[Gen-art] GEN-ART review of draft-ietf-ccamp-loose-path-reopt-01

<I'm assuming people know about gen-art by now. If not - ask.>

Document: draft-ietf-ccamp-loose-path-reopt-01
Reviewer: Harald Alvestrand
Date: November 3, 2005

Summary: Technology ready for Proposed, presentation could use work

Once I understood what this document's driving at, it's a refreshingly 
simple idea: Let intermediate nodes tell the headend node that a better 
(G)MPLS path might be available, and let the headend node have a way to get 
the intermediate nodes to look for one.

I think this is well captured in the last half of the abstract:

   This document proposes a
   mechanism that allows a TE LSP head-end LSR to trigger a new path re-
   evaluation on every hop having a next hop defined as a loose or
   abstract hop and a mid-point LSR to signal to the head-end LSR that a
   better path exists (compared to the current path in use) or that the
   TE LSP must be reoptimized because of some maintenance required on
   the TE LSP path.

and that the abstract would actually be better if the first part was moved 
to the introduction (which in fact says much the same thing, but with more 
words).

Minor technical:

The document does not say explicitly that it's only applicable to LSPs set 
up and maintained via RSVP-TE. (Is it RSVP-TE, or just RSVP?)

More editorials:

- The "notice" that is section 1 seems oddly placed. It might be better 
placed in section 7, where the requirements for section 1 being true are 
stated.

- The document needs a terminology section, or absent that, a consistent 
policy of acronym expansion on first use; ERO is used 6 times before it's 
expanded in the last sentence of the first para of section 1. Other 
acronyms not expanded are TE, LSP, RSVP, LSR, IGP - these are commonly used 
across many (G)MPLS documents, so it's possible that you could point to a 
terminology section from another RFC and be done.

- I believe section 3 is purely tutorial and contains no new protocol. It 
would be good if it clearly said so, and said which document contained the 
normative description of the procedure.

- Section 4 repeats the description of the mechanism given in the 
introduction. I believe this is superfluous.

- The order in which the two mechanisms are introduced in section 2 and 4 
was confusing to me at first read. I think it would flow better if the 
midpoint to headend signalling was mentioned first, and the headend to 
midpoint mechanism was defined afterwards, saying something like

        - A head-end LSR to trigger on every LSR whose next hop is a
        loose hop or an abstract node the re-evaluation of the current
        path in order to detect a potential more optimal path, which may
        result in the mid-point LSR using the mechanism above to signal
        the existence of such a more optimal path

(Note: The English of the paragraph reads oddly, given that the bullets do 
not form complete sentences without the introductory text; it's possible to 
do this better, I think.)

- The description in section 6.3 also obscures the linkage between the two 
functions by calling them "modes"; I'd prefer "functions" - because use of 
the "head-end requesting function" makes the midpoint invoke the "mid-point 
explicit notification function".

- The enumeration of reasons to perform a reoptimization query (timer, 
knowledge of link state change, operator command) seems like either too 
much or too little; there seems to be no protocol impact whatsoever of 
these mechanisms, and there could concievably be other reasons for sending 
the queries.... I suggest inserting some "for example" statements around 
them, so that it's clear that the nodes are free to exercise these 
procedures whenever they feel like it.

- There's a minor inconsistency between section 8, where a head-end may 
(lowercase) decide to ignore notifications from another domain, and section 
6.3.2, where it MUST perform a reoptimization on receiving sub-codes 7 and 
8. I suggest changing the MUST to a SHOULD; this also avoids the silly 
state of having gotten a notification for a path it's decided to tear 
down......

- Some speling erors were noted, but I didn't have time to write them down.

Nice document!