The MPLS WG Archive

[Adrian Farrel <AF@datcon.co.uk>]

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:af@datcon.co.uk
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:david.charlap@marconi.com]
>Sent: Wednesday, August 02, 2000 3:31 PM
>To: mpls@UU.NET
>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.