The MPLS WG Archive

["Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>]

Mani,
Thanks for your comments.

1) Regarding the L Bit - This could be set. For instance, if the previous
node of the tunnel ingress is not mentioned in the ERO then the node before
that can still route the path message to the tunnel ingress looking at the
tunnel ingress address if the L bit is set.

2) Regarding the path message sent over the tunnel- I would say that the
path message would be sent over the existing tunnel as if it were an
interface, transparent to the intermediate nodes.It would not create path
state in the intermediate nodes. I did nt mention it explicitly though.

3) Reg the parameters to identify the tunnel , there was some confusion on
the need for a 5 th parameter. But the LSPID is definitly needed as David
pointed out. Some discussion has happened regarding the significance of the
extended tunnel ID. I thought it would not be necessary since it seemed that
extended tunnel ID would be either zero or sender IP address from the
discussions in the mailing list. But Davids' argument may need to be
incorporated from the robustness angle.

Regards,
Vijay

-----Original Message-----
From: Manikantan Srinivasan [mailto:manis@futsoft.com]
Sent: Tuesday, October 15, 2002 2:34 AM
To: mpls@UU.NET
Subject: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt 


Hello Vijay

draft-vijay-mpls-rsvpte-lspsubobject-00.txt, is a good
contribution, which helps to create TE-LSPs with pre-existing
LSP/tunnels along the intended LSP Path.

I have the following comments to your draft.

1) The "L" bit in the LSP sub object must not be set
at all times, since utilizing a tunnel, is a strict hop.

Reason, When the new LSP is created, we would
like to leverage the existing tunnel.

Can you indicate in your draft that the L bit will
not be set at all times?

2) In the draft we have
"...The LSP sub object
   would be removed from the ERO by r1 and the Path message would be
   then sent to r3 provided the bandwidth constraints of the LSP L1 are
   not violated by admitting the new LSP. At r3, the node would
   recognize that R3 is adjacent to it and propagate the path message
   to it. "

   If the LSP sub object is removed by r1, how will r3, know that
   it is a valid LSP setup request received.

   I believe, the LSP sub object can be removed from the ERO List,
   only by the egress node in the tunnel.

   Using your LSR topology example, I believe,  r1, should pass
   the LSP sub object when it forwards the LSP setup request (Path Message)
to r2.
   r2, can identify that is part of an existing tunnel, which
   is mentioned in the ERO object - "LSP sub object" and forward
   it towards the tunnel's destination. At r3, the ERO will be removed
   by r3 (r3 knows it is part of the tunnel, and it is the end of the
tunnel)
   and then r3 can forward the path message to R3.

3) Can you explain why do we need both TunnelID and LSPID in the LSP
   sub object? The Ingress, Egress Addresses and the TunnelID is sufficient
   to uniquely identify a tunnel.

best regards
mani

====================================
Manikantan (Mani) Srinivasan
Future Communications Software
4300 Stevens Creek Blvd, Suite 187,
San Jose, CA, 95129.
Phone : 408 243 3887 x 107
Fax   : 408 243 0772
email : manis@futsoft.com
------------------------------------
Please do visit us at:

Next Generation Networks,
Marriott Copley Place,
Boston, Massachusetts, USA.
Booth No. 126
October 14-18, 2002.
====================================