The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Apr> msg00048



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLS Ping question

  • From: "Igor Achkinazi" <achkinazi@hotmail.com>
  • Date: Thu, 08 Apr 2004 15:21:10 +0000
  • Cc: mpls@UU.NET
  • X-OriginalArrivalTime: 08 Apr 2004 15:21:11.0481 (UTC) FILETIME=[1FCC3290:01C41D7D]
  • X-Originating-Email: [achkinazi@hotmail.com]
  • X-Originating-IP: [208.246.215.201]

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/onm00200439ave/direct/01/