The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDEB03BC6@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> 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 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:
> 
> 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 curren
> t 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


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


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