The MPLS WG Archive

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

Jack,

    Please see below...

You wrote (in part):

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

It's hard to specify robustness sometimes.  I am sure there are
other ways to know if a label mapping you have received is one
you have previously received and retained then looking it up in
your LIB.  I also seem to recall this being a check in at least
some of the steps in the appendix under receive label mapping.

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

I am pretty sure that you cannot send unsolicited label mappings
for multiple FECs because of the ramifications on the LSPs going
upstream.  But I don't really have the time right at the moment
to put my finger on where it says that in the spec, so I may be
wrong.

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

And Router A is the one making the commitment to deliver a set
of packets in a certain way.  So only Router A's perspective
counts.  If it waits some reasonable amount of time before it
re-issues a label, then it does not matter what Router B's
point of view is with respect to 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.
>
> 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.

This is a smallish sort of window, which may be sorted by simply
having Router A send a Label Withdraw when it receives packets
that are labeled with the labels that Router B mistakenly thinks
are valid.  I think that a robust LSR implementation will do
that in any case.

I think it's time for Bob Thomas to take the torch on this one.
The specification is currently being revised for submission as
a draft standard.  If people can convince him that adding some
semantic/syntactic differentiator is a good idea, then it will
be in the next version.  It makes absolutely no difference to
me.

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

Yeah, but this is a monkey trap.  The fact that it is allowed
does not change the fact that it is a very bad idea.  You have
to realize that DU and Conservative Retention means you will
have to release almost all of the labels you get in any real
world router with any interesting number of interfaces and
peers.  Why would you want to do that?


>
>
> ...

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