The MPLS WG Archive

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

At 05:11 PM 7/30/2001 -0400, Adrian Farrel wrote:
>Tom,
>
> > >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.
>
>This is a protocol issue that I am exposing.  I'm trying to show 
>(unsuccessfully
>:-) that the two quantities 'source address' and 'extended tunnel id' are
>distinct within the protocol.  From this will follow the need for two separate
>fields in the MIB.
>
>Resources may be shared within the network by LSPs that belong to the same
>session (where the Style is Shared Explicit etc., etc.).  "Ingress nodes that
>wish to narrow the scope of a SESSION to the ingress-egress  pair  may  place
>their  IPv4 address here [Extended Tunnel Id] as a globally unique 
>identifier."
>[draft-ietf-mpls-rsvp-lsp-tunnel-08, 4.6.1.1]

  I stand corrected. After some though and research, I think that
  you are right. I don't believe that anyone that I know of has
  implement this, including the 20 or so implementations of the
  MPLS-TE-MIB that are out there, which is why it never came up.
  Anyway, would you agree that it would suffice to just add another
  object to the tunnel table for the session source address?
  We can specify in the description that the LSR/Operator can then
  pick this field or the LSR ID for the extendedTunnelID according to
  the rules of RSVP. I believe that after either the source addr/extended
  tunnel id are chosen, that a unique RSVP session can be identified
  using the existing indexing, since in the end, sessions will be
  signaled with the four indexes (plus the protocol ID field). Thus,
  the existing indexing of the table does not need to change.

         --Tom