Subject: ?: Question on Resource Sharing w.r.t mpls-te-mib-08

From: "Dominic-Savio, Patrick" <[email-masked]>
Date: Mon, 11 Feb 2002 10:50:17 -0500

Hi,
I am re-sending a few questions I had on the TE MIB again (as I did not get
any response the first time around). I would appreciate any helpful
response.
I tried searching the archives for an answer but I could not find anything
relevant to the specific questions I've raised.

Thanks
-patrick. 

-----Original Message-----
From: Dominic-Savio, Patrick
Sent: Monday, February 04, 2002 10:53 AM
To: [email-masked]'
Subject: Question on Resource Sharing w.r.t mpls-te-mib-08

Hi,
The description for mplsTunnelResourcePointer indicates that 2 or more
segments can share resources if the user specifies the same value for this
object for different tunnels.

The description for mplsTunnelSessionAttributes:mergingPermitted indicates
that this is used for reducing resource overhead on downstream transit
routers.

I'm a bit confused about how these two parameters are related (if they are
indeed related). 
First off I'm assuming that mplsTunnelSessionAttributes:mergingPermitted
corresponds to the "SE Style desired" flag of the RSVP Session Attribute
Object [RFC3209] when RSVP is used for signalling. If this is the case then
this bit does not (quote from TE MIB:) "permit transit routers to merge this
session..." it is
only an indication to the egress LSR requesting SE style of reservation.
In any case could you confirm that the
mplsTunnelSessionAttributes:mergingPermitted value does correspond to the
"SE Style desired" flag in RSVP.

If my above assumption is correct then (again with RSVP), say the user sets
up a couple of tunnel instances and requests SE style reservation (using the
mergingPermitted flag) for them. Now, if the egress LSR honors the request
and responds with a SE STYLE reservation, shouldn't the ingress LSR (along
with the transit LSRs) share resources between these two instances ?.
So, receiving of an SE STYLE reservation by itself should indicate to the
ingress LSR that resources should be shared. What then is the purpose of
indication of resource sharing by specifying the same value of
mplsTunnelResourcePointer on the ingress LSR?, this appears to be redundant.

Thanks
-patrick.

---------------------------------------------------------
Patrick Dominic-Savio

<-----Disclaimer Stuff----->

This e-mail and any attachments are confidential. If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachment, use the contents for any purposes, or disclose the contents to
any other person: to do so could be a breach of confidence.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 11 Feb 2002 11:05:04 -0500

Sorry for the delay. I was traveling last week.

>"SE Style desired" flag in RSVP.

         When using RSVP for signaling, I believe that is correct.

>mplsTunnelResourcePointer on the ingress LSR?, this appears to be redundant.

         The bit on the tunnel indicates that sharing is permitted, but the
resource pointer allows you to specify which tunnels to share resources with
(as opposed to any tunnels with resource sharing bit enabled). For example, if
you wanted a bi-directional pair of tunnels to share resources together, 
but not
with other tunnels, you could specify that configuration this way.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Dominic-Savio, Patrick" <[email-masked]>
Date: Mon, 11 Feb 2002 14:58:27 -0500

Tom
Thanks for the response, I do have a couple of follow-up
questions/suggestions:
1. The description for mplsTunnelSessionAttributes:mergingPermitted in the
draft is a bit misleading in that the reducing of resource overhead is not
only applicable to downstream transit routers but is also applicable to the
egress interface of the Ingress LSR.
2. For some of the objects in the MIB table you have actually referenced the
corresponding RSVP object explicitly. Can you do the same if for
"mergingPermitted" ?. You might want to reference the "SE Style desired"
flag of the RSVP Session Attribute for this. Given that the TE MIB object
name is not the same as the RSVP name you can avoid any confusion by
explicitly stating the relationship in the description.
3. What does it mean (for a set of originating tunnel instances) when the
mergingPermitted bit is set but their resource pointers are not the same ?.
Should you share resources or not ?. Also, what does it mean when
mergingPermitted is disabled but resource pointers are shared. (I think it
will help if you add your responses to the descriptions of these objects.)
4. Does the TE MIB specify a standard way to configure bi-directional
tunnels using the tunnel table ?. If not are there any real scenarios where
this "sharing of resources by specifying the same resource pointer" concept
can be used?. I guess what I'm getting at is that if there is no clear
reason for having the shared-resource-pointer then we might as well not
support it and this will help avoid any confusion with the mergingPermitted
flag. When you have two objects with overlapping controls it causes a bit of
a confusion. The other option is to clearly document the behavior of
resource sharing on the Ingress LSR with all possible combinations of the
two objects in question, if some combinations are not valid that can be
specified too.

Thanks 
-patrick.

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Monday, February 11, 2002 11:05 AM
> To: Dominic-Savio, Patrick
> Cc: [email-masked]'
> Subject: Re: ?: Question on Resource Sharing w.r.t mpls-te-mib-08
> 
> 
> 
> >The description for 
> mplsTunnelSessionAttributes:mergingPermitted indicates
> >First off I'm assuming that 
> mplsTunnelSessionAttributes:mergingPermitted