The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS Ping question
IMHO the address should always be as precise as possible in a traceroute, so the one used would be independent of the presence of the downstream mapping TLV. If there is an interface address it should be used... I would agree that some clarification in the draft would be useful, hope the authors agree.. Dave > -----Original Message----- > From: Igor Achkinazi [mailto:achkinazi@hotmail.com] > Sent: Thursday, April 08, 2004 12:38 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: mpls@UU.NET > Subject: RE: MPLS Ping question > > > Dave, > > Section "4.4. Sending an MPLS Echo Reply" of > draft-ietf-mpls-lsp-ping-05.txt > states: "The source IP address is a routable address of the replier". > > It should say something like this: "In case Downstream Mapping TLV is > present in incoming MPLS Echo Request, the source IP address > must be equal > to IP address of an interface from that TLV, which belongs to > the replier. > If Downstream Mapping TLV is not present in MPLS Echo > Request, the source IP > address is any routable address of the replier." > > Such clarification will be much better than including of > router loopback > address into MPLS Ping packet. > > Thank you, > Igor > > > > > >From: "David Allan" <dallan@nortelnetworks.com> > >To: "'Igor Achkinazi'" <achkinazi@hotmail.com> > >CC: mpls@UU.NET > >Subject: RE: MPLS Ping question > >Date: Thu, 8 Apr 2004 12:14:36 -0400 > > > >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/ > > > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.com/go/onm00200415ave/direct/01/ > > |
|