The MPLS WG Archive

[Jack Brennen <John.Brennen@marconi.com>]

Eric Gray wrote:
> 
> 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.

Yes, I agree.

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

Now you have imposed a requirement on Router B to look up a label in its
Label Information Base every time it receives a Label Mapping.  This is expensive
and is not called for in RFC 3036.

Furthermore, LDP explicitly allows a single label to be associated with multiple
FECs.  From 3.5.11.1 (Label Release Message Procedures):

   The FEC TLV may contain the Wildcard FEC Element; if so, it may
   contain no other FEC Elements.  In this case, if the Label Release
   message contains an optional Label TLV, then the label is to be
   released for all FECs to which it is bound.

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

I disagree that this is true from the point of view of Router B; if the downstream
router has advertised a FEC/Label combination, said router is indicating that it is
ready to switch that label now, not at some point in the future.

Your statement is correct from the point of view of Router A; after the last release
for a label is received, Router A should avoid readvertising that label until all
packets in transit have had a chance to clear the network.  But that's not what
my example shows.  Router A is not readvertising a released label, it just looks
that way from Router B's perspective.

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

Correct.  A Label Withdraw message is semantically a request for a release message,
and the label is not actually freed until that Label Release is received.

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

But the problem has nothing to do with DoD mode.  It occurs in DU mode as well:

  Router A                          Router B
  --------                          --------

  Sends Label Mapping
   (Path Vector=<B,C,D,A>)
                                    Receives Label Mapping
  Router A gets a new next hop
   for the FEC
  Sends Label Mapping
   (Path Vector=<E,F,G,A>)
                                    Sends Label Release
                                     (loop detected)
  Receives Label Release
                                    Receives Label Mapping

At the end of this scenario, Router B holds a label which he believes was
validly advertised by Router A.  Router A believes that Router B released
the label.

> 
>     I tend to think of DU and Liberal Retention as being a bundled package
> and the same for DoD and Conservative Retention.

Okay, but RFC 3031 (MPLS Architecture) specifically allows DU & Conservative
to be used together.  See section 5.2.1, scheme 3.

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

I agree; if a session is in DoD mode, unsolicited label mappings shouldn't
be sent, and should be released if received.