Subject: RE: Last call on LSP Ping

From: Shahram Davari <[email-masked]>
Date: Thu, 19 Dec 2002 11:33:36 -0800

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:[email-masked]]
> Sent: Wednesday, December 18, 2002 6:38 PM
> To: Shahram Davari
> Cc: [email-masked]'; 'Kireeti Kompella'; [email-masked]'
> Subject: Re: Last call on LSP Ping 
> 
> 
> 
> In message 
> <[email-masked]
> >, 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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 19 Dec 2002 16:04:58 -0500

In message <[email-masked]
> 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 pac
> ket, 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 termin
> ate LSP-ping packets? There might be 3 solutions:
> 

I was suggesting you set TTL=1 on the VPN label and include an
explicit null label, also with TTL=1.  Others can speak up if the
change will be a problem.

Curtis

---

From: Alia Atlas <[email-masked]>
Date: Fri, 20 Dec 2002 09:35:58 -0500

At 04:04 PM 12/19/2002 -0500, Curtis Villamizar wrote:
> > packets from S=0 in the VPN label. This may require HW change, because 
> curren
> > t implementations don't look at S-bit.
> >

Currently the incoming TTL, which I believe is that checked for the TTL 
expiring, is based upon the top incoming label.  I.e., if the PSN label is 
still on the packet when it reaches the egress, then its TTL would be used, 
rather than the TTL of the VPN label underneath.  Of course, if the PSN 
label is not there, because of PHP, then the incoming TTL would be that of 
the VPN label, and this could work - but that requires PHP :-(.

Alia

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 20 Dec 2002 10:47:15 -0500

In message <[email-masked]>, Alia Atlas 
> the VPN label, and this could work - but that requires PHP :-(.

We then have to insist that in forwarding, an implementation look
beneath the VPN label if the S bit is not set and deliver locally if
the next label is an explicit null.

If the VPN label is not included many ECMP for LDP implementations at
midpoint will not use the same path for the test traffic (hash based
on lower labels only) and the test traffic will not take the same path
as the VPN traffic which is intended to be tested.

Curtis