The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

Hi Ken,

I am affraid if you don't use the RSVP RESV msg the return of LSP-ping
packet your response may fail in the same way as the initial ICMP ping
failed. Remeber the assumption here is that the data path is broken and
control path fine. 

The current sequence seems to be following:

Step 1: 

Ingress LSR is sending regular ICMP pings via the LSP_X

Two cases:

A) pings are returned OK (LSP_X is fine)
B) pings are lost
   1. - LSP_X is fine and return path is broken
   2. - LSP_X is broken by itself

If B then goto step 2.

Step 2: 

Ingress LSR is sending UDP LSP-pings via LSP_X

Two cases:

A) UDP LSP-pings arrive on the tail (egress) and ECHO is copied into
RSVP RESV msg, then returned to the ingress head proving that LSP_X is
fine just there was some issue with the return path of the ICMP from
Step 1.

B) LSP1's data plane is broken by itself somewhere so the tail (R4)
never receives the LSP-ping and R1 never receives the LSP_ECHO object in
the RESV msg.


R.

> Ken Nagami wrote:
> 
> Hi Ping,
> 
> >> You don't give a message type for the LSP-ping.  Were you thinking of
> >> a new message?  Perhaps the Notify message could be used?
> >>
> 
> >> For LSP-ping messages, the echo packets are encapsulated in UDP with a
> >> well-known port number. At the egress, the LSR picks up the echo by
> >> "listening" to the UDP port, and replies them back in Resv. I didn't
> >> consider the Notify message.... Let me think about it.
> 
> Why do you use a RSVP RESV message for an LSP-ping reply?
> I think it is better to use an UDP packet which is the same as
> LSP-ping echo message. If you don't use an MPLS control
> message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for
> all kind of LSP, such as a static LSP and an LSP established by LDP.
> 
> I think the section 4 in the draft-satoru-mpls-1hop-lsp-00.txt is the same
> motivation for your draft.
> 
> Regards,
> 
> Ken Nagami