The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] 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.. > > > 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 > > > 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:khuzema@netbrahma.com] >>> Sent: Thursday, July 19, 2001 1:49 AM >>> Cc: 'mpls@uu.net' >>> 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: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. >>>>>>
|
|