The MPLS WG Archive

[Dan Tappan <tappan@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.

You're missing the point.

If the FEC in question corresponds to the LSR advertising the label, then 
it is appropriate to advertise a NULL label.

If the FEC does _not_ correspond to this LSR, then advertising a NULL label 
will cause the LSP to terminate prematurely. So, if a packet contains a 
label stack the underlying label will be exposed prematurely, causing it to 
be interpreted by an LSR other than the one which advertised it.

With your example, given

  LSR_A --- LSR_B

----LSPx----->

Where the path for LSPx goes through LSR_B. Turning on LDP in LSR_B does 
not change the LSP from "terminating" to "non-terminating" as far as LSR_A 
is concerned, in either case the next hop for the LSP goes through LSR_B. 
What it changes is whether or not LSR_A has received a valid label from the 
next hop. So, LSR_A can always advertise a non-NULL label, but it may 
change the forwarding behavior for that label depending on what it learns 
from LSR_B. It may also change whether LSR_A is the "egress" for LSPx, and 
so may affect whether or not LSR_A even advertises a label at all if in 
Ordered mode, but that is a separate issue from whether or not the 
advertised label should be null.

If the complete corner case we're worrying about is:
- DoD
- Ordered
- LSR_A changes from Egress to non-egress for an LSP

Then the correct behavior was:
- advertise a non-null label while egress (because the LSP did not terminate)
- if LSR_B starts to run LDP, meaning LSR_A realizes it is no longer 
egress, then withdraw the label. Presumably the upstream LSR(s) should 
re-request the mapping (see the last sentence in the "Summary" of RFC3036 
A.1.5), in which case the existing state machine applies.

> > -----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