The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jan> msg00168



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Vpns vs explicit null label

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Thu, 30 Jan 2003 10:25:38 -0500
  • Cc: erosen@cisco.com, Alia Atlas <aatlas@avici.com>, francis.arts@alcatel.be, mpls@UU.NET

Hi Eric:

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

Agreed.

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

I take it this is behavior of at least one implementation?

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

If, for example, I was trying to use LSP ping to test a PW via injecting
LSP-PING into the PW (instead of using a FEC stack at the PSN level).....

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

I would assume if it was originated by an ingress simply as a PID,then the
same would be true. The egress is in control w.r.t. all forwarding layers,
and the label only has significance for protocol multiplexing.

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

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

Reasonable summary of what I concluded. Don't necessarily like it but it
seems to document existing practice.

cheers
Dave

<snipped to end>