The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Curtis,

Let me explain my point a bit more. This has already been stated by
Alia. RFC2547bis says:

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

As you can see no VRF lookup is a possible approach for L3VPN. The following text assumes no VRF lookup at the egress PE:

Based on the example in the draft, LSP ping could send an IP packet with the specific route's VPN label and then the PSN's label.  However, the egress LER would look at the specific route's VPN label and immediately forward the packet, whatever it contained, to the egress attachment circuit. 

Please note that since the LSP is an IP-carrying LSP,  based on the draft no explicit null is required and therefore S=1 for the bottom most label. 

My question is what criteria is used at the egress LSR to identify and terminate LSP-ping packets? There might be 3 solutions:

1) Use explicit null label even though the traffic is IP, and detect LSP-ping
packets from S=0 in the VPN label. This may require HW change, because current implementations don't look at S-bit.

2) Only push the PSN label, and encode the VPN  label in the echo-request. 

3) In echo-request set the TTL=0 for VPN label, and detect the LSP-ping by
sending the TTL=0 packets to the OAM module. This may also require HW change
as I am not sure current implementations check the TTL of the VPN label.

My suggestion was the 2nd one. What method do you suggest?

Thanks,
-Shahram



> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, December 18, 2002 6:38 PM
> To: Shahram Davari
> Cc: 'curtis@fictitious.org'; 'Kireeti Kompella'; 'mpls@UU.NET'
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> 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
>