Re: Some minor comments on the loose-path-opt draft

[Jean Philippe Vasseur <[e-mail]>]

Hi Raymond,

Thanks for your comments and support for the draft - see in line.

At 09:25 AM 4/1/2004 -0800, raymond zhang wrote:
>Hi JP and Yuichi,
>
>Just gone through 
>http://www.ietf.org/internet-drafts/draft-vasseur-ccamp-loose-path-reopt-00.txt 
>and here are some minor comments:
>
>This draft describes a very useful mechanism solving part of the reopt 
>issues documented in the inter-AS requirements draft 
>(http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-06.txt)...
>
>1. Editorial  comments:
>
>1.1. Editorial - clean up the strange characters, for example, in Section 
>4.2, page 5
>"   ...ªªLink-UPªª event). "

ok

>1.2. Section 1, page 2, "
>A loosely routed explicit path is as a path specified as a ..."
>
>
>The "as" proceeding "a path" above should be removed.

right, thanks.

>1.3. Section 1, page 2, "...of the Ipv4 prefix sub-object..."
>should IPv6 prefix be included as well ?
>
>Also in Section 3.2, may need to list a IPv6 error_spec object also...

Agree, we'll fix that,

>1.4. In section 4.3.1, page 7:
>
>"Example:
>
>Let call "
>
>It should be "Let's call..."

ok

>1.5. In section 4.3.1, page 7:
>"... pi such that li is a next (loose) hop of pi for i=1+n"
>
>- delete "pi"
>- "i=1+n" should be changed to "i=1 to n"
>- it may read better if you change "for i=1 to n" to for "i=1 to n which 
>is illustrated in the following example:"
>
>Then after "Pn=<R1,R3,R8>"
>
>add "where L1=R3 is the next loose hop of P1=R1, etc."

right

>2. Other comments:
>
>2.1. In section 4.3.1, page 7
>"- If a better path can be found, the LSR MUST
>              immediately send a Path Error to the head-end LSR
>              (Error code 25 (Notify), sub-code=6 (better path
>              exists))"
>
>I wonder if you should also add "and go ahead with reopt by sending RSVP 
>path messages for the new path". Otherwise there is no action described 
>for this mid-point LSR what it will do after it found a better path and 
>notify the HE LSR.

In this case, the TE LSP is contiguous, hence the mid-point's role is just 
to notify of the existence of a better path (or the requirement for local 
maintenance) in some downstream area/AS. Note that it cannot locally 
reoptimize since the LSP ID would not match. Moreover, the intention is to 
let the Head-end LSR decide on whether to reoptimize depending on the TE 
LSP attributes (pending back-off, ...).

Does that make sense ?

>2.2. Some general comments regarding the mode of operations
>
>There are couple more cases which may be considered:
>
>Mode 1 If it is TE-LSP HE LSR initiated,
>- Midpoint LSR can ignore this request and not to perform reopt even if 
>there is a better path within its AS;
>
>This can either be part of the interconnect agreement between two 
>providers or to protect transit AS for reasons such as HE LSR triggers 
>reopt in an unusually high frequency due to mis-configuration... But 
>mid-point LSR does need to notify the HE LSR why via patherr msg.

Totally agree, this is a good point which will be in the next revision.


>Mode 2 If it is mid-point LSR initiated and midpoint LSR find out there is 
>a better path for an existing TE-LSP and notifies the TE-LSP HE, TE-LSP HE 
>LSR does not want to reopt, for example, configured not to repot that way 
>for operational reasons at that time. (except for local link maint. 
>reasons of course)  I am not sure what's the process here next - both HE 
>and midpoint LSR do nothing and continue to refresh ?

Yes, head-end and the mid-point LSRs could respectively ignore the polling 
and the notification but this is again a good point which is worth being 
clarified.

Thanks for your useful comments: they will be incorporated in the next 
revision.

JP.


>Regards,
>Raymond
>
>
>