The MPLS WG Archive

["manoj juneja" <manojkumarjuneja@hotmail.com>]

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" <jamoussi@nortelnetworks.com>
>To: 'manoj juneja' <manojkumarjuneja@hotmail.com>,    "'mpls@UU.NET'" 
><mpls@UU.NET>
>CC: "'gash@att.com'" <gash@att.com>,    "Peter Ashwood-Smith" 
><petera@nortelnetworks.com>, fedyk@nortelnetworks.com,    
>skalecki@nortelnetworks.com,    "'lili@ss8networks.com'" 
><lili@ss8networks.com>,    "'ylee@irislabs.com'" <ylee@irislabs.com>
>Subject: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp   
>       -modify-03.txt"
>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:manojkumarjuneja@hotmail.com]
>Sent: Wednesday, March 21, 2001 6:06 PM
>To: mpls@UU.NET
>Cc: gash@att.com; Ashwood-Smith, Peter [CAR:CS0I:EXCH]; Jamoussi, Bilel
>[BL60:2868-M:EXCH]; fedyk@nortelnetworks.com;
>skalecki@nortelnetworks.com; lili@ss8networks.com; ylee@irislabs.com
>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
>

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