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

[Ronald Bonica <[e-mail]>]

Hi Carlos,

Good question..... Responses inline......

                        Ron

> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[e-mail]]
> Sent: Wednesday, March 18, 2015 8:38 PM
> To: Ronald Bonica
> Cc: Lizhong Jin; Mach Chen; Gregory Mirsky; draft-bonica-mpls-self- 
> [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: MPLS RT Review -- draft-bonica-mpls-self-ping-04 - LSP 
> Self-Ping
> 
> 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?

[RPB]
We have already agreed not to use the LSP Ping format. But now we have to decide which format to use.....

 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. 


[RPB]
It is possible that an iLSR might signal more than 65K LSPs simultaneously. In that case, we would need to run more than 65K LSP Self-ping sessions simultaneously. So, we need a 32-bit identifier. The UDP source port is only 16 bits. Likewise for 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.

LSP Self-ping can't diagnose the problem of mis-programmed LSPs. It can only confirm that the LSP is as healthy as it is going to get.

                                                          Ron

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