Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt"

From: "Loa Andersson" <[email-masked]>
Date: Wed, 11 Apr 2001 18:24:09 +0200

All,

Manojs question is valid, and the answers are less than satisfactory.
Actions in case of next hop changes needs to be specified, some are 
in the LDP spec, others ae specific for CR-LDP. 

There are some cases (list not complete).

- with loosely routed LSP and a better route is found, because of a
  next hop change. In this case I can't see a problem the procedures 
  are  specified in the LDP specification (p 113), assuming that a 
  loosely routed  CR-LSP is roughly equivalent  to a DoD ordered LSP 
  in it lose parts.

- equipment failure leading to that LDP peering is lost in a loosely 
  routed part of an LSP. The outstanding Label Request is by
definition
  lost. The actions needed here is very similar to what is done in the
  situation described above. But this needs to be specified.

- equipment failure in a strictly routed part of an LSP. My feeling is
  that this should be NAKed and responsibility to clear up the 
  situation should be left to the application requesting the
explicitly
  routed LSP.
  Question here is what a loosely routed node does when it receives 
  the NAK? Chances are that the next hop has changed for this node.
  Also needs to be specified.

Test to this effect should be added to the CR-LDP specification.
Haven't
checked but do we have the same problem for RSVP-TE?

BTW, Don's statement that next hop changes do not affect explicitly 
routed LSP is only partly true. In some known cases the LSDB is used 
to calculate the explicit LSP, the information that lead to next hop
changing will be reflected in the LSDB used to calculate the 
explicit route(s).

/Loa

-- 
Loa Andersson
Chief Architect,
Utfors Research, Architecture and Future Lab (URAX)
Utfors AB
Råsundavägen 12
Box 525, 169 29 Solna
Office          +46 8 5270 2000
Office direct   +46 8 5270 5038
Mobile          +46 70 848 5038
Email           [email-masked]
WWW             www.utfors.se

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 11 Apr 2001 18:45:08 -0400

Loa, Sharma, Manoj:

Let me see if I can clarify my position on this.
My mail has been backed up lately. Sorry for the delay.

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2001 12:24 PM
> To: Sharma Prem
> Cc: Fedyk, Don [BL60:2868:EXCH]; manoj juneja; [email-masked]
> Subject: Re: Valid Race Condition related to draft
> "draft-ietf-mpls-crlsp -modify-03.txt"
> 
> 
> All,
> 
The intent of the CR-LDP modification is to change LSPs that have
constraints.
(Constraints usually mean that loose routing is a bad idea because the 
next hop may not satisfy the constraint.) 

There are also a couple of reasons for modification. One is to get a
new constraints the other is to get a new path with the same constraints.
A Loose path is a degenerative case of the latter where there are no 
constraints.

In order to prevent race conditions the rules we have used was if the 
original LSP changes in any way during a modification then the modification
was aborted. There is a point when you switchover to the new LSP that 
changes in the original are irrelevant. 

So there are three stages of modification.

1. Existing path up. New path request traveling. 

During this phase should the Existing path change I would suggest 
aborting the path modification.
 
2. Existing path up. New path mapping backwards. 

During this phase If a label withdraw from the existing path reaches 
the ingress of the LSP before the mapping I would again abort the
modification.

3. Both paths up.
During this stage traffic is atomically switched to the new LSP 
and the existing path becomes redundant. At this point any change in
the originally path is ignored. But if the new path changes due to a 
label release switching back is not an option. 

Finally if you were unlucky and you have aborted a modification in 1. or 2. 
above start again after a suitable sanity check on the existing path.

These are the ways that I would deal with this but these are only suggested.

You can create a lot more complexity by specifying attempts to recover from
some of the situations. Personally, I would not suggest modify on loose
routed paths I would have an option preventing it. 

That said I don't think that there is a ambiguous race condition if you 
followed the above rules as long as the implementation used two disjoint 
paths that are not related to each other. In other words even if a loose
path 
reroutes a loose segment the outer ends are fixed and as long a there
is not a release or withdraw to the head end who cares it the internal 
path changed during a modify.

That is why I thought I answered the questions before. 

>   situation described above. But this needs to be specified.
CR-LDP explicitly remove the labels when this happens. The behavior here
is the same as LDP. 

>   Also needs to be specified.

Loa you lost me here what are you referring to ? Do you expect a loose 
segment to stay alive while the explicit part is down ? to what end?
Modification is done at the head end only with independent paths.

> checked but do we have the same problem for RSVP-TE?

Is your comment on the modify draft ?

> changing will be reflected in the LSDB used to calculate the 

Actually my statement here was correct. The database may change but unless
the LSP path breaks there is no need move a strict explicit route path.
Now you might want to optimize a path after a LSDB change and using 
the modify is a good way to do this.

Sincerely,
Don Fedyk 
Nortel Networks
[email-masked]
Ph: 978-288-3041

---

From: "Loa Andersson" <[email-masked]>
Date: Thu, 12 Apr 2001 16:04:24 +0200

Don,

do I understand you correctly that the draft is applicable only in
the situation where you have a strictly routed LSP ingress to egress?
If so I rest my case, but I also fail to see why we need the draft.
Just "locally" set up your alternate paths, signal that the traffic
will be sent on the new path, switch over the traffic and tear the
old path down. Nothing modificational (is ther such a word?) about
it.

/Loa

---

From: "manoj juneja" <[email-masked]>
Date: Wed, 25 Apr 2001 15:33:07 -0700

Hi Don/Loa/Prem,

       Today we got the mail of making the draft "draft-ietf-mpls-crlsp 
-modify-03.txt" as a proposed standard. Should not you people feel that the 
restriction that modification of CR-LSP is only applicable to strictly 
routed hops should be addressed in the draft prior to making it as a RFC. I 
think this is a major restriction and should be addressed in the scope of 
the document.

Regards,
manoj.

>From: "Loa Andersson" <[email-masked]>
>To: "Sharma Prem" <[email-masked]>
>CC: 'Don Fedyk' <[email-masked]>,  manoj juneja 
><[email-masked]>, [email-masked]
>Subject: Re: Valid Race Condition related to draft "draft-ietf-mpls-crlsp 
>-modify-03.txt"
>Date: Mon, 23 Apr 2001 13:05:32 +0200
>
>All,
>
>some comments to this discussion.
>
>I agree with Perm, if the draft is only applicable to LSPs where every
>node is explicitly routed, that needs to be explicitly state early in
>the draft. Also know from some offsets communication that "the
>explicit routed only" approach  is under some debate.
>
>Given that we can have LSPs where other constraints are important, I
>would
>be interested in combining dynamic routed CR-LSPs (routed on other
>constraints than explicit nodes), with one explicitly routed node,
>e.g. for performance measurements. I would also be interested to be
>able to make those  measurements at different places, a reason for
>changing (modifying) the LSP, drop one explicitly routed node and
>replace with another.
>
>I'm not concerned over have the loosely routed part of an LSP staying
>alive of the strictly routed part goes away :-), but given that I can
>retry if the a node in the loosely routed part of the LSP NAK a
>request,
>but not if an explicitly routed node does it. Need to distinguish
>between
>cases. Of course this is not a problem if explicit routed only.
>
>It is not only CR-LDP that sets up CR-LSPs, it is much more common to
>do so by RSVP-TE, hence my reflection on the need to something for
>RSVP-TE.
>
>/Loa
>
>
>
>--
>Loa Andersson
>Chief Architect,

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Apr 2001 19:34:10 -0400

Manoj

This thread has gone full circle. Just because the draft is 
most useful for CR strictly routed LSPs does not mean it is 
harmful to loose LSPs. 
If it were up to me I would put a question any wide spread use of
loose LSPs. These LSPs are operational headaches. The more 
you add the more provisioning you have to change should 
your network change. One of the benefits of the modify draft 
was to make CR strictly routed LSPs less of a an operational 
headache and an even better option than loose LSPs.
But the question is the draft only applicable to Strict LSPs?
My answer is no in fact if you wanted to modify the explicit 
part of a strictly LSP this feature would work and must work without
any race conditions (which was the original objection). 

Any implementation of the modify will have a knob to turn on 
or off the modify so if you don't want the feature don't use it.

Don

> From: manoj juneja [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 6:33 PM
> To: [email-masked]; [email-masked]
> Cc: Fedyk, Don [BL60:2868:EXCH]; [email-masked]; [email-masked]