Subject: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt

From: "Manikantan Srinivasan" <[email-masked]>
Date: Mon, 14 Oct 2002 14:04:09 -0700

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 : [email-masked]
------------------------------------
Please do visit us at:

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

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Wed, 16 Oct 2002 11:15:40 +0530

Mani,
The L bit processing would be no different from the normal processing in
other subobjects. The ingress IP address in the LSP subobject is the address
of consideration in this subobject.Anyway, to make it clear and explicit it
can be incorporated in subsequent revisions.

Regarding the sending of path message through the tunnel, I think this is
more of an implementation issue. The ingress of the tunnel, which processes
the LSP subobject, would identify that the path message should be
transparently sent to the egress without creating path state in intermediate
nodes.The tunnel which is like an IP interface, would be the outgoing
interface for reaching the egress. I would add an explicit mention of this
in subsequent revisions of the draft.

Thanks and Regards,
Vijay

-----Original Message-----
From: Manikantan Srinivasan [mailto:[email-masked]]
Sent: Tuesday, October 15, 2002 9:55 PM
To: Vijayanand C - CTD, Chennai.
Cc: [email-masked]; David Charlap
Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt 

Vijay

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

The ERO processing for the LSP subject needs clarification. Can this
be added in your draft, how to process the ERO object in case of Strict
ERO, Loose ERO etc.,

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

Can this be explained as well. I am not sure to which FEC, this path
message (data) will be mapped to?

Because the initial tunnel/LSP is created for a specific FEC.
Can this be added in your draft?

best regards
mani

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Thu, 17 Oct 2002 12:01:46 +0530

Mani,
Regarding the sending of path message over the tunnel, how else do you think
it can be done, given that it has to be sent transparently without creating
path state. I am not sure how its done over FA-LSPs. Is there any problem in
treating the tunnel as an IP interface for the control plane and sending
over it ?

Regards,
Vijay

-----Original Message-----
From: Manikantan Srinivasan [mailto:[email-masked]]
Sent: Tuesday, October 15, 2002 9:55 PM
To: Vijayanand C - CTD, Chennai.
Cc: [email-masked]; David Charlap
Subject: RE: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt 

Vijay

best regards
mani