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

[Alex Zinin <[e-mail]>]

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" <[e-mail]>
> To: "Alex Zinin" <[e-mail]>
> Cc: "Harald Tveit Alvestrand" <[e-mail]>; <[e-mail]>;
> "JP Vasseur (Cisco)" <[e-mail]>; "Yuichi Ikejiri"
> <[e-mail]>; <[e-mail]>; "Kireeti Kompella"
> <[e-mail]>; "Adrian Farrel" <[e-mail]>; "Alex Zinin"
> <[e-mail]>; "Bill Fenner" <[e-mail]>
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art