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

[[e-mail]]

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" <[e-mail]>
Sent by: [e-mail]
25/02/2007 21:00
 
        To:     <[e-mail]>
        cc:     "Adrian Farrel" <[e-mail]>, "JP Vasseur" 
<[e-mail]>, "Arthi Ayyangar" <[e-mail]>
        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
=======
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?