The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi Igor:

The short answer is downstream mapping is not part of the processing rules
for the request termination (only processes FEC stack and received label
stack). The presence of the Downstream Mapping TLV in the request is
effectively a flag saying "send me one in the reply" only. 

The error code in the reply will indicate correct forwarding as the label
and FEC in the FEC stack will align, it is up to the originator of the ping
to figure out that what actually happened does not concur with the
downstream mapping TLV from the previous step of the traceroute (IP address
of reply will not match expected downstream router). At that point to be
truly rigorous, you'd need to back TTL up one and see if downstream mapping
had changed.

cheers
Dave

> -----Original Message-----
> From: Igor Achkinazi [mailto:achkinazi@hotmail.com] 
> Sent: Wednesday, April 07, 2004 1:01 PM
> To: mpls@UU.NET
> Subject: RE: MPLS Ping question
> 
> 
> To avoid confusion I want to rephrase my question and clarify 
> the scenario I 
> have a question about.
> 
> Let's think about path established using LDP, and a network 
> administrator 
> sending MPLS trace-route Echo request from ingress. This MPLS 
> Ping packet 
> ends up at some LSR A in the middle of MPLS cloud:
> 
>                  B ----------> (after topology change)
>                 /
> -------------> A
>                 \
>                  C ----------> (before topology change)
> 
> When MPLS trace-route Echo request (not regular MPLS ping) 
> comes to LSR A 
> before topology changes, LSR A reports C as a downstream router in 
> Downstream Mapping TLV. Immediately after that IGP reroute 
> causes LDP to 
> reconfigure it's downstream information on LSR A. When 
> ingress sends a new 
> MPLS Echo request with TTL incremented LSR A forwards it to 
> B, but MPLS Echo 
> request has old Downstream Mapping TLV reported by A before, 
> which has label 
> and IP address from C. So B will report FEC/Label mismatch.
> 
> I cannot find how the draft covers such scenario
> 
> Thank you,
> Igor Achkinazi
> 
> 
> 
> 
> >From: "Igor Achkinazi" <achkinazi@hotmail.com>
> >To: mpls@UU.NET
> >Subject: MPLS Ping question
> >Date: Mon, 05 Apr 2004 18:42:02 +0000
> >
> >Hi,
> >
> >There were several discussions about MPLS Ping already, but 
> I could not
> >find the answer to following question about trace-route 
> mode: assume that 
> >just before reroute some midpoint LSR X responds with its current 
> >downstream information (label, interface, hashing 
> addresses), so MPLS Ping 
> >initiator will build a packet meant to go to the old 
> downstream in respect 
> >to LSR X. However at the time LSR X gets new MPLS Ping 
> packet (with TTL 
> >incremented by one), its hardware will be configured with a 
> new forwarding 
> >information and the packet will be forwarded to a new 
> downstream router 
> >that will complain about FEC/Label mismatch.
> >
> >Since trace-route fails because of topology change, it should be 
> >repeated
> >again. But network operator sending MPLS Ping from ingress 
> router might not 
> >know that some LSR along the way just did a reroute, so he 
> would assume 
> >that the LSP is broken. How the operator can differentiate 
> between topology 
> >changes and broken LSP, since LDP topology changes are not 
> visible to him?
> >
> >Thank you,
> >- Igor Achkinazi
> >
> 
> _________________________________________________________________
> MSN Toolbar provides one-click access to Hotmail from any Web 
> page - FREE 
> download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
> 
>