The MPLS WG Archive

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

Jack et al,

	Please see comments below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: Jack Brennen [mailto:John.Brennen@marconi.com]
> Sent: Wednesday, September 18, 2002 11:56 AM
> To: MPLS (E-mail)
> Subject: Re: Clarification on Handling a specific event in LDP
> 
> 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.  :-)

This is a rational approach, particularly when there is a next
hop that may become an LDP peer (even theoretically).  However
it is not an option for some implementations.

> 
>   (2)  Leave the NULL label in place; take no action.

This works for implementations that do not 'suffer' with
the overhead of providing LSP ingress.  Otherwise, it is
sub-optimal.

> 
>   (3)  Withdraw the NULL label; readvertise using a non-NULL label
>        only if the session supports Unsolicited advertisement.

In the DoD/Ordered control case - strictly interpreted - this 
is the implied behavior and would result in tearing down all 
affected LSPs to ingress and waiting for the ingress LSRs to 
start over for each LSP.  Because the local LSR should not be
in the business of trying to predict the distribution/control
modes of upstream LSRs (beyond the immediate peer), it should 
behave as if upstream LSRs are observing the same behavior as 
its immediate upstream LSR peer - both because this is one 
reasonable assumption and it is the worst case.  Using this 
assumption, the behavior of Withdrawing the Implicit NULL label 
(just to remove the growing ambiguity in this thread) should be 
considered sociopathic.

> 
>   (4)  Withdraw the NULL label; readvertise using a non-NULL label
>        regardless of the session's advertisement setting.

See response to 3 above.  This is slightly less pathological
in the sense that it is possible that LSPs will take less 
time to be re-established.  It is slightly more pathological
given the possibility that some implementations may simply
release any label they receive unsolicited - you still end
up waiting for the ingress LSRs to re-establish LSPs and you
also end up with a great deal more signaling.

> 
>   (5)  Advertise using a non-NULL label, without withdrawing the
>        NULL label.  The upstream peer *might* realize what you are
>        trying to do...

Indeed, and this behavior is harmless in the event that the
upstream peer does not.  I have previously referred to this 
as implied withdraw.  There are reasons why 'implied withdraw' 
may not work in general.  For example, how does this work if
more than one label has previously been given for the same
FEC?  However, in the case where the one and only previously 
advertised label was the implicit NULL label (which had zero
- or possibly negative semantic value), this behavior will
work nicely.

Moreover, if the upstream LSR does not know what to do with
the label, it will simply release it (potentially telling 
the local LSR not to bother trying this again) and subsequent
behavior is no worse than it would be otherwise.

The downstream LSR should do one other thing.  Because the 
upstream LSR may be 'conservatively' implemented, it may 
simply 'liberally' retain the new Label Mapping.  Hence, 
the local LSR must withdraw the implicit NULL label if
the upstream LSR does not release it within some period of 
time.

Note that - if you cruise through the appendices in RFC 3036
- you should find that things work out correctly when done
this way.

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

In the standards process, anything not explicitly forbidden
is implicitly allowed.  Sometimes things which are explicitly
forbidden are implicitly allowed if undetectable.  Finally,
even if a thing is never allowed, it may not be advisable to
assume that it is not done.  :-)

> 
>     Jack