The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]
Hi all, The draft-pan-lsp-ping-00.txt address just the detection of errors in the dataplane where as ping is also being used to measure the round-trip-delays. So I would suggest that this draft be extended to atleast the full capability of the IP version of the ping. Namely if the ping packet reached the destination and if there exists an LSP in the reverse direction then it should send the return through that LSP. This will allow the host to measure the round-trip-delays when the LSP is a good bidirectional LSP.( which happen to be one of my requirements!) In fact, taking the idea to the next level, there should be a complete proposal of ICMP over MPLS which may implement all the messages in RFC 792 and come up with a general response from the tail end which is signalling protocol independent. The tunproto-00 draft can be good starting point for this. Dave Allen mentioned earlier in this thread that they are coming out with a draft framework. I agree that there should be one comprehensive solution to all the ICMP related issue. But I want to wait and see if they address these issues. My 2 cents. Irfan Lateef >From: Robert Raszuk <raszuk@cisco.com> >Reply-To: raszuk@cisco.com >To: erosen@cisco.com >CC: Ron Bonica <rbonica@MCI.NET>, Yakov Rekhter <yakov@juniper.net>, >Dave Cooper <dcooper@gblx.net>, mpls-list <mpls@UU.NET>, mpls-ops ><mpls-ops@mplsrc.com> >Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt] >Date: Wed, 11 Jul 2001 12:07:38 -0700 > >Eric, > > > We just need to invent a way to ensure that the UDP packet follows >the IP > > hop-by-hop path, rather than being sent through an LSP. > >Well I am afraid this is not easy. What you need to invent is a way not >just for tail not to send the proposed UDP reply the same way as they >send ICMP one but also to make sure each subsequent node does the same. >If a network would be managed by some offline tool yes the tool's >notification by the tail would be enough. If this is attractive solution >I don't know - could be an easy LSP-ping reply option. > >I understand that there is great benefit to eliminate the control plane >usage but I am afraid nothing will be as realiable as either RSVP RESV >(the assumption is that the LSP is up) or IGP flooding (again control >plane). I also fail to come up with anything more simpler then just load >this msg on the RSVP RESV. > >I was watching the thread closely as it addresses one of the most >popular recently customer demand in some extent and would say that not >going forward with this proposal would hurt live deployed networks or >make implementations not interoperable. > >R. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com |
|