The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.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.  Set to zero (or some other NetAdmin controlled
value) extended tunnel id allows sharing between LSPs provided their Session id
is the same.

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.

So the requirement is for two distinct fields.

How does this map to the current MIB?

mplsTunnelIngressLSRId is, rightly, an index into the mplsTunnelTable since it
defines the source which is part of the identifier of the LSP.  Despite the
comments in the MIB, I think this field maps to the source address in the Sender
Template.

We need another field for extended tunnel id that should (possibly) be an index
as well.

Adrian

PS

--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com

----- Original Message -----
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
To: "Apratim Mukherjee" <ApratimM@netbrahma.com>
Cc: <mpls@UU.NET>
Sent: Monday, July 30, 2001 10:18 AM
Subject: RE: Doubts about MPLS-TE Mib


> At 07:18 PM 7/30/2001 +0530, Apratim Mukherjee wrote:
> >Hi Tom ,
> >
> >Thanks for the clarification .
> >         >>But , this is also being used as extended tunnel id , in which
> >case it COULD
> >         >>be 0 ... then isn't there an indexing problem ?
> >         >        Why? 0 is a perfectly valid index.
> >What i meant here is that if extended tunnel id is 0 , then IngressLSRId is
> >0 (If Extended Tunnel Id is ALWAYS same as IngressLSRId). If IngressLSRId is
> >0 , then Sender Template ip address is 0.0.0.0  , if this is same as Ingress
> >LSR Id  . This is wrong since information about the sender Ip address is
> >absolutely essential . I  think there shoud be a separate field for Extended
> >Tunnel Id as this has no necessary relation with IngressLSRId . ( They only
> >MIGHT be same ) .
>
>          This is an artifact of how the protocol works,
> and the MIB models the protocols. I personally think
> that the protocol should have made the Ingress
> LSR Id mandatory for the reason you stated, but it
> didn't. Fortunately, all of the implementations I know
> of to insert the loopback address in this field, so
> operationally there should not be any problem
> (and have not been from what I have heard/seen).
>