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

[JP Vasseur <[e-mail]>]

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:

Thanks,

JP.

>
>
>
>
>
>
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art