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

From: David Charlap <[email-masked]>
Date: Mon, 14 Oct 2002 17:16:57 -0400

Manikantan Srinivasan wrote:
 >
 > 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.

It is not sufficient.  In order to uniquely identify an RSVP-TE LSP, you
need no fewer than five values:
	Tunnel endpoint (egress) address (in SESSION object)
	Tunnel ID (in SESSION object)
	Extended Tunnel ID (in SESSION object)
	Sender (ingress) address (in SENDER_TEMPLATE/FILTER_SPEC object)
	LSP ID (in SENDER_TEMPLATE/FILTER_SPEC object)

Any implementation that makes assumptions about these values is broken.
The existing MPLS MIBs (LSR and TE) do not contain enough information
to cover all of RSVP-TE's capabilities.  For instance, the extended
tunnel ID does not have to match the sender address (it could also be
zero).  And one tunnel (defined by the three values in the SESSION
object) may contain multiple LSPs, each with its own separate LSP ID.

If you don't permit one tunnel to have separate LSPs, then you
effectively eliminate SE style and all of the useful features that it
offers.  You also drasticly reduce the maximum number of LSPs that can
be created between two endpoints.

-- David

---

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

Dear David

Thanks for your mail. 

I used the Tunnel/LSP interchanged and hence I used
Tunnel ID equal with LSP ID. I believe, between an ingress 
and an egress, a LSP/Tunnel can be uniquely identified and 
it is called as LSPID/Tunnel ID.

From the RSVP-TE definitions, I agree, a Tunnel can contain
several LSP-IDs. A Tunnel ID is different from LSP IDs,
and hence we need both Tunnel ID and LSP ID to uniquely identify
the LSP.

Regarding Extended Tunnel ID (in SESSION object), I agree from your
clarification, that this need not be the ingress address. Might be zero.
But if this is non-zero, can we assume that it will be sender IP Address?

I assume that the extended Tunnel ID is either zero or the sender IP
Address.

If the extended tunnel id is same as sender IP address, then we don't 
require this right? 

Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt
be extended to contain the 5 tuples you have mentioned?

As you rightly said, the current MIBs does not have the support for
the 5 tuples to determine a unique LSP in RSVP-TE context. Do you
think it as worthwhile to add these in the MIB for total solution?

best regards
mani

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of David
> Charlap
> Sent: Monday, October 14, 2002 2:17 PM
> To: IETF MPLS List
> Subject: Re: Comments for draft-vijay-mpls-rsvpte-lspsubobject-00.txt
> 
>

---

From: David Charlap <[email-masked]>
Date: Mon, 14 Oct 2002 18:32:53 -0400

> But if this is non-zero, can we assume that it will be sender IP Address?

According to RSVP (RFC 2205) and RSVP-TE (RFC 3209), you can't.  The 
extended tunnel ID may be any value that uniquely identifies the sender. 
  By convention, the sender's IP address is used, because that's the 
easiest way to guarantee uniqueness.

In actual practice, I think it's safe to assume that non-zero values 
will match an IP address on the sender node.  I don't know if it's safe 
to assume that it will match the address used in the SENDER_TEMPLATE 
object, however.

> be extended to contain the 5 tuples you have mentioned?

I haven't read the draft very thoroughly yet, but I think extended 
tunnel ID should be present in the LSP subobject.  Otherwise the draft 
will impose new restrictions on the rest of RSVP-TE.

> think it as worthwhile to add these in the MIB for total solution?

This has been discussed in the working group on many occasions in the past.

The group's consensus is that nobody (or almost nobody) will want to use 
and extended tunnel ID that differs from the sender address, so there's 
no need to accommodate this feature in the MIB.

I disagree, but mine is a minority opinion.  I doubt anybody will be 
changing the MIB at this point, especially since it's a key field that 
would have to change.

If you think this is an important thing to have in the MIB, I think the 
best thing to do is to implement a private MIB in addition to the 
standard one.  Your private one can accommodate the extra key field.

-- David

---

From: "Manikantan Srinivasan" <[email-masked]>
Date: Mon, 14 Oct 2002 16:19:10 -0700

Dear David

Thanks for your replies.

Yes, an enterprise MIB is a good suggestion to use if the
Extended tunnel id is different from the Sender's IP Address.
and I would take that way.

Thanks again.

regards
mani

> Sent: Monday, October 14, 2002 3:33 PM
> To: IETF MPLS List