The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

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

         Yes.

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

         Okay.

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

         The merging permitted flag is only a suggestion to the signaling
that the operator allows merging.  It is up to the implementations to
explicitly invoke resource sharing, even if the MIB requests that they
do so. In cases that you suggested above that do not make sense, the
implementation is free to reject such bogus requests. I do agree however,
that it would help to outline the different cases so that implementations
might be made more straight-forward.

>4. Does the TE MIB specify a standard way to configure bi-directional
>tunnels using the tunnel table ?.

         No, there were no specific methods defined by the working group
at the time, thus none were specified in the MIB.

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

         I will try to do so during the IESG review where such things are 
being
done.

         --Tom



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



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