The MPLS WG Archive

[Eric Gray <ewgray@GraIyMage.com>]

David,

    You and Eric Rosen are dancing around the issue.  :-)

    I believe you missed the point that the fact that the explicit NULL
is "well known" means that it is unnecessary (atleast in the opinion of
some implementers) for the egress to "offer" the explicit NULL label
to the penultimate hop.

    I argued some time ago that the spec not being tighter about this
usage was problematic and was labeled a purist by someone we all
know.  :-)

    The issue is that - because the explicit NULL label is well known -
it is not acceptable behavior for a "compliant" implementation to not
support the explicit NULL label, EVEN IF IT IS INCAPABLE OF
OFFERING IT. Notice that it is acceptable behavior for a compiant
implementation to _never_ offer an explicit NULL label.

    The point has been made several times since that an implementation
that assumes it is acting as the penultimate hop and uses explicit NULL
even though some other label was offered by its downstream (and not
necessarily egress) peer is at least highly anti-social.  For one thing, it
makes it deuced hard to keep per LSP statistics.  Also, the fact that
any LSR could prefix the explicit NULL label to any peer that it knows
to be an LSR - even if it would otherwise forward packets to that peer
unlabeled - does not mean that it should do so or even would do so in
any implementation I know of.

    However it is conceivable that an LSR might use an explicit NULL
label in forwarding packets to a neighbor LSR that never offered this
label.

    Barring this sort of anti-social behavior, it is usually the case that
an LSR receiving an explicit NULL label does so because it has
earlier bound explicit NULL to a FEC in relation to the peer from
which it receives the so-labeled packet.  What this says to me is
that an LSR will only receive a mix of labeled and unlabeled
packets on an LSP if it has issued the same label (explicit NULL)
for a set of traffic it will forward as IP traffic and another set it will
forward as MPLS labeled traffic.  This _should_ put the egress in
control of the situation and the problems discussed here _should_
not arise.

    This is where Eric may be being a little loose with the term egress.
Any LSR that pops an explicit NULL label is acting as an egress. It
has no choice, because it certainly cannot have bound an outgoing
label to a explicit NULL incoming label.  :-)

    So what seems to meant is that - if the explicit NULL label's stack
entry has the BOS bit set - then the IP version is relevant.  Otherwise
it is not.

--
Eric Gray

David Allan wrote:

> Hi Eric:
>
> <snipped>
> > David> this  sort  of  half-PHP is  really  the  provence  of
> > the  LSR  that
> > David> originated the label.  Only consequence of such a
> > spec change is the
> > David> upstream LSR should  not squawk or place limitations
> > on such a label
> > David> if received.
> >
> > When  the egress node  E sends  an LDP  message binding
> > explicit null  to a particular FEC,  it is  telling the penultimate  node
> P that,
> >  under certain circumstances,
>
> Could you elaborate on "under certain circumstances"? I would presume that
> if that was the offered label binding, the upstream LSR was expected to use
> it.
>
> > when P receives an MPLS packet from some third node, P should
> > swap the top label  of that packet with explicit null.  P
> > will do this when the FEC corresponding to the incoming label of the
> packet is
> > the same FEC to which E has bound explicit null.
>
> Yes.
>
> >
> > Strictly speaking E should only bind explicit null to a
> > particular FEC if it somehow knows that any packets which P sees that
> correspond
> > to that FEC will be carrying label stacks of no more than one label.
>
> Consistent with 3032
>
> > In practice, though, it is difficult to make E obey this restriction.
>
> Agreed, although as I note below, of you don't need the V4/V6 part, any
> label will do and has no wierd semantics assocaited with it...
> >
> > I think what you're saying is that  if E gets a packet with
> > explicit null at
> > the top of the stack, it has  gotten what it asked for, and
> > should handle it
> > in the obvious  way.
>
> yes, if it offered it, nothing further required. If it didn't offer it, (for
> example offered implicit NULL and got explicit NULL as a top label, then I
> would presume the ingress originated the explicit NULL as an IP PID
> (although I do not know why it would do so). OR if E offered another label,
> and when popping that label found an explicit NULL would similarly assume
> that it originated with the ingress.
>
> > I agree with  this, and I'd assumed that  this is what
> > would generally be done.  But the spec never made this clear.
> >  So we've seen cases where  E throws the packet away  as malformed,
>
> one where it offered explicit NULL? Different teams implementing different
> features ;-)
>
> > and I  think we've also seen cases where P throws the  packet away rather
> than
> > sending a "malformed" packet.
>
> This is what I presume removing the restriction would address.
>
> > These  lead to lack of  interoperability.
>
> agreed
>
> > I think we've also seen cases where P, when processing a packet with more
> than one
> > label, will treat explicit  null  as  if  it  had   been  implicit  null;
> this
> >  at  least  is
> > interoperable.
> >
> > So perhaps what should really be required is:
> >
> > - When  the egress  LSR pops  off  explicit null,  it should
> > attend to  the
> >   IPv4/v6  type.   Other nodes  treat  the two  kinds  of
> > explicit null  as
> >   equivalent.
>
> I think it's a bit more subtle. If it is a top and a bottom label at E as a
> result of any operation (P doing PHP, P not doing PHP and E popping a
> previous top label etc.), then E attends to the V4/V6 type.
>
> If it is a top and not a bottom label at E, then it is just a label and if
> not offered by E then it is a fault.
>
> IMHO this is a bit bizzare and not what I would design from a clean sheet,
> but seems to correspond to actual usage. Realistically if I did not want to
> attend to V4/V6 type, ANY label would do to stunt double for the way
> Explicit NULL is used, the implementation merely needed to pick any one
> non-reserved value to use where it offered explicit null today and would
> then be compliant with 3032 as written.
>
> >
> > - When asked  to put explicit null on  the top of a label
> > stack,  one MAY do
> >   so, but one SHOULD treat explicit  null as if it were
> > implicit null.  (Not
> >   sure about that "should".)
>
> Not quite clear on the implications of that other than that the link has a
> "default" label for LSPs terminating at E.
>
> >
> > - When  creating a label stack  with explicit null somewhere
> > in the middle,
> >   one MAY put it there, but one SHOULD simply remove it.
>
> I think I just talked myself out of removing the restriction ;-) except if
> we need to document existing practice.
>
> cheers
> Dave
>
>