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

[Dimitri.Papadimitriou@alcatel.be]

adrian, concerning the below point:

>>> 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.

and how this is sorted out when there are multiple competing head-ends
(that may belong to separate domains) ?

>Sure. In a single domain you can apply sensible and rational
reoptimization >centrally.

note that this "central" processing is difficult to achieve when multiple
hea ends do not belong (or are not under the control of a single entity)

> 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