The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Session Attributes
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 At 09:26 AM 7/19/01 +0530, Khuzema Pithewan wrote: >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. > >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:pingpan@juniper.net] >> > Sent: Tuesday, July 17, 2001 9:37 PM >> > To: Khuzema Pithewan >> > Cc: rsvp@ISI.EDU >> > 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. >> > >
|
|