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

From: Ronald Bonica <[email-masked]>
Date: Thu, 12 Mar 2015 00:31:12 +0000

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]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 Mar 2015 19:37:35 +0000

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 <[email-masked]> wrote:
>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 19 Mar 2015 15:23:43 +0000

Hi Carlos,

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

                        Ron

> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Wednesday, March 18, 2015 8:38 PM
> To: Ronald Bonica
> Cc: Lizhong Jin; Mach Chen; Gregory Mirsky; draft-bonica-mpls-self- 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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:
> 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 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]
> >
> >
> >
> >
> >
> >
> >
> >