The MPLS WG Archive

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

What you are describing is an implementation problem, the ping request
should be processed (and reply generated) at interface Intf3 so even if the
Intf4/Intf2 link is used, the reply source address should be Intf3.

IMO there are other problems introduced if the router loopback address is
included in lieu of numbered interfaces. It would hide subtle problems (such
as wrong link of a link bundle between two LSRs being used).

Dave

> -----Original Message-----
> From: Igor Achkinazi [mailto:achkinazi@hotmail.com] 
> Sent: Thursday, April 08, 2004 11:21 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: mpls@UU.NET
> Subject: RE: MPLS Ping question
> 
> 
> Dave,
> 
> I understand that in described case a source IP address of 
> MPLS Echo Reply 
> packet will not match Downstream Mapping TLV of previous 
> probe. There is no 
> easy way to find which IP address belongs to which router, so the 
> implementation can compare only IP address of reply packet 
> with IP addresses 
> from Downstream Mapping TLV of previous step of the traceroute.
> 
> In general case though, IP address of Echo Reply does not 
> need to match IP 
> addresses from Downstream Mapping TLV of previous probe, 
> because there can 
> be parallel links where one is used for MPLS traffic and 
> another is used for 
> IP traffic (and MPLS Echo Reply is IP packet, not MPLS):
> 
>     Intf1<----MPLS--->Intf3
> LSR A                     LSR B
>     Intf2<----IP----->Intf4
> 
> where LSR B is a downstream for LSR A.
> 
> In this case Downstream Mapping TLV will have Intf3 IP 
> address, but IP 
> address from Echo Reply will be equal to Intf4 IP address.
> 
> May I suggest including Router ID into MPLS Ping packet and 
> into Downstream 
> Mapping TLV, one per downstream interface, so this confusion will be 
> unambiguously resolved? This way we will always know which 
> router is sending 
> MPLS Echo Reply and list of downstream routers in respect to previous 
> traceroute probe.
> 
> Thank you,
> Igor
> 
> 
> 
> >From: "David Allan" <dallan@nortelnetworks.com>
> >To: "'Igor Achkinazi'" <achkinazi@hotmail.com>
> >CC: "'mpls@UU.NET'" <mpls@UU.NET>
> >Subject: RE: MPLS Ping question
> >Date: Thu, 8 Apr 2004 10:37:42 -0400
> >
> >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/
> > >
> > >
> 
> _________________________________________________________________
> Watch LIVE baseball games on your computer with MLB.TV, 
> included with MSN 
> Premium! 
> http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00
200439ave/direct/01/