Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-

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

Thanks JP (and thanks for the rigour of tracking down all of the points raised).

 

[SNIPPED]

>> It seems to me that this draft is applicable to a strict ERO where one
>> of the hops is a non-specific abstract node such as an AS number. This
>> is made clear in section 2, but the Abstract and Introduction (yeah,
>> and also the title and draft name) do not adequately expose this fact.
>> But, further, the Introduction talks only about reoptimization without
>> any mention of loose hops or abstract nodes. Thus the draft is
>> schizoid to the third degree - is this loose path reoptimization,
>> reoptimization of loose and non-specific abstract nodes, or general
>> reoptimization? The draft needs to be consistent and clear.
>
>Agree, the following definition has been adopted throughout the
>document: "A loosely routed LSP is defined as an LSP that follows a
>path that contains at least one loose hop or a strict (abstract node)
>hop"

 

So, to be clear, you are only interested in the reoptimization of such "loosely routed LSPs".

 

But note RFC 3209...

   An abstract node
   is a group of nodes whose internal topology is opaque to the ingress
   node of the LSP.  An abstract node is said to be simple if it
   contains only one physical node.

So your definition is not quite accurate since a "strict (abstract node) hop" includes a strict simple abstract node.

 

How about:

   A loosely routed LSP is defined as one that does not contain a full

   explicit route identifying each LSR along the path of the LSP at

   the time it is signaled by the ingress LSR. Such an LSP is signaled

   with no ERO, with an ERO that contains at least one loose hop, or

   with an ERO that contains an abstract node that is not a simple

   abstract node (that is, an abstract node that identifies more than

   one LSR).

 

>I guess that the document title can remain unchanged considering that a
>loose path also includes the case of a path where at least one hop is
>an abstract node.

 

Following the above definition, that is true. Just check that the defintion appears early in the Introduction (and maybe in the Abstract).

>> Section 2 states that an ERO expansion is either up to the next loose
>> hop or to the destination. But, in fact, the ERO expansion may also be
>> any partial fragment towards either of these targets (including next
>> hop resolution). I suggest re-wording this paragraph to list (as
>> bullets) what an ERO might contain, and in a separate list, what the
>> computation might produce.
>
>We listed in this paragraph the most usual case of ERO expansion. If
>you're ok with this, elaborating further on ERO expansion is out of the
>scope of this document.

 

"Most usual" is subjective. Consider nested domains.

But I'm not too bothered about this particular issue, so leave the text.

 
>> Section 4.1
>>
>> I'm not comfortable with the Session Attributes toggling like this.
>> This type of function is what the Admin Status object was invented
>> for.

 

?

>> In section 5.3.2
>> - The link (sub-code=7) or the node (sub-code=8) MUST be
>>  locally registered for further reference (the TE database must
>>  be updated)
>>
>> What does "the TE database must be updated" mean? Are you saying that
>> the TED is now built from information flooded by the IGP *and* by
>> information fed back from signaling? If so (and I don't approve!) then
>> you must define what happens when you receive a new LSA for the
>> specific link that contradicts the information signaled. There is a
>> strong argument that says that *the* method we use for building the
>> TED is IGP flooding - if this mechanism doesn't provide you with the
>> information you need, then you should propose extensions to the IGP,
>> not hook the information onto signaling.

>Let me sightly disagree here. I'm fine to not mention this since this
>may be implementation specific. That said, I do think that this is
>highly desirable (in combination with timer-based mechanism) so as to
>speed convergence. Typically, upon receiving a PathErr message it does
>make sense to first update your TED or the head-end will keep trying
>the same path until an LSA/LSP get received. In many networks, such
>optimization is definitely required to speed up the TE LSP rerouting.

I really disagree (more than slightly :-)

 

It is absolutely OK to say that the failed/going-oos link/node can be supplied to the path computation component as an exclusion. This applies to the recomputation of the failed LSP.

 

It is very suspect to say that you will update the TED. This would apply to the computation of new LSP *only* by the LSR that happens to be the ingress for the failed LSP. How do you know that the next LSP computed will be computed at that LSR?

 

For this procedure to have any realistic meaning, you would want the information to reach all computation points, and the signaling protocol should not do this.

 

Certainly, if you cite "rapid convergence", we will have to convince the IGP WGs and the ADs that it is correct to distribute routing information using the signaling protocol, and not to make changes to the IGP as necessary.

 

Again, I would like to refer you to the crankback draft which handles this issue at ingress and transit computation points.

 

>> OTOH it may be that all you mean is that the Session state should be
>> updated to indicate the link or node that is being shut down so that
>> later recomputation can avoid this link. In this case, I suggest you
>> refer to the CCAMP crankback draft.

>Still such update may be beneficial to other TE LSP and is orthogonal
>to the use of crankback?

 

The only way in which it is orthogonal is that it has been specified differently.

 

We have three drafts we need to sort out here.

- Loose path reoptimization

- Crankback

- Graceful shutdown

 

It seems to me (humbly ;-) that crankback defines the mechanisms for reporting failed resources during LSP setup or after the LSP is established. It specifies the procedures by which various LSRs may attempt to reroute.

 

Graceful shutdown specifies procedures for withdrawing resources so that LSPs are moved using make-before-break before a resource is set oos. This uses existing routing and signaling procedures, but introduces new error codes so that we can distinguish graceful shutdown from failure cases.

 

Loose path reoptimization essentially defines how an ingress may request information about potential reoptimization, and how an LSR may report potential reoptimization. The former is, of course, new procedures. The latter is new error codes.

 

I think I recall that you agreed that the local maintenance stuff should move out of the Loose Path Reoptimization draft [did I make that up?] in which case, the discussion we are having applies only to the split between crankback and graceful shutdown.

 

>> In section 5.3.2
>> - ... Note that in the case of TE LSP
>>  spanning multiple administrative domains, it may be desirable
>>  for the boundary LSR to modify the RSVP PathError message and
>>  insert its own address for confidentiality reason.
>>
>> Yes. Good point, but doesn't the error code also need to change?
>> Otherwise it will appear that the border node is the node being taken
>> oos.
>
>If you agree with this argument I would vote for keeping the same error
>code since this would not change the action taken by the head-end.

 

Note that this debate needs to be split for reoptimization and graceful shutdown. [Increasingly I hope I did hear you say you would remove all graceful shutdown text from this draft!]

But absolutely it would...

 

    AS1     :    AS2  

            :

A---.....---B---D-------Z

         \  :\ /       /

          \ : E       /

           \:        /

            C---..../

            :

Graceful shutdown...

Link BD wants to go out of service.

B needs to report this to A so that there is a make-before-break resignaling.

B substitutes its address in the PathErr.

A assumes B is not healthy and routes through C (very sub-optimal).

A should have resignaled through B and allowed B to route via E.

 

Reoptimization...

LSP is via E. Link BD comes up.

B needs to signal simply "reoptimize".

Since B will do the recomputation, the PathErr can safely carry its address.

 

>> Section 6
>>
>> Need to describe the processing by an LSR that does not understand the
>> new flag (rather than understand it but not support it). Note that you
>> cannot define the behavior of legacy LSRs in this draft, so you must
>> reference behavior defined in some other document.
>>
>> Ditto the new error code.
>
>Unfortunately I do not think that RFC3209 specifies the behavior of a
>node receiving a SESSION ATTRIBUTE flag that it does not understand ...
>An implementation should then just ignore such flag if it does not
>understand it.

 

You are correct. This is one of the joys in our life.

 

But since nothing is stated, there is a high risk that your new flag will be zeroed out by a transit LSR. Oh dear; does that mean that your extensions cannot be guaranteed to work unless the whole network is upgraded?

 

So you need to make some statement. (Or perhaps you'd like to write a BCP for 3209?)


>> Question...
>>
>> How does the process of unsolicited notification (of a potential
>> better path rather than of a link going oos) avoid thrashing races? As
>> a very simple example, consider the following n/w.
>>
>> <-A1-> <--A0-> <-A2->
>> A-----B       C-----D
>>       |       |
>>       |       |
>> E-----F---G---H-----I
>>
>> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and
>> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>>
>> Now install a *low* bandwidth link BC capable of carrying either but
>> not both LSPs. Both B and F will notice that the LSPs entering A0
>> through them can be re-optimized and will report the fact to A and E
>> respectively.

>note that if the link is a "low" bw link, it is unlikely that B and F
>will report a better path but yes that could happen depending on the
>IGP links costs indeed.

 

Well, Let us assume that all links are 10G except BC which is 9.8G. Let us assume that the LSPs are 5G each...

>> Both A and E will attempt mb4b, but (of course) only one will succeed.
>> In a small network, this is not a big deal, but in a large network
>> with a lot of LSPs this is clearly a waste of processing and will
>> cause a degree of network thrash maybe only in the control plane, but
>> maybe in the data plane if a lower priority LSP is re-routed first. In
>> fact, this scenario can cause significant disruption in the data plane
>> as the re-routed LSP will be preempted and could have been
>> successfully left in its original place.

>

>Indeed, but this is no different that any other reoptimization scenario
>in a single area. If for example, a link is restored within an area
>that could offer a potentially more optimal path to a large number of
>TE LSPs, there could be race conditions indeed. This is usually sorted
>out by using jittered reoptimization at the head-end.

 

Sure. In a single domain you can apply sensible and rational reoptimization centrally. This is relatively trivial and works well because:

- repotimization of one LSP at a time is bound to lead to

  relatively poor results

- reoptimization is not time-critical

Note that it is very important that an operation like reoptimization should not lead to LSPs being dropped.

[SNIP]

>> Thus I would suggest removing the unsolicited notification of
>> reoptimization opportunities (while retaining the unsolicited
>> notification of links going oos) or requiring that the policy be
>> timer-based not event triggered.
>
>We would definitely prefer to keep this mode. Implementation could just
>activate the function for *some* sensitive LSP + combined with with
>jittered reoptimization but such notification is desirable to quickly
>take advantage of a newly restored link.

 

OK, that's interesting.

So I didn't see any descripition of processing rules for when 25:6 is received. I (flasely) assumed that the text for 25:7 and 25:8 applied, but clearly it doesn't. Perhaps you'd like to add some processing thoughts for 25:6?

 

Cheers,

Adrian