Subject: RE: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt

From: Adrian Farrel <[email-masked]>
Date: Wed, 2 Aug 2000 16:24:55 +0100

David, Philip,

We saw exactly the behavior that David describes at the last UNH interop.
Of course in that situation the h/w is often a bit rudimentary.

What happened is that the s/w on the downstream box was recycled w/o any
change to h/w so that the light stayed on on the fiber.  The Path refresh
was caught by the downstream node which responded with a Resv with a
different label.

Correct behavior by the upstream node is, of course, either
- reject the Resv and tear the LSP down
- accept the new label and change the switch programming

Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>-----Original Message-----
>From: David Charlap [mailto:[email-masked]]
>Sent: Wednesday, August 02, 2000 3:31 PM
>To: [email-masked]
>Subject: Re: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt
>
>
>I think I can answer one of these....
>
>Philip Matthews wrote:
>> 
>> 4.1.1.1. Downstream
>>   The text says "A node is expected to send a Resv message before its
>>   refresh timers expire if the contents of the LABEL object change."
>>   When could this happen? Once an LSP is set up, is the downstream
>>   node allowed to change the LABEL object in a Resv refresh?
>
>Normally, a downstream node will not change the LABEL object.  
>But there
>are scenarios where it could happen.  For example.  Imagine this
>topology:
>
>	A---B---C---D
>
>A Path and Resv go through and an LSP is established from A to D.
>
>Now, the inbound interface on D goes down, but the outbound 
>interface on
>C remains up.  (Perhaps it was administratively disabled - obviously,
>this wouldn't happen if the fiber was disconnected.)
>
>C thinks the link is still up and continues sending Path refreshes.  D
>thinks the link is down and tears its state.
>
>Now, before C misses enough Resv refreshes to presume link failure and
>generate a PathErr, the inbound interface on D comes up again.
>
>D receives a Path from C (one of the usual refreshes), but it 
>sees it as
>a new Path (since it no longer has the old state in memory).  So it
>allocates a new LABEL (which will almost certainly be 
>different from the
>one it had before) and sends this to C in its Resv messages.
>
>Admittedly, this is a rare (and a bit contrived) sitation, but it can
>happen.

---

From: "Philip Matthews" <[email-masked]>
Date: Wed, 02 Aug 2000 20:28:10 -0400

Thanks for the information.
I guess the answer is that an implementation
SHOULD make an effort to handle such cases,
and not just reject the change with a PathErr
or ResvErr.
- Philip

---

From: David Charlap <[email-masked]>
Date: Thu, 03 Aug 2000 10:17:47 -0400

Philip Matthews wrote:
> I guess the answer is that an implementation SHOULD make an effort to
> handle such cases, and not just reject the change with a PathErr or
> ResvErr.

IMO, if the hardware (or its operating system) is capable of changing
the egress label for an established tunnel, it should attempt to do so.

If the hardware can't do this, or if the attempt fails, then you must
report this fact to the ingress node so that it can take appropriate
action (probably involving tearing down the tunnel and reestablishing
it).  This report would be in the form of a PathErr message.  A ResvErr
message to the egress node might also be useful, but I don't think it
will be necessary.

-- David