Subject: RE: Doubts about MPLS-TE Mib

From: Apratim Mukherjee <[email-masked]>
Date: Thu, 26 Jul 2001 19:41:27 +0530

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

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 ?

Thanks ,
Apratim

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 26 Jul 2001 08:42:49 -0400

At 10:25 AM 7/26/2001 +0530, Apratim Mukherjee wrote:
>Hi ,
>
>I have a few doubts about the MPLS-TE Mib.
>Please note that the doubts are with regards to usage of RSVP-TE as the
>signalling mechanism .
>
>1. There are three similar objects in the mplsTunnelTable ....
>mplsTunnelIndex , mplsTunnelInstance , mplsTunnelPrimaryInstance  .
>  According to my understanding , mplsTunnelIndex is the same as the TunnelId
>in the Session object .
>  But how does mplsTunnelInstance and mplsTunnelPrimaryInstance fit into
>RSVP-Te ?
>  Are they outside the scope of RSVP-Te ?
>  Or do they refer to LspIds of primary and secondary Lsps ?

         We really need to fix the descriptions to include this,
as I have had to explain this about 10 times now. ;) The four
objects come directly from and are required for uniqueness in
RSVP-TE and CR-LDP. Take a look at the session object in RSVP-TE
for example. Three of the objects are required to be unique for
CR-LDP (tunnelInstance = 0 for CR-LDP). You might want to
peruse the archives too, since this question has been asked
numerous times.

         Yes.

         EgressTunnelId.

>3. What is the difference between ARHopTable and CHop Table ?

         The ARHop table stands for "actual route hop table".
This is what returns in the RRO object, and is the
actual path taken by the tunnel. The CHop table stands
for "computed hop" table. This is what the CSPF calculation
spits out and will be (or is trying to be) used to
signal the tunnel. The difference is that the CHop
table is used for diagnostic purposes. If a tunnel
is not being signaled, it is nice to see what the heck
the head is trying to do. When all is working correctly,
the ARHops will be the same as the CHops.

         --Tom

>    Do they refer to incoming and updated EROs ?
>
>Thanks in advance
>Apratim

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 30 Jul 2001 09:38:41 -0400

>be 0 ... then isn't there an indexing problem ?

         Why? 0 is a perfectly valid index.

>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: Apratim Mukherjee <[email-masked]>
Date: Mon, 30 Jul 2001 19:18:50 +0530

Hi Tom ,

Thanks for the clarification .
	>        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 ) . 

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

	>archives :
http://cell.onecall.net/mhonarc/mpls/2001-pr/msg00426.html)
	> >I can only assume that the TE MIB was based upon the features of
>RSVP-TE
	>RSVP-TE, the TE MIB will have to be updated, or that
>implementation will be

	         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: "Feng, Mark" <[email-masked]>
Date: Tue, 31 Jul 2001 16:26:04 -0700

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 3:59 PM
> To: Feng, Mark
> Cc: [email-masked]'
> Subject: Re: Doubts about MPLS-TE Mib
> 
> 
> "Feng, Mark" wrote:
> > 
> > IMO, tunnel Id has "global" significance, within some particular
> > MPLS domain, synonym to well-known ports in classical RSVP. I think
> > that it is unlikely the operator will assign a LSP some tunnel Id
> > without knowing what other potential ingress routers might share
> > the resources.
> 
> If an operator is going to hand-assign tunnel IDs, yes.  And in this
> situation, the operator can choose whether multiple LSPs sharing the
> tunnel ID should share resources or not by directing the 
> switch to use a
> zero or non-zero value for extended tunnel ID
> 
> It is also possible for an ingress router to automatically create LSPs
> based on topology information of some kind.  In which case, the tunnel
> IDs would be automatically generated.  Of course, in this situation,
> resource sharing would be a bad thing, and so a non-zero 
> value would be
> used for extended tunnel ID.
>

I agree fully. What I was trying to say is, if "sharing" is desired, the
operator really needs to have some "global" knowledge of the tunnel IDs;
otherwise, he/she might get a nasty surprise.
 
> > Also, the fact that the egress router is the one who decides what
> > style to use implies that some out-of-band mechanism is used to
> > ensure the proper operation between the ingress routers and the
> > egress routers.
> 
> No.  RSVP has always been egress driven.  The egress router is free to
> try and reserve with any style it wants, and using any amount of
> resources it wants.  This is all perfectly legal and part of 
> the design
> of RSVP.
> 
> Of course, a router that completely ignores the information 
> requested in
> the Path message is one that nobody will be interested in buying.  But
> it does mean that two Paths in the same session, requesting different
> reservation styles and different amounts of resources will 
> not result in
> any kind of self-contradictory state.
> 

I agree with this as well:-). My point was, the egress router needs to base
on some kind of criteria to decide the style. That is outside the scope of
RSVP. Like you said, if the egress router completely ignore the information
in the Path messages, the product might not be that appealing.
 
> > The only reason I can think of to have the tunnel Id and extended
> > tunnel Id is to tailor different needs. For example, there might be
> > some pre-determined mechanism to assign the tunnel Id at each
> > ingress router. If one router decides not to join the sharing,
> > though it is assinged a particular tunnel Id, it can add its own IP
> > in the extended tunnel Id, to exclude itself in the sharing.
> 
> This is one possible scenario.  There are others as well.
> 

I agree again. It is meant for an example.

> -- David