[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Hi Adrian,
On Jan 29, 2005, at 9:59 AM, Adrian Farrel wrote:
<x-tad-smaller>Thanks JP (and thanks for the rigour of tracking down all of the points raised).</x-tad-smaller>
<x-tad-smaller>[SNIPPED]</x-tad-smaller>
<x-tad-smaller>>> It seems to me that this draft is applicable to a strict ERO where one </x-tad-smaller>
<x-tad-smaller>>> of the hops is a non-specific abstract node such as an AS number. This </x-tad-smaller>
<x-tad-smaller> >> is made clear in section 2, but the Abstract and Introduction (yeah, </x-tad-smaller>
<x-tad-smaller>>> and also the title and draft name) do not adequately expose this fact. </x-tad-smaller>
<x-tad-smaller>>> But, further, the Introduction talks only about reoptimization without </x-tad-smaller>
<x-tad-smaller>>> any mention of loose hops or abstract nodes. Thus the draft is</x-tad-smaller>
<x-tad-smaller> >> schizoid to the third degree - is this loose path reoptimization,</x-tad-smaller>
<x-tad-smaller> >> reoptimization of loose and non-specific abstract nodes, or general </x-tad-smaller>
<x-tad-smaller>>> reoptimization? The draft needs to be consistent and clear.</x-tad-smaller>
<x-tad-smaller>></x-tad-smaller>
<x-tad-smaller>>Agree, the following definition has been adopted throughout the </x-tad-smaller>
<x-tad-smaller>>document: "A loosely routed LSP is defined as an LSP that follows a </x-tad-smaller>
<x-tad-smaller>>path that contains at least one loose hop or a strict (abstract node) </x-tad-smaller>
<x-tad-smaller>>hop"</x-tad-smaller>
<x-tad-smaller>So, to be clear, you are only interested in the reoptimization of such "loosely routed LSPs".</x-tad-smaller>
<x-tad-smaller>But note RFC 3209...</x-tad-smaller>
<x-tad-smaller> An abstract node</x-tad-smaller>
<x-tad-smaller> is a group of nodes whose internal topology is opaque to the ingress</x-tad-smaller>
<x-tad-smaller> node of the LSP. An abstract node is said to be simple if it</x-tad-smaller>
<x-tad-smaller> contains only one physical node.</x-tad-smaller>
<x-tad-smaller>So your definition is not quite accurate since a "strict (abstract node) hop" includes a strict simple abstract node.</x-tad-smaller>
<x-tad-smaller>How about:</x-tad-smaller>
<x-tad-smaller> A loosely routed LSP is defined as one that does not contain a full</x-tad-smaller>
<x-tad-smaller> explicit route identifying each LSR along the path of the LSP at</x-tad-smaller>
<x-tad-smaller> the time it is signaled by the ingress LSR. Such an LSP is signaled</x-tad-smaller>
<x-tad-smaller> with no ERO, with an ERO that contains at least one loose hop, or</x-tad-smaller>
<x-tad-smaller> with an ERO that contains an abstract node that is not a simple</x-tad-smaller>
<x-tad-smaller> abstract node (that is, an abstract node that identifies more than</x-tad-smaller>
<x-tad-smaller> one LSR).</x-tad-smaller>
Good suggestion, thanks.
<x-tad-smaller>>I guess that the document title can remain unchanged considering that a </x-tad-smaller>
<x-tad-smaller>>loose path also includes the case of a path where at least one hop is </x-tad-smaller>
<x-tad-smaller>>an abstract node.</x-tad-smaller>
<x-tad-smaller>Following the above definition, that is true. Just check that the defintion appears early in the Introduction (and maybe in the Abstract).</x-tad-smaller>
Sure.
<x-tad-smaller>>> Section 2 states that an ERO expansion is either up to the next loose </x-tad-smaller>
<x-tad-smaller>>> hop or to the destination. But, in fact, the ERO expansion may also be </x-tad-smaller>
<x-tad-smaller>>> any partial fragment towards either of these targets (including next </x-tad-smaller>
<x-tad-smaller>>> hop resolution). I suggest re-wording this paragraph to list (as </x-tad-smaller>
<x-tad-smaller>>> bullets) what an ERO might contain, and in a separate list, what the</x-tad-smaller>
<x-tad-smaller> >> computation might produce.</x-tad-smaller>
<x-tad-smaller>></x-tad-smaller>
<x-tad-smaller>>We listed in this paragraph the most usual case of ERO expansion. If </x-tad-smaller>
<x-tad-smaller>>you're ok with this, elaborating further on ERO expansion is out of the </x-tad-smaller>
<x-tad-smaller>>scope of this document.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>"Most usual" is subjective. Consider nested domains.</x-tad-smaller>
<x-tad-smaller>But I'm not too bothered about this particular issue, so leave the text.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>>> Section 4.1</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> I'm not comfortable with the Session Attributes toggling like this. </x-tad-smaller>
<x-tad-smaller>>> This type of function is what the Admin Status object was invented</x-tad-smaller>
<x-tad-smaller> >> for.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>?</x-tad-smaller>
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.
<x-tad-smaller>>> In section 5.3.2</x-tad-smaller>
<x-tad-smaller>>> - The link (sub-code=7) or the node (sub-code=8) MUST be</x-tad-smaller>
<x-tad-smaller>>> locally registered for further reference (the TE database must</x-tad-smaller>
<x-tad-smaller>>> be updated)</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> What does "the TE database must be updated" mean? Are you saying that </x-tad-smaller>
<x-tad-smaller>>> the TED is now built from information flooded by the IGP *and* by</x-tad-smaller>
<x-tad-smaller> >> information fed back from signaling? If so (and I don't approve!) then </x-tad-smaller>
<x-tad-smaller>>> you must define what happens when you receive a new LSA for the </x-tad-smaller>
<x-tad-smaller>>> specific link that contradicts the information signaled. There is a </x-tad-smaller>
<x-tad-smaller>>> strong argument that says that *the* method we use for building the </x-tad-smaller>
<x-tad-smaller>>> TED is IGP flooding - if this mechanism doesn't provide you with the </x-tad-smaller>
<x-tad-smaller>>> information you need, then you should propose extensions to the IGP, </x-tad-smaller>
<x-tad-smaller>>> not hook the information onto signaling.</x-tad-smaller>
<x-tad-smaller>>Let me sightly disagree here. I'm fine to not mention this since this </x-tad-smaller>
<x-tad-smaller>>may be implementation specific. That said, I do think that this is </x-tad-smaller>
<x-tad-smaller>>highly desirable (in combination with timer-based mechanism) so as to</x-tad-smaller>
<x-tad-smaller> >speed convergence. Typically, upon receiving a PathErr message it does </x-tad-smaller>
<x-tad-smaller>>make sense to first update your TED or the head-end will keep trying </x-tad-smaller>
<x-tad-smaller>>the same path until an LSA/LSP get received. In many networks, such </x-tad-smaller>
<x-tad-smaller>>optimization is definitely required to speed up the TE LSP rerouting.</x-tad-smaller>
<x-tad-smaller> I really disagree (more than slightly :-)</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>It is very suspect to say that you will update the TED. This would apply to the computation of new LSP *only*
</x-tad-smaller>
no, no ... see below.
<x-tad-smaller>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?</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
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.
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>Again, I would like to refer you to the crankback draft which handles this issue at ingress and transit computation points.</x-tad-smaller>
This is orthogonal to crankback.
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>>> OTOH it may be that all you mean is that the Session state should be </x-tad-smaller>
<x-tad-smaller>>> updated to indicate the link or node that is being shut down so that </x-tad-smaller>
<x-tad-smaller>>> later recomputation can avoid this link. In this case, I suggest you </x-tad-smaller>
<x-tad-smaller>>> refer to the CCAMP crankback draft.</x-tad-smaller>
<x-tad-smaller>>Still such update may be beneficial to other TE LSP and is orthogonal</x-tad-smaller>
<x-tad-smaller> >to the use of crankback?</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>The only way in which it is orthogonal is that it has been specified differently.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>We have three drafts we need to sort out here.</x-tad-smaller>
<x-tad-smaller>- Loose path reoptimization</x-tad-smaller>
<x-tad-smaller>- Crankback</x-tad-smaller>
<x-tad-smaller>- Graceful shutdown</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
The term "various LSRs" is key indeed whereas this ID exclusively relies on head-end reroute.
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
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 ?
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>>> In section 5.3.2</x-tad-smaller>
<x-tad-smaller>>> - ... Note that in the case of TE LSP</x-tad-smaller>
<x-tad-smaller>>> spanning multiple administrative domains, it may be desirable</x-tad-smaller>
<x-tad-smaller>>> for the boundary LSR to modify the RSVP PathError message and</x-tad-smaller>
<x-tad-smaller>>> insert its own address for confidentiality reason.</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> Yes. Good point, but doesn't the error code also need to change? </x-tad-smaller>
<x-tad-smaller>>> Otherwise it will appear that the border node is the node being taken </x-tad-smaller>
<x-tad-smaller>>> oos.</x-tad-smaller>
<x-tad-smaller>></x-tad-smaller>
<x-tad-smaller>>If you agree with this argument I would vote for keeping the same error </x-tad-smaller>
<x-tad-smaller>>code since this would not change the action taken by the head-end.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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!]</x-tad-smaller>
<x-tad-smaller>But absolutely it would...</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller> AS1 : AS2 </x-tad-smaller>
<x-tad-smaller> :</x-tad-smaller>
<x-tad-smaller>A---.....---B---D-------Z</x-tad-smaller>
<x-tad-smaller> \ :\ / /</x-tad-smaller>
<x-tad-smaller> \ : E /</x-tad-smaller>
<x-tad-smaller> \: /</x-tad-smaller>
<x-tad-smaller> C---..../</x-tad-smaller>
<x-tad-smaller> :</x-tad-smaller>
<x-tad-smaller>Graceful shutdown...</x-tad-smaller>
<x-tad-smaller>Link BD wants to go out of service.</x-tad-smaller>
<x-tad-smaller>B needs to report this to A so that there is a make-before-break resignaling.</x-tad-smaller>
<x-tad-smaller>B substitutes its address in the PathErr.</x-tad-smaller>
<x-tad-smaller>A assumes B is not healthy and routes through C (very sub-optimal).</x-tad-smaller>
<x-tad-smaller>A should have resignaled through B and allowed B to route via E.</x-tad-smaller>
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 ....
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>Reoptimization...</x-tad-smaller>
<x-tad-smaller>LSP is via E. Link BD comes up.</x-tad-smaller>
<x-tad-smaller>B needs to signal simply "reoptimize".</x-tad-smaller>
<x-tad-smaller>Since B will do the recomputation, the PathErr can safely carry its address.</x-tad-smaller>
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.
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>>> Section 6</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> Need to describe the processing by an LSR that does not understand the </x-tad-smaller>
<x-tad-smaller>>> new flag (rather than understand it but not support it). Note that you</x-tad-smaller>
<x-tad-smaller> >> cannot define the behavior of legacy LSRs in this draft, so you must </x-tad-smaller>
<x-tad-smaller>>> reference behavior defined in some other document.</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> Ditto the new error code.</x-tad-smaller>
<x-tad-smaller>></x-tad-smaller>
<x-tad-smaller>>Unfortunately I do not think that RFC3209 specifies the behavior of a </x-tad-smaller>
<x-tad-smaller>>node receiving a SESSION ATTRIBUTE flag that it does not understand ... </x-tad-smaller>
<x-tad-smaller>>An implementation should then just ignore such flag if it does not </x-tad-smaller>
<x-tad-smaller>>understand it.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>You are correct. This is one of the joys in our life.</x-tad-smaller>
I know ;-)
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>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?</x-tad-smaller>
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 ...
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>So you need to make some statement. (Or perhaps you'd like to write a BCP for 3209?)</x-tad-smaller>
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.
<x-tad-smaller>>> Question...</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> How does the process of unsolicited notification (of a potential</x-tad-smaller>
<x-tad-smaller> >> better path rather than of a link going oos) avoid thrashing races? As </x-tad-smaller>
<x-tad-smaller>>> a very simple example, consider the following n/w.</x-tad-smaller>
<x-tad-smaller>>> </x-tad-smaller>
<x-tad-smaller>>> <-A1-> <--A0-> <-A2-></x-tad-smaller>
<x-tad-smaller>>> A-----B C-----D</x-tad-smaller>
<x-tad-smaller>>> | |</x-tad-smaller>
<x-tad-smaller>>> | |</x-tad-smaller>
<x-tad-smaller>>> E-----F---G---H-----I</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and </x-tad-smaller>
<x-tad-smaller>>> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.</x-tad-smaller>
<x-tad-smaller>>></x-tad-smaller>
<x-tad-smaller>>> Now install a *low* bandwidth link BC capable of carrying either but </x-tad-smaller>
<x-tad-smaller>>> not both LSPs. Both B and F will notice that the LSPs entering A0 </x-tad-smaller>
<x-tad-smaller>>> through them can be re-optimized and will report the fact to A and E </x-tad-smaller>
<x-tad-smaller>>> respectively.</x-tad-smaller>
<x-tad-smaller>>note that if the link is a "low" bw link, it is unlikely that B and F </x-tad-smaller>
<x-tad-smaller>>will report a better path but yes that could happen depending on the </x-tad-smaller>
<x-tad-smaller>>IGP links costs indeed.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>Well, Let us assume that all links are 10G except BC which is 9.8G. Let us assume that the LSPs are 5G each...</x-tad-smaller>
<x-tad-smaller>>> Both A and E will attempt mb4b, but (of course) only one will succeed.</x-tad-smaller>
<x-tad-smaller> >> In a small network, this is not a big deal, but in a large network </x-tad-smaller>
<x-tad-smaller>>> with a lot of LSPs this is clearly a waste of processing and will</x-tad-smaller>
<x-tad-smaller> >> cause a degree of network thrash maybe only in the control plane, but </x-tad-smaller>
<x-tad-smaller>>> maybe in the data plane if a lower priority LSP is re-routed first. In </x-tad-smaller>
<x-tad-smaller>>> fact, this scenario can cause significant disruption in the data plane </x-tad-smaller>
<x-tad-smaller>>> as the re-routed LSP will be preempted and could have been </x-tad-smaller>
<x-tad-smaller>>> successfully left in its original place.</x-tad-smaller>
<x-tad-smaller>></x-tad-smaller>
<x-tad-smaller>>Indeed, but this is no different that any other reoptimization scenario</x-tad-smaller>
<x-tad-smaller> >in a single area. If for example, a link is restored within an area </x-tad-smaller>
<x-tad-smaller> >that could offer a potentially more optimal path to a large number of </x-tad-smaller>
<x-tad-smaller> >TE LSPs, there could be race conditions indeed. This is usually sorted </x-tad-smaller>
<x-tad-smaller> >out by using jittered reoptimization at the head-end.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>Sure. In a single domain you can apply sensible and rational reoptimization centrally. This is relatively trivial and works well because:</x-tad-smaller>
<x-tad-smaller>- repotimization of one LSP at a time is bound to lead to</x-tad-smaller>
<x-tad-smaller> relatively poor results</x-tad-smaller>
<x-tad-smaller>- reoptimization is not time-critical</x-tad-smaller>
well the latter is quite arguable ;-)
<x-tad-smaller>Note that it is very important that an operation like reoptimization should not lead to LSPs being dropped.</x-tad-smaller>
<x-tad-smaller> [SNIP]</x-tad-smaller>
<x-tad-smaller>>> Thus I would suggest removing the unsolicited notification of </x-tad-smaller>
<x-tad-smaller> >> reoptimization opportunities (while retaining the unsolicited</x-tad-smaller>
<x-tad-smaller> >> notification of links going oos) or requiring that the policy be </x-tad-smaller>
<x-tad-smaller> >> timer-based not event triggered.</x-tad-smaller>
<x-tad-smaller>></x-tad-smaller>
<x-tad-smaller>>We would definitely prefer to keep this mode. Implementation could just </x-tad-smaller>
<x-tad-smaller>>activate the function for *some* sensitive LSP + combined with with </x-tad-smaller>
<x-tad-smaller>>jittered reoptimization but such notification is desirable to quickly </x-tad-smaller>
<x-tad-smaller>>take advantage of a newly restored link.</x-tad-smaller>
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>OK, that's interesting.</x-tad-smaller>
<x-tad-smaller>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?</x-tad-smaller>
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.
<x-tad-smaller> </x-tad-smaller>
<x-tad-smaller>Cheers,</x-tad-smaller>
<x-tad-smaller>Adrian</x-tad-smaller>