The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Vpns vs explicit null label
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> |
|