The MPLS WG Archive

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



[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:10:14 -0400
  • Cc: rbonica@MCI.NET, yakov@juniper.net, dcooper@gblx.net, mpls@UU.NET, mpls-ops@mplsrc.com
  • X-OriginalArrivalTime: 11 Jul 2001 20:10:15.0042 (UTC) FILETIME=[7F741620:01C10A45]
  • X-Originating-IP: [65.112.106.16]

Robert,
See my comment below.
Irfan Lateef

>
>Eric> I guess  I'm also having  some trouble understanding why  the 
>LSP-ping
>Eric> mechanism needs to be specific  to a particular control protocol.  
>Why
>Eric> not just  use a  UDP packet to  send the  response back to  the 
>tunnel
>Eric> head?  It  won't necessarily travel  back along the control  path, 
>but
>Eric> does that really matter?
>
>Robert> It may disappear the same way  as the original icmp test so the 
>head
>Robert> will assume that LSP is down while it is in fact up.
>

IF this UDP packet cannot be delivered to the head end, will it
not generate an ICMP packet to the tail end? And if it does one
can send a message to the NMS.

Secondly, if UDP is a concern then why cant we use TCP, open a
socket and send the message, so the tail end can be sure
that the message will indeed be delivered.

>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.   That  
>would
>eliminate  the  worry  about  MPLS   data  plane  problems  in  the  
>reverse
>direction.  It does leave a hole  in the situation where the RSVP-TE 
>control
>plane is working  although there is no IP connectivity from  the tail to 
>the
>head, but that doesn't seem like too big of a hole.
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com