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

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Sun, 25 Feb 2007 14:00:39 -0600

Hi,
 
Here's my review of this I-D to help the authors prepare it for WG last
call. In my opinion, the draft is almost ready except for a few minor
items and editorials. I encourage the WG to also post any items at this
time, so as to allow the authors to efficiently update. If the authors
can submit a new version addressing the comments, we can take the I-D
forward.
 
Thanks,
Deborah
 
=======
Boilerplate
Need the new boilerplate
=======
Nits: may want to check, a couple of nits on weird spacings and line
lengths
=======
Section 1
Update for recent work, e.g. [INTER-DOMAIN-FRAMEWORK] is RFC4726,
RFC4726 applies for MPLS-TE and GMPLS, requirements for GMPLS are in
draft-otani-ccamp-interas-gmpls-te-05.txt.
=======
Section 2
text has "supported by one of three options"
May want to also mention 4726's hybrid support, probably a small note is
all that's needed, e.g. "(or hybrid)". Also, it would be useful to
mention something on consideration for 4726's backward compatibility,
either here or in a later section.
=======
Section 3
item 2 incomplete sentence, a suggestion:
s/adhered to./adhered./
also in item 2
s/message an error code/message with error code/
item 3
s/in the Section 3/in Section 3/
item 4
s/option is supplied/option is specified/
=======
Section 3.2
s/information that report/information that reports/
=======
Section 5.1.2
s/(filed link)/(failed link)/
=======
Section 5.1.3
s/domian/domain/
=======
Section 6
s/preferable/more preferred/
s/in order search/in order to search/
=======
Section 7
s/:-/:/
the text says "disallow or ignore hops", I don't think its "ignore"?
======
[LOOSE-REOPT] is now [RFC4736], and Informational, did you want to
reference as a Normative Reference?
Check and update others.
======
Section 11
JP's email address is up-to-date?

---

From: [email-masked]
Date: Sun, 25 Feb 2007 21:42:56 +0100

deborah, all

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-F-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---------

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. 

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

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

thanks,
- d.

"BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Sent by: [email-masked]
25/02/2007 21:00
 
        To:     <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>, "JP Vasseur" 
<[email-masked]>, "Arthi Ayyangar" <[email-masked]>
        Subject:        Chair review of 
draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

Hi,
 
Here's my review of this I-D to help the authors prepare it for WG last 
call. In my opinion, the draft is almost ready except for a few minor 
items and editorials. I encourage the WG to also post any items at this 
time, so as to allow the authors to efficiently update. If the authors can 
submit a new version addressing the comments, we can take the I-D forward.
 
Thanks,
Deborah
 
=======
Boilerplate
Need the new boilerplate
=======
Update for recent work, e.g. [INTER-DOMAIN-FRAMEWORK] is RFC4726, RFC4726 
applies for MPLS-TE and GMPLS, requirements for GMPLS are in 
all that's needed, e.g. "(or hybrid)". Also, it would be useful to mention 
something on consideration for 4726's backward compatibility, either here 
or in a later section.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Feb 2007 11:22:07 -0000

Dimitri, Deborah,

Thanks for your comments on this I-D.

Since I seem to be the de facto editor at the moment, I will try to get to 
them this week and submit a new revision before the cut-off.

Cheers,
Adrian
----- Original Message ----- 
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; "JP Vasseur" 
<[email-masked]>; "Arthi Ayyangar" <[email-masked]>
Sent: Sunday, February 25, 2007 8:00 PM
Subject: Chair review of draft-ietf-ccamp-inter-domain-rsvp-te-04.txt

Hi,

Thanks,
Deborah

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Feb 2007 14:27:59 -0000

Dimitri,

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

> A-E-C-D, or A-B-F-D, we have a situation where B Notify msg toward X would

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.

> 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.

> 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.

> 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

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