The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

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]

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

Well, talking of vendor-specific issues... :-)
RSVP _should_ work.

The source address is not part of the session id.  It is in the Sender Template.
It is completely legal to have identical session ids from distinct ingress
points - this is how (the mythical?) LSP merge works.  It is completely legal to
have two LSPs with identical session ids from the same ingress point - this is
how make-before-break works.

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

But it doesn't suggest it, per se.  It suggests it _if_ you don't want to allow
LSP merge.  Why would you want to prevent LSP merge using this technique
(although there are other ways of achieving it)?

Seen another way, if the extended tunnel id was intended to be always the same
value as the source address, why introduce the field in RSVP-TE (it did not
exist in RSVP)?  If it has no value let's drop it from the protocol; but it does
have value.

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

Aha.  That is certainly an answer.

But what about the other fields that overlap between RSVP and RSVP-TE?  We don't
want to move them out of the TE-MIB.

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

As above, it doesn't.

Adrian