[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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