The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

>Tom, am I being dense?
>In the protocol (RSVP) we have
>- source address in Sender Template
>- extended tunnel id in Session.
>
>Extended tunnel id may be set to the source address to reduce the scope for
>resource sharing between LSPs that might (intentionally or accidentally) have
>the same other Session fields.

         That is the first that I have ever heard of resource sharing
being accomplished that way. This seems haphazard and vendor-specific
at best. If you want to share tunnel resources, do so explicitly by
having the same tunnel resource entries shared by multiple tunnel
entries.

>Set to zero (or some other NetAdmin controlled
>value) extended tunnel id allows sharing between LSPs provided their 
>Session id
>is the same.

         That is not a MIB issue. If the admin does what you describe,
then RSVP will not work, period. You will have mis-configured
your network because you will have non-unique sessions, and thus
sessions will not be signaled. This is not a MIB issue.
I think that the BCP here is to do what the RSVP-TE specification
suggests (and should have made mandatory, IMHO). That is, to set the
ingress LSR id as the extended id.

>So...
>At the ingress we need to allow control of the extended tunnel id so that
>NetAdmin can decide what level of resource sharing is allowed.  In some
>implementations this will not be an option (extended tunnel id will always be
>set to source address), but other implementations will allow this control.
>At the ingress one could argue that the source address should not under 
>NetAdmin
>control since you shouldn't be able to attempt impersonation, but in the case
>where a node has multiple addresses, it would be reasonable to allow the value
>to be controlled.
>
>At transit and egress nodes, since there two fields in the protocol, the MIB
>should display both.

         You can see both fields at transit nodes: look at the tunnel
entry and the RSVP MIB for that session.

>So the requirement is for two distinct fields.

         I don't see it as a requirement to see both fields
distinctively. RSVP TE uses them synonymously to function
correctly.

>How does this map to the current MIB?

         The LSR ID is mapped into the extended tunnel ID field.
If you want a different value in that field, change
the router's LSR ID so that all tunnels will utilize that as
their LSR ID. Using something that is non-unique (i.e.: not
the router's LSR id) is just asking for trouble.

         --Tom