The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jul> msg00151



[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]

  • From: "Irfan Lateef" <irfanlateef@hotmail.com>
  • Date: Wed, 11 Jul 2001 16:13:44 -0400
  • Cc: rbonica@MCI.NET, yakov@juniper.net, dcooper@gblx.net, mpls@UU.NET, mpls-ops@mplsrc.com
  • X-OriginalArrivalTime: 11 Jul 2001 20:13:45.0117 (UTC) FILETIME=[FCAAFCD0:01C10A45]
  • X-Originating-IP: [65.112.106.16]

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