The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

I have a few questions on MPLS ping, particularly as it applies to 
pseudo-wires and L3VPNs.  For a simple non-hierarchical TE-LSP or LDP, it 
seems to be viable (though rather complex to implement) and to depend upon 
knowing an alternate IP only route for every ingress LER in the network.

First, for pseudo-wires, it appears to me that MPLS ping is using the 
bottom-of-stack bit to help make a forwarding decision.  I.e., consider if 
a packet comes in with a PSN label, PW label, and then an IPv4 Explicit 
NULL, as specified in Section  5.3:
    "To test an LSP that carries non-IP traffic, before injecting ICMP and
    MPLS ping messages into the LSP, the IPv4 Explicit NULL label should
    be prepended to such messages. The ingress and egress LSR's must
    follow the procedures defined in [LABEL-STACKING]"

Now, normally, the PSN label (if present) would be popped off and then the 
PW label would be consulted as for how to forward the packet.  The PW label 
indicates the outgoing interface and that the packet inside should be 
encapsulated according to the pseudo-wire type.  However, with MPLS ping, 
if the bottom-of-stack bit is not set, then the hardware must consider the 
label underneath the PW label, discover that it is an IPv4 Explicit NULL 
label and treat the packet accordingly.

This indicates to me that the forwarding paradigm has changed to support 
this - now the forwarding decision is made as a result of not just the 
20-bit label, but also the bottom-of-stack bit.

Am I missing something here?  The solution could be changing the label 
stack to be PSN label, Router Alert Label, PW label.  Then the software 
would look at the PW label and underneath and determine that it is an MPLS 
ping packet (in some fashion).

A similar question applies for L3VPNs.  First, let me quote briefly from 
2547bis about the label distribution.

   "Suppose that a PE has assigned label L to route R, and has
    distributed this label mapping via BGP.  If R is an aggregate of a
    set of routes in the VRF, the PE will know that packets from the
    backbone which arrive with this label must have their destination
    addresses looked up in a VRF.  When the PE looks up the label in its
    Label Information Base, it learns which VRF must be used.  On the
    other hand, if R is not an aggregate, then when the PE looks up the
    label, it learns the egress attachment circuit, as well as the
    encapsulation header for the packet.  In this case, no lookup in the
    VRF is done.

    We would expect that the most common case would be the case where the
    route is NOT an aggregate."

So, my concern here is for the case where the route is not an aggregate and 
the label indicates the egress attachment circuit as well as the 
encapsulation header for the packet.

In this case, LSP ping would send an IP packet with the specific route's 
label and then the PSN's label.  However, the egress LER would look at the 
specific route's label and immediately forward the packet, whatever it 
contained, to the egress attachment circuit.

My understanding is that certain implementations do aggregate the routes in 
a VRF together so that an egress lookup in the VRF is done.  However, 
certain implementations do not, and 2547bis expects this to be the most 
common case.

Three other concerns are as follows:

1) Setting the TTL of all labels except the top label to 1 doesn't seem 
viable for the LDP LSP over an RSVP LSP, unless the RSVP LSP is in uniform 
mode.  I.e., suppose that the ingress of the LDP LSP wishes to send an LSP 
ping, and, furthermore, that the LDP LSP enters an RSVP LSP at that 
ingress, but the RSVP LSP ends before the egress of the LDP LSP under 
consideration.
In that case, if the RSVP LSP is not doing the uniform TTL mode, the TTL of 
the LDP LSP's label will be exposed and used, but be too small.

2) For the trace-route case with an intermediate router which doesn't 
support MPLS ping, I am not clear on how/why a further router would include 
the DOWNSTREAM_MAPPING TLV, since that wouldn't be in the Echo Request, 
because the ingress doesn't have an appropriate DOWNSTREAM_MAPPING TLV to 
insert in, due to the non-supportive intermediate router.  Perhaps it would 
be clearer if the ingress could specify, via a flag, that a 
DOWNSTREAM_MAPPING TLV should be included.

3) Also, it's not clear to me how well the trace-route mode would work with 
LSPs which are not using the uniform model.  I.e., if one were to set all 
the TTL of all the labels underneath the top one to 1, then it wouldn't 
matter how much you increased the TTL of the top label - when that LSP 
ended, the trace-route mode would go to the next hop always.  Of course, 
you would notice this due to differences in the DOWNSTREAM_MAPPING, but 
that doesn't help in tracing the LSP, and it wouldn't indicate a 
control-plane problem, as was intended, but simply that the top LSP was not 
using the uniform model.

Thanks for any responses,
Alia Atlas