The MPLS WG Archive

["Philip Matthews" <philipma@nortelnetworks.com>]

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


Adrian Farrel wrote:
> 
> 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.