Subject: RE: Session Attributes

From: "Feng, Mark" <[email-masked]>
Date: Fri, 20 Jul 2001 10:02:31 -0700

See comments below.

> -----Original Message-----
> From: Arumugam R [mailto:[email-masked]]
> Sent: Friday, July 20, 2001 2:22 AM
> To: Rajesh P Jain
> Cc: [email-masked]'
> Subject: Re: Session Attributes
> 
> 
> 
> Hi,
> See inline comments.
> Rajesh P Jain wrote:
> 
> >         Can someone clarify where should we store the 
> Session Attribute Object ?
> 
> ###  It is left to the implementation, but usually kept in the PSB.
> 
> > 
> > 
> >         Also, The draft tells that Session Attribute is an 
> Optional Object. So,
> > Let us consider a case where a Path Message is sent without 
> a Session Attribute
> > Object (As a result, the PSB is set up at all the nodes etc).
> 
> ###  Eventhough it is optional, it is upto the implementation looking 
> for it as a mandatory object.  Coming back to you question if you 
> receive a Path message without a Session Attribute object, 
> you have to 
> allocate a FF style for the flow..
> 

I don't agree with that. The draft does not say what style of reservation
should be used. It is really up to the implementation. Conversely, even if
the sender asks for SE style in the SESSION_ATTRIBUTE object, the receiver
does not have to honor the request. According to the standard, that does not
appear to be a protocol error. In other words, the reservation style is
decided by the receiver.

> > 
> > 
> >         Now, If we send a Path Message (Of Course for 
> Rerouting a Tunnel) with
> > Session Attribute. So, How will the New Path Message 
> compare Session Attribute
> > Object Details (For the "Make Before Break" or Rerouting) 
> the PSB of the Old
> > Path Message.
> 
> ###  So you can't reroute the traffic for an FF style flow
> 

If the receiver sends a Resv with SE style, it is still possible to do
"make-before-break". The new Path message would appear to be from a
different sender, since the LSP Id is changed. "Comparing", if done, is
implementation dependent. 

> > 
> > 
> >             Does it mean that if we send a Path Message 
> without a Session
> > Attribute Object, some DEFAULT value of (Setup/ Holding 
> Priority etc is stored).
> > If yes, then what is the default value???
> 
> ###  I think it should be your implementation's assumption. 
> The default 
> value can be 4.
> 
> Reg
> Arumugam
> 
> > 
> > TIA
> >         Rajesh P Jain
> > 
> > 
> > 
> > "Feng, Mark" wrote:
> > 
> >> Also the "local protecion" flag is useful in term of 
> re-routing LSPs in case
> >> of downstream node failure. The resource affinity related 
> vectors are useful
> >> regarding constraint-based routing...
> >> 
> >> - Mark
> >> 
> >>> -----Original Message-----
> >>> From: Khuzema Pithewan [mailto:[email-masked]]
> >>> Sent: Thursday, July 19, 2001 1:49 AM
> >>> Cc: [email-masked]'
> >>> Subject: Re: Session Attributes
> >>> 
> >>> 
> >>> SE Desired flag can be set in Session Attribute if Ingress is
> >>> willing to
> >>> use make-before-break of LSPs...
> >>> 
> >>> Khuzema.
> >>> 
> >>> 
> >>> Rajesh P Jain wrote:
> >>> 
> >>>> "Hi",
> >>>>                 I would also like to know if this Session
> >>> 
> >>> Attribute OBJECT
> >>> 
> >>>> anyway helpful in Rerouting Traffic Engineered Tunnels?? Is
> >>> 
> >>> the information
> >>> 
> >>>> present in this object anyway useful in 
> "make-before-break" concept?
> >>>> 
> >>>> TIA
> >>>>         Rajesh P Jain
> >>>> 
> >>>> "Feng, Mark" wrote:
> >>>> 
> >>>>> Ping,
> >>>>> 
> >>>>> I know the name implies the attributes belong to the
> >>>> 
> >>> session. But does it
> >>> 
> >>>>> mean all senders, i.e. ingress routers, need to have the
> >>>> 
> >>> same session
> >>> 
> >>>>> attributes? Should the transit nodes reject the new Path
> >>>> 
> >>> message, if the
> >>> 
> >>>>> session attributes are different from other senders of
> >>>> 
> >>> the same session,
> >>> 
> >>>>> because there is no rule on "merging" the session attributes?
> >>>>> 
> >>>>> Thanks.
> >>>>> 
> >>>>> - Mark
> >>>>> 
> >>>>>> -----Original Message-----
> >>>>>> From: Ping Pan [mailto:[email-masked]]
> >>>>>> Sent: Tuesday, July 17, 2001 9:37 PM
> >>>>>> To: Khuzema Pithewan
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: Re: Session Attributes
> >>>>>> 
> >>>>>> 
> >>>>>> Khuzema,
> >>>>>> 
> >>>>>> First, this question should go to the mpls list. Please
> >>>>> 
> >>> forward the
> >>> 
> >>>>>> discussion to that list. Second, the question itself is
> >>>>> 
> >>> implementation
> >>> 
> >>>>>> dependent. Finally, since the Session Attribute object
> >>>>> 
> >>> is to describe
> >>> 
> >>>>>> the properties of a RSVP session, in a normal implementation,
> >>>>>> it should
> >>>>>> be kept where you keep the session.
> >>>>>> 
> >>>>>> - Ping
> >>>>>> 
> >>>>>> Khuzema Pithewan wrote:
> >>>>>> 
> >>>>>>> Hi,
> >>>>>>> 
> >>>>>>> Session Attribute Object in RSVP-TE contains some
> >>>>>> 
> >>> flags , setup and
> >>> 
> >>>>>>> holding priority and some session related info.
> >>>>>>> 
> >>>>>>>  My doubt is , if this object is per session or per LSP,
> >>>>>> 
> >>>>>> because name
> >>>>>> 
> >>>>>>> suggest
> >>>>>>>  that it is per session, but holding/setup priorities are
> >>>>>> 
> >>>>>> the attributes
> >>>>>> 
> >>>>>>> of a LSP.
> >>>>>>>  so basically where to keep this Object,?? in PSB or
> >>>>>> 
> >>> Session???
> >>> 
> >>>>>>> Khuzema.
> >>>>>> 
> 
>

---

From: David Charlap <[email-masked]>
Date: Fri, 20 Jul 2001 15:14:20 -0400

>> Eventhough it is optional, it is upto the implementation looking
>> you have to allocate a FF style for the flow..
> 
> I don't agree with that. The draft does not say what style of
> reservation should be used. It is really up to the implementation.
> Conversely, even if the sender asks for SE style in the
> SESSION_ATTRIBUTE object, the receiver does not have to honor the
> request. According to the standard, that does not appear to be a
> protocol error. In other words, the reservation style is decided by
> the receiver.

It's more than just that.  Everything in SESSION_ATTRIBUTES is
advisory.  This can be inferred from the fact that its class number is
greater than 192.  Routers that don't support SESSION_ATTRIBUTES are
supposed to opaquely forward the object and set up the Path without
using it.

If the parameters in SESSION_ATTRIBUTES were hard requirements, then
this behavior would make no sense.

Of course, a conformant implementation _should_ follow the parameters,
unless there's a really good reason why not to.  But they are still
advisory nonetheless.

> If the receiver sends a Resv with SE style, it is still possible
> to do "make-before-break". The new Path message would appear to be
> from a different sender, since the LSP Id is changed. "Comparing",
> if done, is implementation dependent.

It is possible to do make-before-break even with FF style.  The only
catch is that resources will be temporarily wasted on those nodes/links
that the new and old LSPs have in common.  The reroute may fail if there
aren't enough resources to hold this temporary reservation.  But if
there are sufficient resources, make-before-break will still work.

-- David