Draft: draft-ietf-ccamp-loose-path-reopt-01 Reviewer: Harald Tveit Alvestrand [harald@alvestrand.no] Review Date: November 3, 2005 LC Date: October 28, 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!