Subject: RE: Doubts about MPLS-TE Mib

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 30 Jul 2001 10:18:25 -0400

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

         --Tom

>Hope this is more clear
>Thanks
>Apratim
>
>         ----------
>         From:   Thomas D. Nadeau[SMTP:[email-masked]]
>         Sent:   Monday, July 30, 2001 7:08 PM
>         To:     Apratim Mukherjee; [email-masked]'
>         Subject:        RE: Doubts about MPLS-TE Mib
>
>         At 07:41 PM 7/26/2001 +0530, Apratim Mukherjee wrote:
>         > > Hi ,
>         > >
>         > > Thanks for the clarifications . But a few doubts persist ...
>         > > >2. the object mplsTunnelIngressId is defined to be used as the
>         > > >ExtendedTunnelId .
>         > >
>         > >          Yes.
>         > >
>         > > >But then where will the SenderTemplate object's
>         > > >Sender IP address come from ?
>         > >
>         > >          EgressTunnelId.
>         >First , do you mean EgressLSRId by this ... but this could only be
>         >IngressLSRId if anything .
>         >
>         >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.
>
>         >I realise that this question has been asked before but i could not
>find any
>         >satisfactory conclusion to a thread that speaks about this .
>         >One of the promising threads ends on this note from David Charlap (
>from the
>         >archives :
>http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
>         > >Then there is potential for conflict between the TE MIB and
>RSVP-TE
>         > >itself. ...........
>         > >I can only assume that the TE MIB was based upon the features of
> >RSVP-TE
>         >that are commonly in use, and can not fully accomodate all of >its
>features.
>         >If someone build a router that supports multipoint-to-point >LSPs
>using
>         >RSVP-TE, the TE MIB will have to be updated, or that
> >implementation will be
>         >unable to properly represent these kinds of LSPs >using it.
>         >
>         >Is this then an unresolved problem ?
>
>                  I don't think that this is still a problem. The current
>indexing
>         comes right from the RSVP/CR-LDP specifications, so if there is
>         a problem, those protocols will be broken too.
>
>                  --Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 30 Jul 2001 14:38:02 -0400

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.
[email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 30 Jul 2001 16:18:51 -0400

>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

         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.

>At transit and egress nodes, since there two fields in the protocol, the MIB

         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

---

From: David Charlap <[email-masked]>
Date: Mon, 30 Jul 2001 17:04:10 -0400

"Thomas D. Nadeau" wrote:
>> value) extended tunnel id allows sharing between LSPs provided their
>> Session id is the same.
> 
> sessions will not be signaled.

No.  This is not at all true.  There is _NOTHING_ in RSVP that requires
every LSP to be in a separate session.  Multiple LSPs sharing a single
session is the mechanism by which resources are shared.  It is this
precise mechanism that allows make-before-break to work.

Setting the extended tunnel ID to zero is perfectly legal.  It is the
mechanism by which multiple LSPs may share resources if they originate
from different routers.

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

I would strongly disagree with you here.  RSVP-TE has this mechanism,
which makes it relatively simple to support many-to-one LSPs.  Would you
rather someone creates a new, and incompatible mechansim for this
instead?

It is well known that the MIB does not support all of the features of
RSVP-TE.  This discussion has gone around this group several times.  It
is clear that the authors of the MIB are not interested in being able to
represent every kind of setup that RSVP can legally get into.  That's
their choice, of course, but it doesn't mean that RSVP's specification
should now be changed in order to accomodate it.

That's like wanting to redesign a car for a top speed of 85, because the
speedometer doesn't go any higher.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 30 Jul 2001 19:19:38 -0400

> Aha.  That is certainly an answer.

Unfortunately, there is no RSVP-TE MIB, even in draft form.

True, you can take the MIB from RFC 2209 and tweak it for the new fields
used by RSVP-TE, but you necessarily end up with a private MIB, not a
standard.

A while back, I asked about an RSVP-TE MIB and was told that it is
unnecessary because the MPLS TE-MIB presents all the same information. 
Unfortunately, this turned out not to be true.

-- David

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 30 Jul 2001 17:11:50 -0400

Tom,

> having the same tunnel resource entries shared by multiple tunnel

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]

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

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

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.

> distinctively. RSVP TE uses them synonymously to function

As above, it doesn't.

Adrian

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 31 Jul 2001 08:30:17 -0400

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