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

From: [email-masked]
Date: Tue, 1 Feb 2005 10:48:35 +0100

hi adrian, so i have a more fundamental questions/issues the Notify request object was meant to Notify entities different from the head-end - so why is this mechanism not considered that notifies this (notifying domain) entity on behalf of the other local domain nodes that in turn would notify the head-end LSP nodes (note: the Notify Request object processing has been extended in the segment recovery document to tackle similar cases) ?

"Adrian Farrel" <[email-masked]>
01/31/2005 09:54 GMT
Please respond to "Adrian Farrel"

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "JP Vasseur" <[email-masked]>, <[email-masked]>
bcc:
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-

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: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "JP Vasseur" <[email-masked]> <[email-masked]>
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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 3 Feb 2005 08:19:39 -0500

Hi Dimitri,

On Jan 30, 2005, at 7:48 AM, [email-masked] wrote:

>> Well, Let us assume that all links are 10G except BC which is 9.8G. 
>> Let us

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.

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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 3 Feb 2005 08:35:12 -0500

Hi Adrian,

On Jan 29, 2005, at 9:59 AM, Adrian Farrel wrote:

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

Good suggestion, thanks.

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

Sure.

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

Well if there is no strong reason for:
- using the Admin Status instead,
or
- not using one bit of the Session Attribute object

we would prefer to keep this part unchanged.

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

no, no ... see below.

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

I'm certainly *not* suggesting to rely on signaling to populate the 
TED. All I'm saying (and without this, most deployed TE networks would 
have serious issues in term of convergence upon link failure) is that 
an LSR receiving a PERR should prune momentarily (timer-based) the 
failed network element from its TED before recomputing a new TE LSP 
path. If you have an issue with the formulation, I can suggest:

- The link (sub-code=7) or the node (sub-code=8) SHOULD be locally 
registered for further reference so as to avoid re-using the link to 
compute in subsequent path computation (at least for some period of 
time until the TED is updated by the routing protocol).

OR

I can simple remove that text since this is implementation specific and 
not directly related to the protocol itself.

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

This is orthogonal to crankback.

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

The term "various LSRs" is key indeed whereas this ID exclusively 
relies on head-end 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 other words, you'd be happy with the removal of the maintenance 
procedure from this ID, right ?
That said, all the procedure are identical, so why not keeping the 
paragraph that suggests to cope with maintenance since this certainly 
requires a head-end reopt ?

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

In case of link oos, for inter-domain the head-end does not have any 
idea of what is the best strategy to apply because of its lack of 
visibility ! You can draw two topologies for which the best strategy 
will either be to reroute along the same ABR or via another ABR. We 
know other path computation techniques to sort this out, should the 
shortest path be required ....

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

I think that in both cases, the issue is identical. Regardless, of the 
address carried in the PERR, the head-end cannot determine what is the 
"more optimal" choice with such path computation technique. Note that 
an implementation may try multiple alternatives.

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

I know ;-)

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

Hey not at all ... in fact, unless some mid-point LSR does weird things 
on flags that they do not understand because some procedure have not 
been documented, this only requires partial network upgrades. Quite 
frankly since this is not likely to happen ...

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

Ah, I was feeling the suggestion ;-) ... Along these lines, if we had 
to write BCP for all the non-specified behavior, I'm afraid we would 
have to write quite a few.
If the WG think that this may be an potential issue that must be 
documented I would volunteer but I could bet a few beers ;-) that 
existing implementations will just do the right things.

>  >> better path rather than of a link going oos) avoid thrashing 
> races? As
>
>
> Let us assume that the LSPs are 5G each...
>
>
>
> reoptimization centrally. This is relatively trivial and works well 
> because:
>
>

well the latter is quite arguable ;-)

> should not lead to LSPs being dropped.
>
>
>  [SNIP]
>
>
>
> but clearly it doesn't. Perhaps you'd like to add some processing 
> thoughts for 25:6?
>
>

Well, there are a multitude of options both in term of implementations 
*and* parameters settings ... so I would prefer to not elaborate too 
much here on implementation specific details. The aim of the draft is 
for the head-end to get notified on the existence of a more desirable 
path. The head-end behavior upon such notification is a bit out of the 
scope.

Hope you're ok with this and if so I'll repost the new rev.

Cheers, and thanks for your detailed comments.

JP.