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

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

Dimitri,

I agree with your points, hence my original questions.

Note that reoptimization within a *single* domain can be handled
"centrally" with the advantages I describe.

If there are multiple domains involved (as you point out) things get
messy. But note that it is only the domain in which reoptimization is
possible that is going to advertise a reoptimization possibility. Thus
this single domain can work out which LSPs would be best reoptimized, and
only notify the appropriate ingresses about the subset of LSPs. In this
case (again) the notifying domain would best make this decision in a
"centralized" manner.

Cheers,
Adrian

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "JP Vasseur" <jvasseur@cisco.com>; <ccamp@ops.ietf.org>
Sent: Sunday, January 30, 2005 12:48 PM
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-


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