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

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

Hi Dimitri,

On Jan 30, 2005, at 7:48 AM, Dimitri.Papadimitriou@alcatel.be wrote:


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) ?

race conditions are unavoidable and sorted out upon CAC on Mid-point ... this has been the case for ever in both intra and inter-area.

Thanks.

JP.


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