The MPLS WG Archive

["Dominic-Savio, Patrick" <Patrick.Dominic-Savio@marconi.com>]

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.

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Monday, February 11, 2002 11:05 AM
> To: Dominic-Savio, Patrick
> Cc: 'mpls@uu.net'
> Subject: Re: ?: Question on Resource Sharing w.r.t mpls-te-mib-08
> 
> 
> 
>          Sorry for the delay. I was traveling last week.
> 
> >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: 'mpls@uu.net'
> >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.
> 
>          When using RSVP for signaling, I believe that is correct.
> 
> >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.
> 
>          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. 
> 


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.