The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

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

Alia> In  this case,  LSP ping  would send  an IP  packet with  the specific
Alia> route's label and then the PSN's label. 

That isn't  my interpretation of the  draft.  I think the  intention is that
the LSP  ping carries only  the "PSN label".   That is, it carries  only the
label  or labels  needed to  get it  to the  egress PE,  not the  label that
identifies a particular VPN route (or a particular PWE3 pseudowire). 

If  you wanted  to  know not  only whether  a  particular LSP  leads to  the
intended PE,  but also whether that PE  is a proper egress  for a particular
VPN route (or PWE3  pseudowire), then I think you would need  to use the FEC
stack TLV in the body of the message to identify that VPN route.


Alia> I.e., consider if 
Alia> a packet comes in with a PSN label, PW label, and then an IPv4 Explicit 
Alia> NULL, as specified in Section  5.3:
Alia>     "To test an LSP that carries non-IP traffic, before injecting ICMP
Alia>     and MPLS ping messages into  the LSP, the IPv4 Explicit NULL label
Alia>     should be prepended to such messages. The ingress and egress LSR's
Alia>     must follow the procedures defined in [LABEL-STACKING]"


I'd  agree that  this is  a  strange passage  ;-) Remember  though that  the
context is RSVP-TE only. I'd guess  that the purpose of the explicit null is
to counteract the effect of the RSVP-TE L3PID field.