draft-vasseur-ccamp-loose-path-reopt-02.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

 

This draft is another that does not make it onto the agenda for San Diego, but I will be taking the mood of the room for whether this is useful CCAMP work. Please read-up in advance and send comments to the list.

 

My comments are below. Please try to avoid strange characters in ASCII files :-)

 

Thanks,

Adrian

 

==

 

Abstract.

The abstract is far too long.

Can you also remove or expand any acronyms which are not widely known. (TE, LSP, LSR, MPLS, ERO)

 

2. Establishment of a loosely routed TE LSP

Definition of a loose hop.

I think we discussed this before in another context.

What you say about loose hops and the L-bit is fine, but you also need to cover "non-specific abstract nodes" such as AS numbers or IP prefixes, since they (although may carry the L-bit clear to indicate that they comprise a strict hop) still imply a degree of routing freedom that may be susceptible to reoptimization.

 

  "The path computation may either be performed by
   means of CSPF or any Path Computation Element (PCE) and can be
   partial (up to the next loose hop) or complete (up to the TE LSP
   destination)."

Two issues with this text.

a. CSPF is a technique, PCE is a location. I don't think it is

   meaningful to compare them with an either-or statement.

b. Your text here is explicitly allowing a transit node to

   resolve the ERO beyond the next next hop. This is contrary

   to RFC3209. It may be desirable, but it needs wider

   discussion if this is to be supported.

 

<- The path an inter-area TE LSP T1 from R1 (head-End LSR) to R11
>- The path requested by an operator for an inter-area TE LSP T1

>  from R1 (head-End LSR) to R11

4.1 Path re-evaluation request

 

Where do we stand on this draft using up one of the rare SESSION_ATTRIBUTE flags instead of using the LSP_ATTRIBUTES object? In particular, is this a quality of the session or the LSP?

 

 

5.1 Head-end reoptimization control

Previously there was some discussion of signaling by the head-end whether reoptimization may be performed by transit nodes "autonomously" or whether only the head-end may initiate reoptimization. This section seems to state that you don't support this signaling and REQUIRE that only the head-end may initiate reoptimization.

I think it would be wise to cover both cases in this draft.

 

 

New error values

Suggest you remove the numeric values of the new error codes from all over the text and have them in just one place for IANA assignment.

Node that they are called "Error Values" not "error sub-codes"

 

 

Unsatisfied reference

You have a reference to [PATH-COMP], but no citation.

This is an important consideration where there are constraints to the original computation that need to be applied at later computation points.

You might also mention route exclusions in this context.

 

 

5.3.2 Mid-point explicit notification mode

In the case of imminent local maintenance you are using an unreliable message (PathErr) to notify the head-end that it really should redirect the LSP. Is it assumed that the node that is about to go into maintenance mode SHOULD retransmit the PathErr periodically until the LSP is moved? What if no better path exists?

Note that there is an operational contradiction seen in the network between the statement that a head-end receiving an error value 7 or 8 is REQUIRED to reoptimize, and a head-end that doesn't support the error value being supposed to ignore the PathErr. How is the node that is about to go into maintenance mode supposed to distinguish these cases?

 

 

8. Acknowledgments

It is good to see that Raymond as an author is giving himself full acknowledgment for his work ;-)

 

 

Refs.

[INTER-AREA-AS] is now dead. Long live its replacement.