The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

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

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.

> Does the LSP Sub object in draft-vijay-mpls-rsvpte-lspsubobject-00.txt
> 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.

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

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