The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Jack,

    Yes, I meant Label Withdraw.

    The case where Router A re-issues Label 1, is problematic only for the
time it takes Router B to receive the corresponding Label Mapping.  Once
Router B receives a Label Mapping for a label it already has and a different
FEC, Router B will know that it is screwed up.  It is reasonably well
known that you should not re-use a label you have just removed from service
for some period of time as this is likely to result in miss-routed packets in
any case.  This would be forced in the case where Router A withdraws a label
mapping because Router A cannot then re-use the label until it receives a
Label Release for that label.

    Having a syntactically different messages for the initial and subsequent
update Label Mappings would fix the problem you're describing, but it may
not be necessary.  One simple way to avoid this problem is to treat any label
received unsolicited (when operating in DoD mode) as an update.  If this is
what you do, then you would not end up using any label you did not get as
a result of a Label Request - at least originally.

    I tend to think of DU and Liberal Retention as being a bundled package
and the same for DoD and Conservative Retention.  I told Bob Thomas a
long time ago that - while I think it reasonable for an implementation  to
send Label Requests in DU mode - I do not think it is reasonable for an
implementation to send unsolicited Label Mappings when operating in
the DoD mode.  If it were up to me, in DoD mode, the only Label Mappings
I would not immediately Release would be the ones I asked for and updates
for the ones I asked for.

You wrote:

> Eric Gray wrote:
> > No.  Router B has done a BAD THING.
>
> I won't argue this point, merely because it's not fundamental to my finding
> of a possible protocol instability.  The fundamental problem is that an "update"
> Label Mapping message can "cross on the wire" with a Label Release message for
> the same FEC/Label combination.  It is possible, in several ways, for Router B
> to accept the "update" Label Mapping message as if it were a normal unsolicited
> Label Mapping, even though it just recently released a Label Mapping for the
> same FEC.  Reasons why Router B might do this:
>
>    (1)  The original Label Mapping caused a "loop detection" failure,
>         but the "update" Label Mapping did not.
>    (2)  Router A was not the next hop when the original Label Mapping
>         was processed, but is the next hop when the "update" Label Mapping
>         is processed.
>    (3)  Router B had no available memory to keep the original Label Mapping,
>         but memory became available by the time the "update" Label Mapping
>         was processed.
>
> If "update" Label Mapping messages were syntactically different than normal
> unsolicited Label Mapping messages, the whole problem could be avoided.  That
> is how I would fix the specification if it were my decision.
>
> > There is always a 'robustness' behavior that is well understood, if not exactly
> > specified.  If Router A is getting labels it does not know how to handle (it
> > has no corresponding ILM for these labels), it is a simple matter of software
> > to realize that it should send a Label Release for those labels to the LSR that
> > is sending them.
>
> In my examples, Router A thinks that the label has been released by Router B,
> so it is free to reassign it to a different FEC -- there may be a corresponding
> ILM for the label (on Router A) when Router B actually puts traffic onto it,
> in which case Router A won't see anything amiss.
>
> Also, I think you mean that Router A should send a Label Withdraw.  I don't
> necessarily agree, but I wouldn't argue too hard against it.
>
>     Jack

--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray