Subject: RE: Session Attributes

From: "Feng, Mark" <[email-masked]>
Date: Wed, 18 Jul 2001 09:41:46 -0700

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: Rajesh P Jain <[email-masked]>
Date: Thu, 19 Jul 2001 13:05:22 +0530

"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

---

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 19 Jul 2001 09:26:30 +0530

Hi,

I am given to understand that, when RSVP-TE works with MPLS, the LSP
setup is control driven, means, there should be some Administrator which
is responsible to configure the session attributes for the session, if
administrator wants to give different session attributes for the path
messages grouped on per ingress basis, then Extended tunnel Id can be
used. Now if there is case of reception of PATH messages with different
session attributes in same session, then its a result of
mis-configuration and I believe in that case path message should be
dropped. But again if(?) we say setup/holding priorities are attributes
of LSP then what is significance of keeping them per session?

Khuzema.

---

From: Khuzema Pithewan <[email-masked]>
Date: Thu, 19 Jul 2001 14:18:58 +0530

SE Desired flag can be set in Session Attribute if Ingress is willing to
use make-before-break of LSPs...

Khuzema.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Jul 2001 10:53:20 -0500

The SESSION_ATTRIBUTES are per LSP.  Consider the case where the operator
decides to change the holding & reserving priority used for the tunnel.
Then a make-before-break is done, where the new LSP is signalled with the
new priorities in the SESSION_ATTRIBUTES object before the old LSP is torn
down. 

Also, consider the case of doing fast-reroute, where the backup LSP belongs
to the same session as the primary LSP, but may have a different holding
and reserving priority than the primary (whether due to the contents of the
FAST_REROUTE object, if used, or to operator configuration at the potential
PLR).

Dropping a PATH message because it has different information in its
SESSION_ATTRIBUTES object than a previous PATH message for the same SESSION
does not make sense for either of the above scenarios.

Alia