The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Mar> msg00256



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Feedback regarding draft "draft-ietf-mpls-crlsp-modify-03.txt"

  • From: "manoj juneja" <manojkumarjuneja@hotmail.com>
  • Date: Wed, 21 Mar 2001 12:53:53 -0700
  • Cc: gash@att.com, petera@NortelNetworks.com, jamoussi@NortelNetworks.com, fedyk@NortelNetworks.com, skalecki@NortelNetworks.com, lili@ss8networks.com, ylee@irislabs.com
  • X-OriginalArrivalTime: 21 Mar 2001 19:53:53.0678 (UTC) FILETIME=[A83FD2E0:01C0B240]
  • X-Originating-IP: [38.204.3.195]

Hi All,
        I have certain comments regarding draft
"draft-ietf-mpls-crlsp-modify-03.txt".

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

Please comment on this.

Regards,
manoj.




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