The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 01:00 PM 9/18/2002 -0400, Gray, Eric wrote:
>Dan,
>
>         The distinction between terminating LSPs and
>non-terminating LSPs is not always readily apparent.
>One of the scenarios I pointed out (much) earlier
>is the one in which LDP is 'turned on' in a router.
>This has the effect of changing a routing peer into
>both a routing and LDP peer.  It also changes LSPs
>that previously terminated on surrounding routing
>peers into non-terminating LSPs.

         Shouldn't the labels bound to these LSPs be withdrawn
and be re-requested?

         --Tom



>Eric W. Gray
>Systems Architect
>Celox Networks, Inc.
>egray@celoxnetworks.com
>508 305 7214
>
>
> > -----Original Message-----
> > From: Dan Tappan [mailto:tappan@cisco.com]
> > Sent: Wednesday, September 18, 2002 12:48 PM
> > To: Jack Brennen
> > Cc: MPLS (E-mail)
> > Subject: Re: Clarification on Handling a specific event in LDP
> >
> > At 11:56 AM 9/18/2002 -0400, Jack Brennen wrote:
> > >It seems to me that any of these behaviors should be allowed; the
> > >upstream peer should not interpret any of these behaviors as a
> > >fatal error.  Additionally, it seems evident that any of these
> > >behaviors is "acceptable" -- the data flow in question should be
> > >correctly forwarded regardless of which behavior is chosen.
> >
> > Actually, that point is arguable. In fact, in the case where the LSP in
> > question didn't terminate at this LSR, i.e. where the FEC did not
> > correspond to the LSR or to one of its connected interfaces, then
> > advertising a NULL label at all will not produce correct forwarding
> > behavior in the presence of a label stack.
> >
> > So, the "correct" behavior is more like:
> >
> > (1a) Advertise NULL labels only for terminating LSPs. For non-terminating
> > LSPs, always advertise a non-NULL label even if no label has been received
> > from the next-hop.
> >
> >
> > >Eric Rosen wrote:
> > > >
> > > > Is this a practical problem for you, or simply a theoretical one?
> > > >
> > >
> > >It's an implementation detail for any implementor whose LSR gives out
> > >NULL labels (either implicit or explicit).  Specifically, what should
> > >the behavior be when a NULL label has been sent upstream, and a "real"
> > >(non-NULL) label becomes available from the next hop (either through
> > >a next hop change or through receipt of a Label Mapping or an Address
> > >message)?  How is the behavior modified by the three major "knobs" of
> > >LDP (DoD/Unsolicited, Ordered/Independent, Liberal/Conservative)?
> > >
> > >RFC 3036 is silent on the matter, so I would assume that the behavior
> > >is implementation-dependent, with the following possibilities (there
> > >may be more, but these come to mind):
> > >
> > >   (1)  Avoid the issue -- don't send NULL labels.  :-)
> > >
> > >   (2)  Leave the NULL label in place; take no action.
> > >
> > >   (3)  Withdraw the NULL label; readvertise using a non-NULL label
> > >        only if the session supports Unsolicited advertisement.
> > >
> > >   (4)  Withdraw the NULL label; readvertise using a non-NULL label
> > >        regardless of the session's advertisement setting.
> > >
> > >   (5)  Advertise using a non-NULL label, without withdrawing the
> > >        NULL label.  The upstream peer *might* realize what you are
> > >        trying to do...
> > >
> > >It seems to me that any of these behaviors should be allowed; the
> > >upstream peer should not interpret any of these behaviors as a
> > >fatal error.  Additionally, it seems evident that any of these
> > >behaviors is "acceptable" -- the data flow in question should be
> > >correctly forwarded regardless of which behavior is chosen.
> > >
> > >     Jack



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.