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

From: "Bilel Jamoussi" <[email-masked]>
Date: Thu, 22 Mar 2001 09:15:08 -0500

can you clarify why the next hop changes? is it node failure? loosely routed
lsp with no pinning?

Bilel.

-----Original Message-----
From: manoj juneja [mailto:[email-masked]]
Sent: Wednesday, March 21, 2001 6:06 PM
To: [email-masked]
Cc: [email-masked]; Ashwood-Smith, Peter [CAR:CS0I:EXCH]; Jamoussi, Bilel
[BL60:2868-M:EXCH]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Valid Race Condition related to draft
"draft-ietf-mpls-crlsp-modify-03.txt"

Hi All,

   Please comment on the following :

        If the LSP modification is in progress and in the meantime the
next hop for the same LSP changes then should the modification
procedure be aborted ?

Regards,
manoj.

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

---

From: "manoj juneja" <[email-masked]>
Date: Thu, 22 Mar 2001 11:59:28 -0700

Hi bilel,

       I have couple of points in mind regarding crlsp-modift-03.txt
draft.

First Point :
          From the protocol point of view, we have a valid next hop
change procedure defined for an already established LSP. So, there has
to be proper interworking of various procedures in the protocol. It may
happen that when u have sent the label request message for modifying
the characteristics of an LSP, the next hop change trigger can come for
an already establsihed LSP (for which the modification is in progress).
We should provide this valid race condition in the draft and the
solution for the same in draft. The next hop of an active LSP can
change due to any reason.

Also, Can u please comment on the following :

Second Point :

LSP modification should be limited to modification in bandwidth and
holding priority of already active LSP. I don't foresee any application
for re-route capability. This capability can be implemented in some other 
way also.

If we compare the modification procedures to already exisiting
modification procedures in various call control protocols viz. ISDN,
ATM and GSM, these protocols allow in bandwidth modification only.
Those procedures don't allow for re-routing. For re-routing u have to
establish another path which is treated as a complete new request.
Is there any specific reason why re-routeing has been thought of as a
part of modification in MPLS ?
I think we should define messages like LSP modify Request and LSP
modify complete/LSP modify reject for modification. These modify
messages should take the same signalling path as of original LSP
establishment messages.
Is not everbody overloading the Label Request/Label Mapping messages
for everything (i.e. keeping the same set of messages even for O-UNI) ?

Third Point :

As per the draft, after the modification procedure is complete, the
ingress node will initiate the LSP release procedures for the old LSP.
Is there any guard timer running in the intermediate nodes that these
nodes will be receiving the Label Release message from the upstream
node ? I think we should have the guard timer, may be network manager
dependent.

Please comment.

Regards,
manoj.

>From: "Bilel Jamoussi" <[email-masked]>
>To: 'manoj juneja' <[email-masked]>,    "[email-masked]'" 
><[email-masked]>
>CC: "[email-masked]'" <[email-masked]>,    "Peter Ashwood-Smith" 
><[email-masked]>, [email-masked],    
>[email-masked],    "[email-masked]'" 
><[email-masked]>,    "[email-masked]'" <[email-masked]>
>Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp   
>       -modify-03.txt"
>Date: Thu, 22 Mar 2001 09:15:08 -0500
>

---

From: "Don Fedyk" <[email-masked]>
Date: Mon, 26 Mar 2001 09:12:29 -0500

Manoj

Usually the path modification is for TE LSP that are routed via an Explicit
route. This means that they are not affected by next hop changes in IP
routing. If the existing path is torn down due to a failure on the path then
you have a couple of options.

1. Abort any modification and treat as a normal failure.
2. Handle the path release but wait for the new modification path in hope
that it will still be valid.

We have built 1. in the past. 2. is more difficult and a low percentage
success rate.

Don

---

From: "Sharma, Prem" <[email-masked]>
Date: Tue, 27 Mar 2001 19:56:41 -0800

Hi Don,
 
But what about the cases when you have loose hops in the explicit routes and
route pinning is not requested? Can there be a scenario where the arrival of
a next hop change trigger (for a loosely routed hop), while the original LSP
is being re-routed, may potentially lead to race condition? 
 
Thanks.
Prem

 -----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Monday, March 26, 2001 6:12 AM
To: manoj juneja; [email-masked]
Cc: [email-masked]; Peter Ashwood-Smith; Bilel Jamoussi;
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp
-modify-03.txt"

Manoj 

Don 

> From: manoj juneja [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> next hop for the same LSP changes then should the modification 
<http://explorer.msn.com>