Subject: Re: Question about Label allocation in RSVP-TE

From: "Quan Sun" <[email-masked]>
Date: Fri, 20 Apr 2001 15:05:44 -0400

Thank you, David. What you said makes sense.

Could you (or someone else) make some more points (advantages/disadvantages) 
about similar situation involving bi-directional path setup in GMPLS using 
RSVP-TE? In that case, when a Resv message comes (e.g. to an intermediate 
node), if no resource is avaliable at that node, it would be frustrating 
(and costly if the entire path must be torn down) because the reverse path 
is already established and may be carrying data (see Section 3.1 of 
Bidirectionnal LSPs of the GMPLS RSVP-TE draft).

Quan

>From: David Charlap <[email-masked]>
>To: [email-masked]
>Subject: Re: Question about Label allocation in RSVP-TE
>Date: Fri, 20 Apr 2001 13:44:04 -0400
>
>Quan Sun wrote:
> >
> > A dumb question, but still a bit confusing for me when reading the
> > RSVP TE draft: when you receive a Path message, (a) you immediately
> > allocate a label for the upstream link and save it for later use
> > (this label will be later put to the RESV message coming from the
> > downstream node), or (b)the label is only allocated after a RESV
> > message has come.
>
>It doesn't matter.  You can't send the label to the upstream peer until
>after the Resv arrives.  What you do inside your box is not something
>that RFCs should be dictating.
>
>As with pre-reserving resources, there are advantages to both
>techniques.
>
>If you reserve the label during Path processing....
>
>1: You won't have to take the time to reserve it when the Resv
>    arrives.  Depending on your architecture, this might improve LSP
>    setup times.
>
>2: After successfully reserving the label, you won't have to worry
>    about some other LSP taking the last one before your Resv arrives.
>
>3: You will have to deal with the possibility of not having any labels
>    available during Path processing.  Do you send back an error?  Or
>    do you wait for the Resv and then try again? (in case another LSP
>    was torn during that time.)
>
>4: If you successfully allocate the label, and then the Path is torn
>    before the Resv arrives, the allocation was wasteful.  The label
>    was never needed, because no data arrived.  In a heavily-loaded
>    situation, this may have prevented another LSP from coming up.
>
> > If you read RSVP draft Section 4.1.1 (Handling Label Objects in Resv
> > Messages), you understand the above (b) is the case. When you read
> > Section 4.2.4 (Handling of LABEL_REQUEST), you have a feel that the
> > label is attempted to be allocated when you receive the Path message
> > (The draft says: "A node that recognizes a LABEL_REQUEST object, but
> > that is unable to support it (possibly because of a failure to
> > allocate labels) SHOULD send a PathErr...). At least, I know of a
> > MPLS vendor who uses the above case (a).
> >
> > Or, this is an implementation specific issue?
>
>Implementation-specific would be my opinion.
>
>IMO, any behavior which is invisible outside the box (such as described
>above) should not be dictated by standards bodies.
>
>-- David

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.