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

From: JP Vasseur <[email-masked]>
Date: Thu, 2 Feb 2006 11:22:53 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 05 Feb 2006 13:12:26 +0100

Good that it was helpful!

One outstanding issue.....

--On 2. februar 2006 11:22 -0500 JP Vasseur <[email-masked]> wrote:

> 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

isn't the answer to the headend-to-midpoint query an instance of the 
midpoint-to-headend signal?

from the doc, I understood it as if the headend can't tell the difference 
between a spontaneous reoptimization and a reoptimization done in response 
to a headend query - but there may be a difference I missed.

Not terribly important!

---

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Feb 2006 07:57:55 -0500

Hi Harald,

Thanks for your reply (and your review)  - see in line

On Feb 5, 2006, at 7:12 AM, Harald Tveit Alvestrand wrote:

> isn't the answer to the headend-to-midpoint query an instance of  
> the midpoint-to-headend signal?
>
> from the doc, I understood it as if the headend can't tell the  
> difference between a spontaneous reoptimization and a  
> reoptimization done in response to a headend query - but there may  
> be a difference I missed.
>

You did not miss anything ;-) but in the mid-point notification case  
there are other cases that we handle such as the reoptimization for  
path maintenance and so on ... Thus starting with the head-end  
control function is more didactic ;-)

> Not terribly important!

Good, thanks. I'll repost today to move forward. Just a process- 
oriented question. What is the logical next step after having  
addressed the gen-art review comments ?

Thanks.

Cheers.

JP.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 06 Feb 2006 14:16:30 +0100

--On mandag, februar 06, 2006 07:57:55 -0500 JP Vasseur 
<[email-masked]> wrote:

>> Not terribly important!
>>
>
> Good, thanks. I'll repost today to move forward. Just a process- oriented
> question. What is the logical next step after having  addressed the
> gen-art review comments ?

What you should do - even before submitting - is to check with Alex as 
responsible AD.
This review was done in the Last Call period, and there may be more issues 
that were raised during Last Call that he'd want you to address.

If there aren't any, then just tell Alex you think it's ready...

                           Harald

---

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Feb 2006 11:15:56 -0500

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,
>
>>   mechanism that allows a TE LSP head-end LSR to trigger a new  
>> path re-
> 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  
>>        path in order to detect a potential more optimal path,  
>> which may
> the one more commonly used - that said, they're not exclusive) but  
> I reworded a bit since indeed clarify could be improved. Thanks.
>
>> the two functions by calling them "modes"; I'd prefer "functions"  
>> - because use of the "head-end requesting function" makes the  
>> - 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  
> <draft-ietf-ccamp-loose-path-reopt-02.doc>
>
> Thanks,
>
> JP.
>
>>
>>
>>
>>
>>
>>
>>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Feb 2006 16:36:02 -0000

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-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: "Harald Tveit Alvestrand" <[email-masked]>; <[email-masked]>;
"JP Vasseur (Cisco)" <[email-masked]>; "Yuichi Ikejiri"
<[email-masked]>; <[email-masked]>; "Kireeti Kompella"
<[email-masked]>; "Adrian Farrel" <[email-masked]>; "Alex Zinin"
<[email-masked]>; "Bill Fenner" <[email-masked]>
Sent: Monday, February 06, 2006 4:15 PM
Subject: Re: GEN-ART review of draft-ietf-ccamp-loose-path-reopt-01

> Harald's suggestions made during GEN-ART review) ? If so, I'll repost

--------------------------------------------------------------------------
------

---

From: Alex Zinin <[email-masked]>
Date: Tue, 7 Feb 2006 16:57:17 -0800

Adrian, JP-

 Yes, please go ahead and respin the doc.

-- 
Alex
http://www.psg.com/~zinin