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

["Adrian Farrel" <[e-mail]>]

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