Adrian, JP- Yes, please go ahead and respin the doc.
-- Alex http://www.psg.com/~zinin Monday, February 6, 2006, 8:36:02 AM, Adrian Farrel wrote: > This WG chair is OK with the changes. > Looking at the I-D tracker, this I-D is pending AD write-up, so it hasn't > gone out for IESG review yet. > I would suggest an immediate submission of the new version of the I-D so > that the IESG does not waste its time on the points that Harald caught. > Thanks, > Adrian > ----- Original Message ----- > From: "JP Vasseur" <[EMAIL PROTECTED]> > To: "Alex Zinin" <[EMAIL PROTECTED]> > Cc: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>; <gen-art@ietf.org>; > "JP Vasseur (Cisco)" <[EMAIL PROTECTED]>; "Yuichi Ikejiri" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Kireeti Kompella" > <[EMAIL PROTECTED]>; "Adrian Farrel" <[EMAIL PROTECTED]>; "Alex Zinin" > <[EMAIL PROTECTED]>; "Bill Fenner" <[EMAIL PROTECTED]> > Sent: Monday, February 06, 2006 4:15 PM > Subject: Re: GEN-ART review of draft-ietf-ccamp-loose-path-reopt-01 >> Hi Alex, >> >> Could you let me know if you are ok with the changes (incorporating >> Harald's suggestions made during GEN-ART review) ? If so, I'll repost >> that new revision. >> >> Thanks. >> >> JP. >> > -------------------------------------------------------------------------- > ------ >> >> On Feb 2, 2006, at 11:22 AM, JP Vasseur wrote: >> >> > Hi Harald, >> > >> > Many Thanks for the comments ... and sorry for responding so >> > late ... See in line, >> > >> > On Nov 3, 2005, at 11:34 AM, Harald Tveit Alvestrand wrote: >> > >> >> <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). >> >> >> > >> > Indeed, I moved most of the first half of the abstract to the >> > Introduction section. >> > >> >> 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?) >> > >> > OK, I clarified. >> > >> >> >> >> 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. >> > >> > Yes, good point. I moved the text that used to be in the notice >> > section to the section renamed "Applicability and Interoperability" >> > >> >> >> >> - 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. >> > >> > Yes, thanks, a Terminology section has been added. >> > >> >> >> >> - 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. >> >> >> > >> > Indeed, I added some text to clarify. >> > >> >> - Section 4 repeats the description of the mechanism given in the >> >> introduction. I believe this is superfluous. >> >> >> > >> > You're right but unless strong objection I would prefer to keep >> > that section since it incorporates an example that has been >> > introduced in section 3. >> > >> >> - 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.) >> >> >> > >> > I kept the same order (because the first mechanism is likely to be >> > the one more commonly used - that said, they're not exclusive) but >> > I reworded a bit since indeed clarify could be improved. Thanks. >> > >> >> - 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". >> >> >> > >> > Indeed, thanks (fixed). >> > >> >> - 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. >> >> >> > >> > Good point indeed, thanks. >> > >> >> - 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...... >> >> >> > >> > Also a good point ... Thanks, this has been changed to a SHOULD. >> > >> >> - Some speling erors were noted, but I didn't have time to write >> >> them down. >> >> >> > >> > I made another pass and hopefully caught them. >> > >> >> Nice document! >> >> >> >> >> > >> > Sorry for the proprietary format ... but if you want to have a look >> > at the changes and let me know whether they fully address your points: >> > >> > <draft-ietf-ccamp-loose-path-reopt-02.doc> >> > >> > Thanks, >> > >> > JP. >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
