Re: Chair review of draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Dimitri,

Thanks for getting these review comments in before last call started. Most 
welcome.

> o) section 3.4: processing is clearly indicated but on inter-domain basis
> one of the issue is that the processing can have to be performed on nodes
> that will further Notifies toward an AS-path that is completely different
> from its corresponding TE LSP e.g. A-B-...-C-D, but Notify msg flows along
> A-E-C-D, or A-B-F-D, we have a situation where B Notify msg toward X would
> travel via the tail-end (D) and C Notify msg would loop via the head-end
> (A) - advisable to prevent such thing
>
>      ----------E--------
>     |                   |
> e.g. A --- B -... X ...- C --- D
>           |                   |
>            ---------F---------

To clarify this point, you are concerned about how the Notify recipient may 
be replaced in a Path message as it enters the domain, and as it exits the 
domain (ditto Resv message).

This issue is dicussed somewhat in the GMPLS-UNI (RFC4208) and in segment 
protection. And there is a trade-off and a modelling question.

The trade-off is that it is probably highly beneficial to repair problems 
within the domain. Therefore, the domain entry point should replace the 
Notify Recipient with its own ID. The down side of this is that a Notify 
that genuinely needs to go to the original Notify Recipient must be 
forwarded (at the RSVP level) by the domain entry point.

The modelling is issue concerns how the Notify Recipient should be set on 
the Path message as it leaves a domain. The domain is not interested in 
knowing about notifiable events that happen outside the domain, so ideally 
we would replace the Notify Recipient with the original recipient used 
before entering the domain, but htis information is not known.

Actually, however, this replacement is only appropriate in nested domains. 
In sequential domains, when we leave one domain, we enter another, and so 
the new domain will want to use its own domain entry point as the Notify 
Recipient. This introduces the trade-off benefit again because the local 
issues are handled locally (which is good) but notifications that should go 
(for example) to the ingress, must now be forwarded multiople times, domain 
by domain.

Now, note that the inter-domain framework (RFC4726) was careful to put 
nested domains out of scope. They are more appropriate to the MLN work. We 
could observe that the domain-by-domain forwarding technique could be used 
for nested domains as well, but it doesn't look so pretty. Igor and I 
proposed a solution to this issue for nested in domains in That Book, but 
AFAIK, no-one has come close to needing to deploy a solution for nested 
domains yet.

So, I have added some discussion to the I-D around this subject.

> o) section 6: it is unclear from section 6 why an LSP head-end would ever
> desire to exercise control re-opt in part. when non-contiguous, at the end
> the only realistic reason for requesting such kind of request from the
> head-end is lost of performance e.g increasing loss, delay, etc.

I think you have answered your question to some extent.

A transit domain may be aware of the potential for reoptimization, but not 
bother because it is not worried by the level of service being provided. But 
the cumulative effect on the end-to-end LSP may cause the head-end to worry 
and trigger a reoptimization request (of course, the transit domain may 
choose to ignore the request).

But there is another benefit to end-to-end reoptimization that per-domain 
reoptimization cannot address. Per-domain re-optimization is restricted to 
preserve the domain entry and exit points (since to do otherwise would break 
the LSP!). But end-to-end reoptimization is more flexible and can select new 
domain border LSRs.

You are also right to observe that end-to-end reoptimization may involve a 
non-local modification and that might select new entry / exit points. In 
this case, we can observe that local re-optimization is more easily and 
flexibly achieved using nesting or stitching, and the "locality principle" 
(i.e., the idea of keeping information only where it is needed) is best 
achieved using stitching or nesting. That said, a contiguous LSP can easily 
be modified to take advantage of local reoptimizations (as defined in 
RFC4736) even if, as you observe, this would require the dissemination of 
information and the invocation of signaling outside the local domain.

I will update section 6 to bring out these points.

> there is also a clear diff. between a desirable re-opt. when the LSP is
> contiguous (and thus triggerable only by the head-end) and a
> local-/domain-specific resource re-opt. in other cases

You mean the cost/benefit analysis of reoptimization may be different.
Yes, that is correct and worth adding to section 6.

> o) section 7: the document could be more specific for the hello exchanges
> at inter-domain boundaries - in the same section specific security in
> using MPLS-BFD for end-to-end TE LSP should be clarified

I think you are raising some issues about peering and trust models at domain 
borders. These models relate to the establishment of signaling adjacencies 
(for example, but not limited to) through the exchange of Hello messages. 
Also relevant is the trust that one can assign to the content of signaling 
messages (including restart messages) and this is an example of the issues 
raised by the IESG with various recent I-Ds, in particular the restart 
extensions I-D.

AFAICS there is required to be *some* trust relationship between neighbors 
across a domain boundary if signaling is to be used. If this trust does not 
exist, do not use this function. It is not a requirement to signal across 
domain boundaries, but it is a requirement to provide a mechanism to support 
it if neighboring domains wish to.

Should this trust relationship be any different from between intra-domain 
peers? Possibly.

Should domain border nodes be able to selectively disallow certain 
"vulnerable" features at domain borders? Absolutely. And it is worth 
pointing out that the restart function could be disabled on the links 
between domain borders if it is considered vulnerable.

I have made several updates to the security section.

> - in the same section specific security in
> using MPLS-BFD for end-to-end TE LSP should be clarified

Absolutely. I have added a note about OAM, although this is largely to
reference other material since OAM is out of scope for this signaling
draft.

Many thanks,

Adrian