The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Dec> msg00357



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

Last call on LSP Ping

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Wed, 18 Dec 2002 18:37:32 -0500
  • cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, "'Kireeti Kompella'" <kireeti@juniper.net>, "'mpls@UU.NET'" <mpls@UU.NET>


In message <4B6D09F3B826D411A67300D0B706EFDEB03BC1@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> Curtis,
> 
> Could you please explain in simple terms how can one check the
> inner LSP's connectivity in L3VPN and L2VPN? Consider the case
> where no VRF table lookup is done at the egress.
> 
> Thanks,
> -Shahram 

You'll have to first explain to me how you do a VPN without doing a
VRF lookup.  The LSP for normal VPN traffic can't just terminate on
the loopback.  The last label normally drives the VRF lookup.  If "S"
is clear or TTL expires, then the packet is directed to the loopback
to IP and UDP port 3503 for MPLS-ping processing.  MPLS-ping can only
check the VRF lookup in the control plane.  This was the point of the
statement "Since the MPLS-ping 'echo request' packets are extracted no
further downstream than the egress LSR, faults at the egress in
decapsulating and directing traffic further are not detected." that
now appears in the fourth paragraph of "1. Introduction".

Did I miss something?

Curtis