The MPLS WG Archive

[Dan Tappan <tappan@cisco.com>]

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