Re: [mpls] LSP traceroute failure with Inter-AS MPLS

	Yes, for reference, the draft is called draft-nadeau-mpls-interas-lspping-03.txt

On Apr 14, 2010, at 4:27 PM, Nitin Bahadur wrote:

> 
> Hi Ilya,
> 
>   There is an expired draft by George Swallow & Tom Nadeau that tries to
> address the problem you are encountering.
> 
>  mpls-tunneling will not help. Mainly because lsp-traceroute is used as a
> diagnostic tool to detect where a failure is in the network. If there is a failure
> in the network, then the echo request/response will unlikely make it to the 
> egress PE.
> 
>  So for fault isolation, you need the transit nodes to respond back. How they
> respond back is theorized in the above mentioned draft.
> 
> Thanks
> Nitin  
> 
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On 
>> Behalf Of Ilya Varlashkin
>> Sent: Wednesday, April 14, 2010 7:44 AM
>> To: IETF MPLS
>> Subject: [mpls] LSP traceroute failure with Inter-AS MPLS
>> 
>> Hi,
>> 
>> I was doing some LSP traceroutes across AS boundaries (on real-world
>> network) and missed replies from some intermediate routers in 
>> the target AS. Digging a bit deeper I've found following: if 
>> some AS has BGP-free core and its internal (core) routers 
>> don't have routing information for foreign prefixes, then 
>> these internal routers won't be able to send LSP Echo Replies 
>> to originator of the traceroute. Normal end-to-end traffic is 
>> delivered without problems both ways because PE routers in 
>> such AS put two labels on the stack (using labelled-unicast) 
>> when sending packets towards foreign routers, so core routers 
>> don't have to know how to reach foreign PE.
>> 
>> Before going to our routers' vendor I've looked through 
>> RFC4379 once more to check whether it's an implementation or 
>> specification issue. It looks like there is nothing in RFC to 
>> address above mentioned scenario, so looks like specification issue. 
>> 
>> Similar problem with normal traceroute within MPLS L3VPN 
>> environment is addressed by ICMP-tunnelling trick - 
>> forwarding ICMP message along the same path as original 
>> packet that caused generation of that ICMP message. Wouldn't 
>> the same approach work with LSP ping? All what's needed, from 
>> protocol PoV, is to say that if an intermediate router (not 
>> final destination!) needs to send a reply (because TTL 
>> expired) doesn't have route back to originator of LSP ECHO 
>> then it should send reply along the same path as original LSP 
>> ECHO. I.e. if PE1 sends LSP ECHO request to PE2 over 
>> intermediate router P, and P would use label L1 and interface 
>> INTF1 to send packets towards PE2, then P should also use 
>> label L1 and interface INTF1 when it needs to send replies 
>> back to PE1.
>> Would doing so cause any problems? If not, should we ammend 
>> specification of LSP ping/traceroute?
>> 
>> Cheers,
>> iLya
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 