Subject: Session Attributes

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 16 Jul 2001 15:36:57 +0530

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: "Feng, Mark" <[email-masked]>
Date: Tue, 17 Jul 2001 14:11:35 -0700

I think the name Session Attribute is a misnomer. IMO, the attributes apply
to a particular LSP. Where to keep it is implementation dependent. PSB seems
to be a logical place.

- Mark

> -----Original Message-----
> From: Khuzema Pithewan [mailto:[email-masked]]
> Sent: Monday, July 16, 2001 3:07 AM
> To: [email-masked]
> Subject: Session Attributes
> 
> 
> Hi,
>

---

From: "Feng, Mark" <[email-masked]>
Date: Mon, 23 Jul 2001 09:28:28 -0700

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

Though this is true, there might be a problem achieving a true
"make-before-break while working with different vendor's implementation. The
draft does not say what the expected behavior should be in FF style.

But I agree this is the logical way to do it:-). 

- Mark
 
> -- David