The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

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. 

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