Re: [mpls] MPLS RT Review -- draft-bonica-mpls-self-ping-04 - LSP Self-Ping

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Ron,

Thanks for this update — one particular line caught my attention, which refers to the following in the draft:
   o  UDP Source Port is any port selected from the dynamic range
      (49152-65535) [RFC6335]
   o  UDP Destination Port is any port selected from the dynamic range

I was thinking that the requirement is for the source to be able to identify the packet itself. For that, you are using the “Session-id”. What is the advantage of using the LSP Ping format with an Echo Reply message type, versus using a more generic approach? For example, you could use an opaque UDP packet, and bind the Session ID to the source port. Or use an ICMP Echo and bind the Session ID to the ICMP Echo Identifier, and the Retries to the ICMP Echo Sequence Number. As you had mentioned, all is needed is that the source can identify the self packet, without affecting interop.

The part that is a harder problem to solve is the issue about false positives — if the MPLS-encapsulated self-ping packet does not make it to the egress but it is forked mid-LSP (e.g., broken LSP), it will appear as if the LSP is working.

Thanks!

— Carlos.


> On Mar 11, 2015, at 8:31 PM, Ronald Bonica <[e-mail]> wrote:
> 
> Carlos, Greg, Mach and Lizhong,
> 
> Thanks for your thoughtful review. Having reflected on your comments, I see that a very significant piece of text is missing from the document. The following is a rough estimation of that text.
> 
> This text, if accepted, should address about half of your comments. Standby for more emails addressing remaining comments.
> 
>                                                        Ron
> 
> Missing text
> =========
> 
> Unlike LSP Ping and S-BFD, MPLS Self-ping is not a general purpose MPLS OAM mechanism. It is applicable only when the following conditions are true:
> 
> - An application  (e.g., RSVP) has received notification that downstream forwarding state either a) has been installed or b) will be installed shortly
> - The application needs to disambiguate the above mentioned message. For example, the application needs to prevent traffic from being routed over an LSP until downstream forwarding state has actually been installed
> - The application does not require confirmation of the correctness of downstream forwarding state, because there is a very high probability that downstream forwarding state is correct
> - In order to obtain the required information, the application must invoke procedures that are viable when control plane resources are extremely scarce (e.g., after a network event that causes RSVP to establish many LSPs simultaneously). These procedures can consume only limited control plane resource on the ingress LSR and cannot consume any control plane resources on the egress LSR.
> 
> LSP Self-ping is not a general purpose OAM mechanism because it cannot detect some classes of failure.  For example, LSP Self-ping cannot detect a misprogrammed  LSP.  Furthermore, LSP Self-ping cannot detect failures in LSPs that were signaled using LDP independent mode. However, when the above listed conditions are true, a general purpose OAM mechanism is not required. In this case, the requirement to conserve control plane resources outweighs the requirement to detect all classes of failure.
> 
> MPLS Self-ping is not an extension to LSP Ping. It is a distinct protocol. MPLS Self-ping listens for input on one UDP port, while LSP Ping listens for input on another. Having received input, the two protocols behave differently from one another. While the two protocols are named similarly and share a common message format, they are distinct from one another. Therefore, this document does not update [RFC 4379]
> 
> 
> 
> 
> 
> 
> 
>