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

[JP Vasseur <[e-mail]>]

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