Subject: Re: RSVPTE questions, please help me for this, thanks

From: "Hong Liao" <[email-masked]>
Date: Mon, 5 Nov 2001 15:10:06 -0500

But Label object in the Rsvpte is mandatory, if the ResvTear use the same
structure of the Resv msg for the flow descriptor list, them Label object
is a mandatory, too. The draft should be more clear for this.

Julia

                    David Charlap                                                                                   
                    <David.Charlap@ma        To:     Eric Gray <[email-masked]>                            
                    rconi.com>               cc:     Hong Liao <[email-masked]>, (bcc: Hong Liao/Telcordia)    
                                             Subject:     Re: RSVPTE questions, please help me for this, thanks     
                    11/05/01 11:30 AM                                                                               

Eric Gray wrote:
>
> You also need to be liberal in what you accept in the sense that
> you should not reject an RSVPTear message that contains a label
> object, even if you do not need it in your implementation.

I would say that this is implicit.  Unnecessary objects are never cause
for rejecting any message.

> However, this raises the following question:
>
> o You should be able to figure out what LSP the message applies to
>   without the label object and

Again, this is implicit.  According to RFC 2205, and its MIBs, the key
for uniquely identifying an RSVP connection is the 5-tuple composed of
session and sender information.  For RSVP-TE, this is tunnel endpoint
address, tunnel ID, extended tunnel ID, sender address and LSP ID.

In the case of multiple Resv messages arriving for a single sender
(which should only happen for multicast), then the next-hop address
uniquely determines a particular Resv message.

The label is never a key, but a value to be used in establishing a
connection.

> o There is a non-infinitesimal probability that including a label
>   object might result in contradiction between the LSP indicated by
>   the label object and the LSP that would be determined without it
>   - therefore

I don't see any such possibility, since the label is not a key.  If it
differs, then something has obviously gone wrong (perhaps an intervening
Resv message, intented to change the label, got lost), but it shouldn't
result in selecting the wrong connection.

Note also that the 5-tuple of session/sender information will uniquely
identify a single LSP in all cases.  And if everything is unicast, it
will uniquely identify a single connection across the local switching
fabric as well.  So there should never be a situation where one LSP
would be selected with the label and another would be selected without
it.

> o If both are present, which is the more correct decision
>
>   o ignore the label object or
>   o ignore the rest of the message in determining what LSP to apply
>     it to?

I would ignore the label object, since it doesn't seem to serve any
purpose during ResvTear processing.

If your switch architecture requires the label value in order to process
the tear, then the problem will still not apply, since you won't be able
to select ANY LSP without it.

I would also argue that such an architecture would be problematic for
many other reasons.  If your code does not retain the label value at all
times, it can't know whether an incoming Resv message is a refresh or if
it is requesting a change in label value for the connection.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 05 Nov 2001 17:44:56 -0500

Hong Liao wrote:
> 
> But Label object in the Rsvpte is mandatory, if the ResvTear use
> the same structure of the Resv msg for the flow descriptor list,
> them Label object is a mandatory, too. The draft should be more
> clear for this.

Who cares?  The intention of the message is clear - tear down the
specified reservation - and the existing objects are sufficient to
perform that teardown.  A LABEL in this context is really irrelevant.  
Since the draft doesn't require you to reject the ResvTear message under
this circumstance, the ambiguity remains.  You are free to choose either
path.  I would recommend choosing the one that allows you to
interoperate with as many others as possible.

-- David