Subject: Few questions related to MPLS-TE-MIB: tunnels vs tunnelInstances

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 19 Oct 2001 13:21:02 -0400

Hi! I have few comments/questions related to the MPLS-TE-MIB.
	Your help will be appreciated.

	Q1. mplsTunnelTable represents two kind of concepts:Tunnel & 
	TunnelInstance. 
	
	It may make sense, to keep some of the attributes associated
	with a tunnelInstance same, if they belong to the same tunnel.

	Is my assumption correct ? Is so, should there be two tables
	: mplsTunnelTable & mplsTunneInstanceTable ?

	Q2. Specifically, what is the scope (tunnel or tunnelInstance)
	of the following attribute ?
	
		a) mplsTunnelName - Should this be same for all tunnel 
		instances, within a tunnel ?
	
		b)mplsTunnelIfIndex - Do we have one ifIndex per 
		tunnel or one ifIndex per tunnelInstance ? 

		[Does it make sense to create one ifIndex per 
		tunnelInstance ???]

	Q3. tunnelInstancePriority is valid ONLY within the context of 
	a tunnel. 

	Does this mean that two tunnelInstances that belong to two
	 _different_ tunnels (different tunnelIndex) should not be used
	 for load sharing even if the -IngressLSRId , EgressLSRId & 
	tunnelInstancePriority are same?
	
	* It may be helpful to add a little more text to the draft,
indicating 
	when should the user create a new tunnelInstance, instead of
	new tunnel.
	
	Thanks,
	sanjay

---

From: "abhay" <[email-masked]>
Date: Sat, 20 Oct 2001 13:08:21 +0530

Sanjaya,
Please read my comments below...

> : mplsTunnelTable & mplsTunneInstanceTable ?

Tunnel Instance will be the same value for secondary tunnels created by the initial primary tunnel

No need for 2 tables,let it be simpler,so one can have implementation freedom

> [Does it make sense to create one ifIndex per 

a) For the mplsTunnelName we can assign it to the first primary tunnel,
    Then we can have a formula like this
    For this tunnel ID,all these instances....ah here is the name.
    Name can be used to administration purposes to atleast know something distinct for u to remember,about
    where the tunnel is heading

b) Okay,now 1) Assume that you when u request a mpls tunnel as an interface,then 
the interfaces MIB(rather a requirement to assign unique Interface Indices to it)
However T.E MIB has the tunnel instance for which u can have only a single ifIndex for a primary tunnel
and then the instances can use the same ifIndex

c)You can have multiple inteface indices per tunnel instance.

> Q3. tunnelInstancePriority is valid ONLY within the context of 

1) Priority can be used to choose which tunnel to route traffice in case of primary failure.

> tunnelInstancePriority are same?

1) We can use different tunnels to the same destination for load balancing,but generally traffic load balancing is classified
and we need a fair queuing for allowing traffic to flow on the different tunnels id's on a percentage basis.However,as RFC for
Requirements for Traffic Engineering recommends reservation of bandwidth.Care should be taken again for not to underutilize
or overutilize traffic tunnels.Generally tunnel instances for load balancing would be a better idea,all of them usually have the same
priority as the primary and also we do not need load balanced tunnels to be pre-empted.

> when should the user create a new tunnelInstance, instead of

1) One way of dealing with the creation of the mplsTunnelInstance is how you want your tunnels to behave.

Please Read below:
1)  You can configure tunnels to have backup paths,with/without switchover /switchback mechanisms,in these cases
it is wise to have the tunnel instances,you can know which primary tunnel  has gone DOWN,and then the immediate
expectation is to know the next primary tunnel instance which is Being Used to maintain traffic flow.Here is the need
to create the instance.
Also,when u implement switchover and switchback ,tunnel instances are easily used to switchover and switch back.
However,if u want local protection paths,then u can add some additional indices one is local path ID,local primary Path ID
these entries can allow local paths to know about primary paths and primary paths to know about Locally spawned Tunnels.
This is for Local Paths which start at the MID point of the tunnel.

Thanks,
Abhay