Subject: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Nov 2014 16:38:51 +0000

Folks

At IETF 91, the following points were raised with regard to draft-bonica-mpls-self-ping:

1) Why not use BFD?
2) Self-ping does not diagnose FIB programming errors in which an LSR other than the egress de-encapsulates and forwards the packet.
3) How does Self ping verify a bidirectional LSP's readiness to carry traffic in both directions?
4) Why does MPLS Self ping use MPLS Echo packets, as opposed to ICMP echo packets or some other packet format?

Responses follow:

1) Why not use BFD?

Self Ping is an extremely light-weight protocol. A typical Self Ping session emits one or two packets and terminates less than one second after initiation. Self-ping requires no configuration or control plane resources on the egress LSR. 

By contrast, BFD is designed to verify bi-directional connectivity over a longer period of time. Therefore, MPLS Self Ping is appropriate in environments where BFD is too resource intensive.

2) Self-ping does not diagnose programming errors in which an LSR other than the egress de-encapsulates and forwards the packet.

Self Ping is designed to verify LSP readiness without consuming control plane resources on the egress router. It is not designed to diagnose programming errors in which an LSR other than the egress de-encapsulates and forwards the packet. Mechanisms that diagnose such issues are available [RFC 4950]. However, they are more resource intensive.

3) How does Self ping verify a bidirectional LSP's readiness to carry traffic in both directions?

In order to verify bidirectional LSP readiness, RSVP instantiates two LSP Self Ping sessions, one at each end of the LSP. The LSR at one end of the LSP initiates a self ping session when it receives a RESV message. The LSR at the other end of the LSP initiates a Self Ping Session when it sends a RESV message. Each LSP endpoint forwards traffic over the LSP only after the LSP Self Ping session terminates successfully

4) Why does LSP Self Ping use MPLS Echo packets, as opposed to some other packet format?

LSP Self Ping could have used many packet formats. The only hard requirement was to have one 64-bit field in which the 64 bit session identifier could be encoded. The MPLS Echo packet was convenient because its Senders Handle is 64-bits long. 

I will update the draft to reflect this information.

Ron Bonica

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 19 Nov 2014 17:54:13 +0000

Hi Ron,

Please see below..

On 11/19/14, 11:38 AM, "Ronald Bonica" <[email-masked]> wrote:

>1) Why not use BFD?
>
>Self Ping is an extremely light-weight protocol. A typical Self Ping
>session emits one or two packets and terminates less than one second
>after initiation. Self-ping requires no configuration or control plane
>resources on the egress LSR.
>
>By contrast, BFD is designed to verify bi-directional connectivity over a
>longer period of time. Therefore, MPLS Self Ping is appropriate in
>environments where BFD is too resource intensive.
>
<Nagendra> I think this can be achieved by multiphop echo BFD control
packet sent as self destinated. IMHO, the size will be less for BFD packet
and still the validation can  be done without the control plane
involvement of egress node. Also with SBFD and BFD HW offload in egress, I
think it should not be a concern.

On the same line, I think, a deployment that is concerned about the
initial drops for few msec will also be concerned about the LSP health
(ex: continuous traffic blackholing due to DP failure) and may need BFD to
perform the check. So the use of BFD will help with both initial and
continuous check.

-Nagendra

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 19 Nov 2014 20:26:28 +0000

> packet sent as self destinated. IMHO, the size will be less for BFD packet and
> still the validation can  be done without the control plane involvement of
> egress node. Also with SBFD and BFD HW offload in egress, I think it should
> not be a concern.
> 

Nagendra,

Which of the following are you proposing?

1) The ingress LSR formats a BFD control message and encapsulates in UDP and IP. The IP address is that of the ingress LSR. The ingress LSR forwards the packet over the LSR under test. The egress LSR receives the packet and forwards it back to the ingress LSR, exactly as it would forward any other packet. The egress LSR never examines anything beyond the IP header.

2) Something else

If something else, what?

                                                   Ron

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 19 Nov 2014 23:56:33 +0000

Hi Ron,

On 11/19/14, 3:26 PM, "Ronald Bonica" <[email-masked]> wrote:

>1) The ingress LSR formats a BFD control message and encapsulates in UDP
>and IP. The IP address is that of the ingress LSR. The ingress LSR
>forwards the packet over the LSR under test. The egress LSR receives the
>packet and forwards it back to the ingress LSR, exactly as it would
>forward any other packet. The egress LSR never examines anything beyond
>the IP header.

Yes and I think this can be achieved with both traditional and SBFD.
 
>
>2) Something else
>
>If something else, what?
>
>                                                   Ron
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 20 Nov 2014 00:36:49 +0000

Nagendra,

If 1) is what you are proposing, there is virtually no difference between your proposal and what is documented in the draft. In either case:

- The egress LSR never looks beyond the IP header. It simply forwards the packet based upon IP destination.
- On the ingress node, the packet is forwarded to a dynamic UDP port. The application listening on that port is neither BFD nor MPLS Echo. It is LSP Self Ping.

The only difference between the two proposals is the format of the probe message.

                                                                        Ron

> -----Original Message-----
> From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2014 6:57 PM
> To: Ronald Bonica; [email-masked]
> Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from
> the mike
> 
> Hi Ron,
> 
> >>packet sent as self destinated. IMHO, the size will be less for BFD
> >>packet and  still the validation can  be done without the control
> >>plane involvement of  egress node. Also with SBFD and BFD HW offload
> >>in egress, I think it should  not be a concern.
> >>
> >
> >Nagendra,
> >

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 19 Nov 2014 19:28:00 -0800

Hi Ron,

Still trying to understand the need for the draft, hence, have few of questions and need clarifications. Appreciate your response in advance.

1. (clarification q) The Ingress LSR sends the Echo request, with destination IP address to self, and forwards to Egress LSR (sec 2), correct?  Is this the only thing which identifies the Ingress LSR or something else too?
2. What happens if there is LSP breakage or something and the Echo request ends up on transit LSR? Doesn't it process? I see that draft says, this will avoid control plane processing. How so? The packet is forwarded from ingress to egress, which means, the egress will have to process the packet i.e. look up the ip address to send it back to ingress.

Draft says "The egress LSR forwards the MPLS Echo message to its destination, the
   ingress LSR.  The egress LSR forwards the MPLS Echo message exactly
   as it would forward any other packet."

Could you explain, how egress forwards the packet back to ingress w/o looking up the packet IP header i.e. in the data plane and no additional control plane of OAM process?
3. Is the assertion that, if Echo Reply is received back at the ingress then it is failure, rather it should receive Echo Request back at Ingress, correct?
4. Why can't you use LSP proxy ping to self via Egress?

Will followup with additional questions, if any, based on your responses.

cheers
-sam

> On Nov 19, 2014, at 8:38 AM, Ronald Bonica <[email-masked]> wrote:
> 
> Folks
>

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 19 Nov 2014 19:39:22 -0800

BTW, the draft also proposes the IP destination as routable address and not local host address.
This is re-defining the semantics defined in RFC4379.
Secondly, as mentioned earlier, when there is LSP failure, the packet will be routed to destination address, as Echo request. which in this case is ingress LSR.

-sam
> On Nov 19, 2014, at 7:28 PM, Sam Aldrin <[email-masked]> wrote:
> 
> Hi Ron,
> 
>> On Nov 19, 2014, at 8:38 AM, Ronald Bonica <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Folks
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 20 Nov 2014 13:33:38 +0000

Hi Ron,

Yes. That is right.

This being a local matter to ingress, I am trying to say that BFD can also
be used, as a response to your initial email  that said, why BFD cannot be
used :)

Regards,
Nagendra

On 11/19/14, 7:36 PM, "Ronald Bonica" <[email-masked]> wrote:

>Nagendra,
>
>If 1) is what you are proposing, there is virtually no difference between
>your proposal and what is documented in the draft. In either case:
>
>- On the ingress node, the packet is forwarded to a dynamic UDP port. The
>application listening on that port is neither BFD nor MPLS Echo. It is
>LSP Self Ping.
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 20 Nov 2014 09:42:33 -0500

To me what is described in the draft seems like this is a description of a device/vendor feature that automates the basic procedures of 4379/etc.. This can and has been done for quite some time using other means such as onboard automated scripts/actions after paths are established/signaled. I say this not to be glib, but because I built such a thing about 10 years ago that has been deployed widely.  Also, as Sam says, there is some deviation from RFC4379 which we should ask is worth the additional complication (and required implementation + associated delay/etc...) versus just using the existing means. 

	The bottom line is that we should be asking ourselves whether or not this something we really need to standardize.

	—Tom

> On Nov 19, 2014:10:28 PM, at 10:28 PM, Sam Aldrin <[email-masked]> wrote:
> 
> Hi Ron,
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 20 Nov 2014 10:36:12 -0500

This is exactly what I said at Mic.
We have been deploying MPLS for a while and if such DP active verification was necessary, vendors have solved it without
standard specific solution, may that be BFD or self-ping.

One of the argument made was that client BFD session detects that “tunnel is active but DP is not”.
Does it imply there is some kind of UNI signaling going on between PE and CE to indicate that tunnel has become
active, commence data? And the idea is that PE will refrain notification until self-ping verify DP active?

If that is not the case then this technique is not even useful – self ping is not actually causing the DP to become active,
If it doesn’t become active in the time window, what is PE going to do?

/himanshu

From: mpls [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Thursday, November 20, 2014 9:43 AM
To: Sam Aldrin
Cc: Ronald Bonica; [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

            —Tom

On Nov 19, 2014:10:28 PM, at 10:28 PM, Sam Aldrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ron,

cheers
-sam

On Nov 19, 2014, at 8:38 AM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 20 Nov 2014 18:57:15 +0000

Hi,

Sort of summarizing what’s been stated but here’s my observation of draft-bonica-mpls-self-ping.

1.      LSP Ping and BFD MPLS already do what is being proposed.

2.      Ron needs a mechanism that is more efficient on egress LSRs, with respect to resources and operational aspects.

3.      Any probe packet having destination IP address as the ingress LSR has limitations in terms of how effective it can verify the DP readiness.

4.      The proposal by Ron is limited to those LSPs that signal via ordered mode (ex: LDP independent mode will not work) - same problem as (3).

If the intent of draft-bonica-mpls-self-ping is just to document what has been implemented or what is being implemented, I’d like to request followings to be captured in the document.

-        limitations (3 and 4) so that readers are aware of them.

-        usage of non-127/8 address as destination IP address in MPLS echo request/reply deviates from RFC4379.

If the intent of draft-bonica-mpls-self-ping is to advocate a mechanism for efficient MPLS DP readiness test, and I’d like to request that:

-        requirements (2) are well captured.

-        S-BFD be evaluated (as it addresses the efficiency requirements and does not have limitations described by 3 and 4).

Himanshu, I have one comment in-line below. Please look for [NOBO].

From: mpls [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Thursday, November 20, 2014 10:36 AM
To: Thomas D. Nadeau; Sam Aldrin
Cc: Ronald Bonica; [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

[NOBO] That is another interesting aspect of the whole solution. However, I believe that the problem scope of this document is much smaller: ingress LSR to detect readiness of RSVP signaled LSP. For RSVP signaled LSP, only the LSP that is “passing the test” can be tied to the tunnel as the active LSP, so at least the ingress LSR will not pump traffic into the tunnel without knowing whether DP end-to-end is ready or not. Assuming that there are other ways to get to the egress LSR from this ingress LSR, then the problem is solved. Otherwise the ingress LSR will drop the traffic but the problem is contained to that network node (i.e. packets are not traversing un-ready LSP).

Thanks!

-Nobo

/himanshu

From: mpls [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Thursday, November 20, 2014 9:43 AM
To: Sam Aldrin
Cc: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Shahram Davari <[email-masked]>
Date: Thu, 20 Nov 2014 19:15:33 +0000

Hi,

Since the procedures in this draft generates and processes the test packets on the same router and since other routers just forward normally,  why do we even need a draft? There is no interoperability requirements, and each vendor can implement what they like.

Thanks
Shahram

From: mpls [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Thursday, November 20, 2014 10:57 AM
To: Shah, Himanshu; Thomas D. Nadeau; Sam Aldrin
Cc: Ronald Bonica; [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi,

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 20 Nov 2014 11:56:55 -0800

Hi Nobo,

[without shooting the messenger]

In addition to what you listed, would like to see details on how  this ID will improve the performance at Egress should be clarified.
i.e. IP routing Vs OAM process (w/o FEC validation). Also, how this model helps if reverse IP path is not available (inter-domain, reverse path broken, non-routable ingress IP address) and to what gain?

There are many ways the LSP ping is being used, both as proprietary and also part of eco system.
If we go by the logic that this ID is needed, we will have slew of new ID’s detailing different usage models.

Hence, I totally agree with what Shahram and others have indicated.

-sam

> On Nov 20, 2014, at 11:15 AM, Shahram Davari <[email-masked]> wrote:
> 
> Hi,
> 
> From: mpls [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Shah, Himanshu
> Cc: Ronald Bonica; [email-masked] <mailto:[email-masked]>
> From: mpls [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Thomas D. Nadeau
> Cc: Ronald Bonica; [email-masked] <mailto:[email-masked]>
> On Nov 19, 2014:10:28 PM, at 10:28 PM, Sam Aldrin <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Ron,
>  
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>  
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 20 Nov 2014 23:23:10 +0000

Thanks for not shooting me Sam but I’m really not the messenger ☺

If there is a good proposal that covers set of LSP types with [virtually] no imitations, then documenting such proposal has an value, IMHO.

I’d agree that current contents of this document may not provide sufficient value to be pursued as an informational document, but I’m not hopeless that something could come out of this.

Thanks!

-Nobo

From: Sam Aldrin [mailto:[email-masked]]
Sent: Thursday, November 20, 2014 2:57 PM
To: Shahram Davari
Cc: Nobo Akiya (nobo); Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi Nobo,

-sam

On Nov 20, 2014, at 11:15 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks
Shahram

Hi,

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 20 Nov 2014 19:04:49 -0500

Understand documenting helpful techniques (more useful during restoration/re-optimization cases) as informational RFC, but I believe IETF usually
entertains proposals which has interoperability implications, AFAIK.

Which is what others are saying as well…

Thanks,
himanshu

From: Nobo Akiya (nobo) [mailto:[email-masked]]
Sent: Thursday, November 20, 2014 6:23 PM
To: Sam Aldrin; Shahram Davari
Cc: Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked]
Subject: RE: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Thanks!

-Nobo

From: Sam Aldrin [mailto:[email-masked]]
Sent: Thursday, November 20, 2014 2:57 PM
To: Shahram Davari
Cc: Nobo Akiya (nobo); Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi Nobo,

-sam

Hi,

Thanks
Shahram

Hi,

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Nov 2014 21:44:31 +0000

Hi Sam,

Response inline......

From: Sam Aldrin [mailto:[email-masked]]
Sent: Wednesday, November 19, 2014 10:28 PM
To: Ronald Bonica
Cc: [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi Ron,

1.      (clarification q) The Ingress LSR sends the Echo request, with destination IP address to self, and forwards to Egress LSR (sec 2), correct?
[RPB]  Almost. The Ingress LSR sends the Echo *Reply*, with destination IP address to self, and forwards to Egress LSR.

2.        Is this the only thing which identifies the Ingress LSR or something else too?
[RPB] The egress LSR doesn't need to identify the ingress LSR. It just forwards an IP packet based upon IP destination. The Ingress LSR identifies the Echo Reply as one that it sent to itself by matching the Sender Handle in the message with an LSP Ping Session ID.

3.      What happens if there is LSP breakage or something and the Echo request ends up on transit LSR? Doesn't it process?
[RPB] The transit LSR forwards the Echo Reply back to the ingress. The ingress declares the LSP to be ready to carry traffic, even though it is broken. That's why my original message says, "Self Ping is designed to verify LSP readiness without consuming control plane resources on the egress router. It is not designed to diagnose programming errors in which an LSR other than the egress de-encapsulates and forwards the packet. Mechanisms that diagnose such issues are available [RFC 4950]. However, they are more resource intensive."

I see that draft says, this will avoid control plane processing. How so?
[RPB] The draft says that it avoids control plane processing on the egress router. The egress router never looks beyond the IP header. It simply forwards based upon IP destination.

The packet is forwarded from ingress to egress, which means, the egress will have to process the packet i.e. look up the ip address to send it back to ingress.
[RPB] Yes. This happens on the forwarding plane.

4.      Is the assertion that, if Echo Reply is received back at the ingress then it is failure, rather it should receive Echo Request back at Ingress, correct?
[RPB] Exactly the opposite! If the Echo reply is received at the ingress, that is success

5.      Why can't you use LSP proxy ping to self via Egress?

[RPB] The procedures described in Section 3.2.1 of draft-ietf-mpls-proxy-lsp-ping consume control plane resources on the egress LSR.

                                ROn

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Nov 2014 21:46:45 +0000

Sam,

Exactly! LSP Ping and LSP Self-ping, are different protocols from one another. LSP Self-Ping is not an extension to LSP Ping. Although the two protocols share a common message format, they listen for input on different UDP ports. LSP Ping executes one set of procedures in response to input, while LSP Self-ping executes an entirely different set of procedures.

                                                                               Ron

From: Sam Aldrin [mailto:[email-masked]]
Sent: Wednesday, November 19, 2014 10:39 PM
To: Ronald Bonica
Cc: [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

-sam
On Nov 19, 2014, at 7:28 PM, Sam Aldrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Nov 2014 22:06:48 +0000

Tom,

You make a valid observation. LSP Self Ping is akin to GRE keep-alive. An ingress device sends a message to itself through the tunnel under test. The egress device simply forwards the message back to the ingress, based upon its IP destination. The egress device never even looks beyond the IP header.

The ingress device consumes the message that it produced. Because the ingress is both producer and consumer of the message, there are no interoperability requirements. Each ingress device could use a different message format, so long as the message contains enough information to associate it with an LSP Self-ping session.

Because there are no interoperability requirements between the ingress and egress, it not necessary to publish a document on the standards track.

However, LSP Self-ping procedures entirely local to the ingress router. The ingress router sends messages off the box that might be detected by counters, firewalls, intrusion detection devices, etc. Therefore, it is appropriate to publish an INFORMATION RFC explaining what this extra OAM traffic is.

                                                                                           Ron

From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, November 20, 2014 9:43 AM
To: Sam Aldrin
Cc: Ronald Bonica; [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

          —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 21 Nov 2014 17:17:03 -0500

> On Nov 21, 2014:5:06 PM, at 5:06 PM, Ronald Bonica <[email-masked]> wrote:
> 
> Tom,
>  

	I agree, Informational is cool.

	—Tom

>  
>                                                                                            Ron
>  
>  
> From: Thomas D. Nadeau [mailto:[email-masked] <mailto:[email-masked]>]

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 21 Nov 2014 22:19:56 +0000

Shah,

Because there are no interoperability implications, there is no need for a standards track RFC. However, because LSP Ping sends traffic off-box, an INFORMATIONAL RFC is appropriate. LSP Ping traffic might be detected by counters, intrusion detection devices and firewalls. We should document all of the OAM traffic that we generate.

                                   Ron

From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, November 20, 2014 7:05 PM
To: Nobo Akiya (nobo); Sam Aldrin; Shahram Davari
Cc: Thomas Nadeau; Ronald Bonica; [email-masked]
Subject: RE: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Thanks,
himanshu

Cc: Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked]<mailto:[email-masked]>

Thanks!

-Nobo

Hi Nobo,

-sam

Hi,

Thanks
Shahram

Hi,

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 21 Nov 2014 19:28:25 -0500

Makes sense.. OK.
/himanshu

From: Ronald Bonica [mailto:[email-masked]]
Sent: Friday, November 21, 2014 5:20 PM
To: Shah, Himanshu; Nobo Akiya (nobo); Sam Aldrin; Shahram Davari
Cc: Thomas Nadeau; [email-masked]
Subject: RE: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Shah,

                                   Ron

Cc: Thomas Nadeau; Ronald Bonica; [email-masked]<mailto:[email-masked]>

Thanks,
himanshu

Thanks!

-Nobo

Hi Nobo,

-sam

Hi,

Thanks
Shahram

Hi,

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 24 Nov 2014 22:02:54 +0000

Hi Nobo,

Inline……

Sent: Thursday, November 20, 2014 1:57 PM

Hi,

-          usage of non-127/8 address as destination IP address in MPLS echo request/reply deviates from RFC4379.
[RPB]
Both good points. I will catch both of these in the next version of the draft.

-          S-BFD be evaluated (as it addresses the efficiency requirements and does not have limitations described by 3 and 4).
[RPB]
Again, both good points. I will catch both of these in the next draft version.

                                                               Ron

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 24 Nov 2014 15:28:15 -0800

Hi Ron,

Thanks for the comments.
Please find my comments inline.

On Fri, Nov 21, 2014 at 1:44 PM, Ronald Bonica <[email-masked]> wrote:

>  Hi Sam,
>
>
>
> Response inline……
>
>
>
> *From:* Sam Aldrin [mailto:[email-masked]]
> *Sent:* Wednesday, November 19, 2014 10:28 PM
> *To:* Ronald Bonica
> *Cc:* [email-masked]
> *Subject:* Re: [mpls] draft-bonica-mpls-self-ping: Response to comments
> from the mike
>
>
>
> Hi Ron,
>
>
>
> Still trying to understand the need for the draft, hence, have few of
> questions and need clarifications. Appreciate your response in advance.
>
>
>
> 1.      (clarification q) The Ingress LSR sends the Echo request, with
> destination IP address to self, and forwards to Egress LSR (sec 2), correct?
>
> *[RPB] * Almost. The Ingress LSR sends the Echo **Reply**, with
> destination IP address to self, and forwards to Egress LSR.
>
%sam - Ah uh! Now I know why it(draft) is confusing. While when I read your
response, it says 'Echo Reply', where as draft-bonica says, 'MPLS Echo
Message'.
I believe you are actually forming 'MPLS Echo Reply' and NOT 'MPLS Echo
Request'.
In sec 2.
o Format a MPLS Echo [RFC4379] message

o  Send the MPLS Echo message through the LSP under test.

This is what is confusing. As you are referring to RFC4379, either use
MPLS Echo Request/Reply, to avoid confusion.

I understand you are just using the packet format, but there is no
definition of MPLS Echo message.

> *[RPB] The egress LSR doesn’t need to identify the ingress LSR. It just
> forwards an IP packet based upon IP destination. The Ingress LSR identifies
> the Echo Reply as one that it sent to itself by matching the Sender Handle
> in the message with an LSP Ping Session ID. *
>
>
>
> 3.      What happens if there is LSP breakage or something and the Echo
> request ends up on transit LSR? Doesn't it process?
>
> *[RPB] The transit LSR forwards the Echo Reply back to the ingress. The
> ingress declares the LSP to be ready to carry traffic, even though it is
> broken. That’s why my original message says, **“*Self Ping is designed to
> verify LSP readiness without consuming control plane resources on the
> egress router. It is not designed to diagnose programming errors in which
> an LSR other than the egress de-encapsulates and forwards the packet.
> Mechanisms that diagnose such issues are available [RFC 4950]. However,
> they are more resource intensive.”
>
>
>
> *[RPB] The draft says that it avoids control plane processing on the
> egress router. The egress router never looks beyond the IP header. It
> simply forwards based upon IP destination.*
>
>
>
> The packet is forwarded from ingress to egress, which means, the egress
> will have to process the packet i.e. look up the ip address to send it back
> to ingress.
>
> *[RPB] Yes. This happens on the forwarding plane.*
>
%sam - Could be or could punt to RP if the forwarding entry is not on the
LC.

>  4.      Is the assertion that, if Echo Reply is received back at the
> ingress then it is failure, rather it should receive Echo Request back at
> Ingress, correct?
>
> *[RPB] Exactly the opposite! If the Echo reply is received at the ingress,
> that is success*
>
%sam - In the above answer, the echo reply could also be looped back from a
transit, not necessarily egress. How you define success in that case?

> *[RPB] The procedures described in Section 3.2.1 of *draft-ietf-mpls-proxy-lsp-ping consume control plane resources on the egress LSR.
>
> %sam - Have you done any quantitative study with existing LSP ping (w/o
FEC validation) or BFD? Trying to understand how much improvement this new
mechanism is bringing.

%sam - In addition, what if the egress lsr for the lsp is not in the same
domain and may not have routable address? In otherwords, Echo reply is not
received and timesout, but the RESV message is already received back at
ingress.

cheers
-sam

> 2) Self-ping does not diagnose FIB programming errors in which an LSR
> other than the egress de-encapsulates and forwards the packet.
> session emits one or two packets and terminates less than one second after
> initiation. Self-ping requires no configuration or control plane resources
> on the egress LSR.
>
> 2) Self-ping does not diagnose programming errors in which an LSR other
> than the egress de-encapsulates and forwards the packet.
>
> Self Ping is designed to verify LSP readiness without consuming control
> plane resources on the egress router. It is not designed to diagnose
> programming errors in which an LSR other than the egress de-encapsulates
> and forwards the packet. Mechanisms that diagnose such issues are available
> [RFC 4950]. However, they are more resource intensive.
>
> In order to verify bidirectional LSP readiness, RSVP instantiates two LSP
> Self Ping sessions, one at each end of the LSP. The LSR at one end of the
> LSP initiates a self ping session when it receives a RESV message. The LSR
> at the other end of the LSP initiates a Self Ping Session when it sends a
> RESV message. Each LSP endpoint forwards traffic over the LSP only after
> the LSP Self Ping session terminates successfully
>
> LSP Self Ping could have used many packet formats. The only hard
> requirement was to have one 64-bit field in which the 64 bit session
> identifier could be encoded. The MPLS Echo packet was convenient because
> its Senders Handle is 64-bits long.
>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 25 Nov 2014 01:52:02 +0000

Sounds good Ron, look forward to seeing the next revision.

Thanks!

-Nobo

From: Ronald Bonica [mailto:[email-masked]]
Sent: Monday, November 24, 2014 5:03 PM
To: Nobo Akiya (nobo); Shah, Himanshu; Thomas D. Nadeau; Sam Aldrin
Cc: [email-masked]
Subject: RE: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi Nobo,

Inline……

Hi,

                                                               Ron

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 25 Nov 2014 02:42:45 +0000

Hi, Ron, Sam,

Joining the discussion late. I did want to point out a couple of additional considerations, I believe these have not been mentioned yet, apologies if they have:

  1.  If the packet is an MPLS Echo Request, from S4.3 of RFC4379, “The Router Alert option MUST be set in the IP header.” In that case, the egress will do some processing, punt to a slower path, examine more closely, follow RFC4379’s procedures, might not like the pak.
  2.  If the packet is an MPLS Echo Reply, it cannot be sent, because from S4.5 of RFC4379 “It MUST ONLY be sent in response to an MPLS echo request.”
  3.  In both #1 and #2, there are some potential issues with following the RFC4379 processing. However,
  4.  There is nothing preventing you from defining a new Message Type of “MPLS echo self-ping” in some friendly range, and specifying the procedures. The caveats of not detecting an LSP broken mid-way that puts the IP packet on the data plane and others still apply to this (unless there is some control plane processing on the LSP egress, which defeats the purpose.

Thanks,

Carlos.

From: Sam Aldrin <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 24, 2014 at 6:28 PM
To: Ronald Bonica <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi Ron,

Thanks for the comments.

On Fri, Nov 21, 2014 at 1:44 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sam,

Response inline……

From: Sam Aldrin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 19, 2014 10:28 PM
To: Ronald Bonica
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Hi Ron,

1.      (clarification q) The Ingress LSR sends the Echo request, with destination IP address to self, and forwards to Egress LSR (sec 2), correct?
[RPB]  Almost. The Ingress LSR sends the Echo *Reply*, with destination IP address to self, and forwards to Egress LSR.
%sam - Ah uh! Now I know why it(draft) is confusing. While when I read your response, it says 'Echo Reply', where as draft-bonica says, 'MPLS Echo Message'.
I believe you are actually forming 'MPLS Echo Reply' and NOT 'MPLS Echo Request'.
In sec 2.
o Format a MPLS Echo [RFC4379] message

This is what is confusing. As you are referring to RFC4379, either use MPLS Echo Request/Reply, to avoid confusion.

I understand you are just using the packet format, but there is no definition of MPLS Echo message.

2.        Is this the only thing which identifies the Ingress LSR or something else too?
[RPB] The egress LSR doesn’t need to identify the ingress LSR. It just forwards an IP packet based upon IP destination. The Ingress LSR identifies the Echo Reply as one that it sent to itself by matching the Sender Handle in the message with an LSP Ping Session ID.

3.      What happens if there is LSP breakage or something and the Echo request ends up on transit LSR? Doesn't it process?
[RPB] The transit LSR forwards the Echo Reply back to the ingress. The ingress declares the LSP to be ready to carry traffic, even though it is broken. That’s why my original message says, “Self Ping is designed to verify LSP readiness without consuming control plane resources on the egress router. It is not designed to diagnose programming errors in which an LSR other than the egress de-encapsulates and forwards the packet. Mechanisms that diagnose such issues are available [RFC 4950]. However, they are more resource intensive.”

The packet is forwarded from ingress to egress, which means, the egress will have to process the packet i.e. look up the ip address to send it back to ingress.
[RPB] Yes. This happens on the forwarding plane.
%sam - Could be or could punt to RP if the forwarding entry is not on the LC.

4.      Is the assertion that, if Echo Reply is received back at the ingress then it is failure, rather it should receive Echo Request back at Ingress, correct?
[RPB] Exactly the opposite! If the Echo reply is received at the ingress, that is success
%sam - In the above answer, the echo reply could also be looped back from a transit, not necessarily egress. How you define success in that case?

%sam - Have you done any quantitative study with existing LSP ping (w/o FEC validation) or BFD? Trying to understand how much improvement this new mechanism is bringing.

%sam - In addition, what if the egress lsr for the lsp is not in the same domain and may not have routable address? In otherwords, Echo reply is not received and timesout, but the RESV message is already received back at ingress.

cheers
-sam

                                ROn

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 25 Nov 2014 00:41:23 -0800

Hi Carlos,

Comments inline.
> On Nov 24, 2014, at 6:42 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
> Hi, Ron, Sam,
> 
> If the packet is an MPLS Echo Request, from S4.3 of RFC4379, “The Router Alert option MUST be set in the IP header.” In that case, the egress will do some processing, punt to a slower path, examine more closely, follow RFC4379’s procedures, might not like the pak.
Yes, this is what I was eluding to when I sent my first email. But after re-reading and Ron's reply, MPLS Echo request format type packet is never sent. Instead  always an MPLS Echo Reply format type packet, which gets sent, which means, IP options are not set

Rest of the comments were mentioned in other emails as well.

-sam
> If the packet is an MPLS Echo Reply, it cannot be sent, because from S4.5 of RFC4379 “It MUST ONLY be sent in response to an MPLS echo request.”
> In both #1 and #2, there are some potential issues with following the RFC4379 processing. However,
> There is nothing preventing you from defining a new Message Type of “MPLS echo self-ping” in some friendly range, and specifying the procedures. The caveats of not detecting an LSP broken mid-way that puts the IP packet on the data plane and others still apply to this (unless there is some control plane processing on the LSP egress, which defeats the purpose.
> Thanks,
> 
> Carlos.
> 
> From: Sam Aldrin <[email-masked] <mailto:[email-masked]>>
> To: Ronald Bonica <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Fri, Nov 21, 2014 at 1:44 PM, Ronald Bonica <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Sam,
>>  
>> Response inline……
>>  
>> From: Sam Aldrin [mailto:[email-masked] <mailto:[email-masked]>] 
>> Cc: [email-masked] <mailto:[email-masked]>

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 25 Nov 2014 00:48:50 -0800

Ron,

I do not think the reason specifying it as LSP ping is correct. 
Although you are using LSP ping Echo reply like packet format, it is not LSP ping packet as it doesn't confirm to RFC4379.
For ex: MPLS Echo Reply is only sent when MPLS Echo Request is received. Neither does it detect any dataplane failures, which is the title of the RFC. 

Hence, I am not convinced that this ID warrants informational RFC, which is based on RFC4379.

But if you want to keep the ID out side the perview of RFC4379, then it should be updated accordingly and discussion should be on those lines.

cheers
-sam
> On Nov 21, 2014, at 2:19 PM, Ronald Bonica <[email-masked]> wrote:
> 
> Shah,
>  
> From: Nobo Akiya (nobo) [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked] <mailto:[email-masked]>
> Thanks for not shooting me Sam but I’m really not the messenger J
>  
> Cc: Nobo Akiya (nobo); Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked] <mailto:[email-masked]>
> On Nov 20, 2014, at 11:15 AM, Shahram Davari <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> 
> From: mpls [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Nobo Akiya (nobo)

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 25 Nov 2014 23:28:05 +0000

Sam and Carlos,

You are correct in that LSP Self-ping has very little to do with LSP Ping [RFC 4379]. In fact, aside from borrowing the message format, it has *nothing* to do with RFC 4379]!

Rationale follows:

-          LSP Self-ping messages do not carry the router alert message

-          Transit and egress LSRs don’t examine or process LSP Ping messages; they simply forward them

-          Only the ingress LSR listens for LSP Self Ping messages

-          The ingress LSR listens for LSP Self Ping messages on a different port than it listens for LSP Ping messages

-          The ingess LSR never responds to an LSP Self Ping message.

I will make this explicit in the next version of the draft.

Sam,

You raise another point that Loa also raised in his chairs review. RFC 4379 does not specify Echo Request and Echo Reply messages. It specifies a single Echo message with a Message Type field (request or reply). In draft-bonica-mpls-self-ping, I retain that terminology. However, Loa suggests that I refer to an Echo Reply message for clarity. I tend to agree with Loa. What do you think?

                                                                                                                                                 Ron

From: Sam Aldrin [mailto:[email-masked]]
Sent: Tuesday, November 25, 2014 3:49 AM
To: Ronald Bonica
Cc: Shah, Himanshu; Nobo Akiya (nobo); Shahram Davari; Thomas Nadeau; [email-masked]
Subject: Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

Ron,

cheers
-sam
On Nov 21, 2014, at 2:19 PM, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Shah,

                                   Ron

Thanks,
himanshu

Thanks!

-Nobo

Hi Nobo,

-sam

Hi,

Thanks
Shahram

Hi,

Thanks!

-Nobo

/himanshu

            —Tom

Hi Ron,

cheers
-sam

Folks

1) Why not use BFD?

Responses follow:

1) Why not use BFD?

Ron Bonica

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 25 Nov 2014 15:56:10 -0800

Hi Ron,

Thanks for the reply.

[sorry for the top post]

Glad that we are on the same page.
Now that we are clear that this ID is not related to RFC4379 but borrows
the model and format of packet structure, etc, I do not have a problem as
such, provided the draft text is worded that way.
Not just for the reasoning purposes, but adds clarity to what you intend to
do and not confuse readers with LSP ping.
W.r.t. Request / Reply, I prefer to have new terms defined and identify
them in the terminology section. For ex: 'Self Ping Message' or something
else.

RFC4379 may not define different message formats for Echo Request and Echo
Reply, it clearly identifies those message types.

cheers
-sam

On Tue, Nov 25, 2014 at 3:28 PM, Ronald Bonica <[email-masked]> wrote:

>  Sam and Carlos,
>
>
>
> You are correct in that LSP Self-ping has very little to do with LSP Ping
> [RFC 4379]. In fact, aside from borrowing the message format, it has *
> *nothing** to do with RFC 4379]!
>
>
>
> Rationale follows:
>
>
>
> -          The ingress LSR listens for LSP Self Ping messages on a
> different port than it listens for LSP Ping messages
>
> You raise another point that Loa also raised in his chairs review. RFC
> 4379 does not specify Echo Request and Echo Reply messages. It specifies a
> single Echo message with a Message Type field (request or reply). In
> draft-bonica-mpls-self-ping, I retain that terminology. However, Loa
> suggests that I refer to an Echo Reply message for clarity. I tend to agree
> with Loa. What do you think?
>
>
>
>
> Ron
>
>
>
> *Sent:* Tuesday, November 25, 2014 3:49 AM
> *To:* Ronald Bonica
> *Cc:* Shah, Himanshu; Nobo Akiya (nobo); Shahram Davari; Thomas Nadeau;
> [email-masked]
>
> Although you are using LSP ping Echo reply like packet format, it is not
> LSP ping packet as it doesn't confirm to RFC4379.
>
> For ex: MPLS Echo Reply is only sent when MPLS Echo Request is received.
> Neither does it detect any dataplane failures, which is the title of the
> RFC.
>
>
>
> But if you want to keep the ID out side the perview of RFC4379, then it
> should be updated accordingly and discussion should be on those lines.
>
>
>
> cheers
>
> -sam
>
> Because there are no interoperability implications, there is no need for a
> standards track RFC. However, because LSP Ping sends traffic off-box, an
> INFORMATIONAL RFC is appropriate. LSP Ping traffic might be detected by
> counters, intrusion detection devices and firewalls. We should document all
> of the OAM traffic that we generate.
>
>
>
>                                    Ron
>
>
>
>
>
> *From:* Shah, Himanshu [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, November 20, 2014 7:05 PM
> *To:* Nobo Akiya (nobo); Sam Aldrin; Shahram Davari
> *Cc:* Thomas Nadeau; Ronald Bonica; [email-masked]
> *Subject:* RE: [mpls] draft-bonica-mpls-self-ping: Response to comments
> from the mike
>
>
>
> *Understand documenting helpful techniques (more useful during
> restoration/re-optimization cases) as informational RFC, but I believe IETF
> usually*
>
> *entertains proposals which has interoperability implications, AFAIK.*
>
>
>
> *Which is what others are saying as well…*
>
>
>
> *Thanks,*
>
> *himanshu*
>
>
>
> *From:* Nobo Akiya (nobo) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, November 20, 2014 6:23 PM
> *To:* Sam Aldrin; Shahram Davari
> *Cc:* Shah, Himanshu; Thomas Nadeau; Ronald Bonica; [email-masked]
> *Subject:* RE: [mpls] draft-bonica-mpls-self-ping: Response to comments
> from the mike
>
>
>
> If there is a good proposal that covers set of LSP types with [virtually]
> no imitations, then documenting such proposal has an value, IMHO.
>
>
>
> I’d agree that current contents of this document may not provide
> sufficient value to be pursued as an informational document, but I’m not
> hopeless that something could come out of this.
>
>
>
> Thanks!
>
>
>
> -Nobo
>
>
>
> *From:* Sam Aldrin [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, November 20, 2014 2:57 PM
> *To:* Shahram Davari
> *Cc:* Nobo Akiya (nobo); Shah, Himanshu; Thomas Nadeau; Ronald Bonica;
> [email-masked]
> In addition to what you listed, would like to see details on how  this ID
> will improve the performance at Egress should be clarified.
>
> i.e. IP routing Vs OAM process (w/o FEC validation). Also, how this model
> helps if reverse IP path is not available (inter-domain, reverse path
> broken, non-routable ingress IP address) and to what gain?
>
>
>
> Since the procedures in this draft generates and processes the test
> packets on the same router and since other routers just forward normally,
>  why do we even need a draft? There is no interoperability requirements,
> and each vendor can implement what they like.
>
>
>
> Thanks
>
> Shahram
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Nobo Akiya (nobo)
> *Sent:* Thursday, November 20, 2014 10:57 AM
> *To:* Shah, Himanshu; Thomas D. Nadeau; Sam Aldrin
> *Cc:* Ronald Bonica; [email-masked]
> 2.       Ron needs a mechanism that is more efficient on egress LSRs,
> with respect to resources and operational aspects.
>
> 3.       Any probe packet having destination IP address as the ingress
> LSR has limitations in terms of how effective it can verify the DP
> readiness.
>
> 4.       The proposal by Ron is limited to those LSPs that signal via
> ordered mode (ex: LDP independent mode will not work) - same problem as (3).
>
>
>
> If the intent of draft-bonica-mpls-self-ping is just to document what has
> been implemented or what is being implemented, I’d like to request
> followings to be captured in the document.
>
> -          usage of non-127/8 address as destination IP address in MPLS
> echo request/reply deviates from RFC4379.
>
>
>
> If the intent of draft-bonica-mpls-self-ping is to advocate a mechanism
> for efficient MPLS DP readiness test, and I’d like to request that:
>
> -          S-BFD be evaluated (as it addresses the efficiency
> requirements and does not have limitations described by 3 and 4).
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Shah, Himanshu
> *Sent:* Thursday, November 20, 2014 10:36 AM
> *To:* Thomas D. Nadeau; Sam Aldrin
> *Cc:* Ronald Bonica; [email-masked]
> *This is exactly what I said at Mic.*
>
> *We have been deploying MPLS for a while and if such DP active
> verification was necessary, vendors have solved it without*
>
> *standard specific solution, may that be BFD or self-ping.*
>
>
>
> *One of the argument made was that client BFD session detects that “tunnel
> is active but DP is not”.*
>
> *Does it imply there is some kind of UNI signaling going on between PE and
> CE to indicate that tunnel has become*
>
> *active, commence data? And the idea is that PE will refrain notification
> until self-ping verify DP active?*
>
>
>
> *If that is not the case then this technique is not even useful – self
> ping is not actually causing the DP to become active,*
>
> *If it doesn’t become active in the time window, what is PE going to do?*
>
>
>
> [NOBO] That is another interesting aspect of the whole solution. However,
> I believe that the problem scope of this document is much smaller: ingress
> LSR to detect readiness of RSVP signaled LSP. For RSVP signaled LSP, only
> the LSP that is “passing the test” can be tied to the tunnel as the active
> LSP, so at least the ingress LSR will not pump traffic into the tunnel
> without knowing whether DP end-to-end is ready or not. Assuming that there
> are other ways to get to the egress LSR from this ingress LSR, then the
> problem is solved. Otherwise the ingress LSR will drop the traffic but the
> problem is contained to that network node (i.e. packets are not traversing
> un-ready LSP).
>
>
>
> Thanks!
>
>
>
> -Nobo
>
>
>
>
>
> */himanshu*
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Thomas D. Nadeau
> *Sent:* Thursday, November 20, 2014 9:43 AM
> *To:* Sam Aldrin
> *Cc:* Ronald Bonica; [email-masked]
>             To me what is described in the draft seems like this is a
> description of a device/vendor feature that automates the basic procedures
> of 4379/etc.. This can and has been done for quite some time using other
> means such as onboard automated scripts/actions after paths are
> established/signaled. I say this not to be glib, but because I built such a
> thing about 10 years ago that has been deployed widely.  Also, as Sam says,
> there is some deviation from RFC4379 which we should ask is worth the
> additional complication (and required implementation + associated
> delay/etc...) versus just using the existing means.
>
>
>
>             The bottom line is that we should be asking ourselves whether
> or not this something we really need to standardize.
>
>
>
>             —Tom
>
>
>
>
>
>
>
> destination IP address to self, and forwards to Egress LSR (sec 2),
> correct?  Is this the only thing which identifies the Ingress LSR or
> something else too?
>
> 2. What happens if there is LSP breakage or something and the Echo request
> ends up on transit LSR? Doesn't it process? I see that draft says, this
> will avoid control plane processing. How so? The packet is forwarded from
> ingress to egress, which means, the egress will have to process the packet
> i.e. look up the ip address to send it back to ingress.
>
>
>
>   3. Is the assertion that, if Echo Reply is received back at the ingress
> then it is failure, rather it should receive Echo Request back at Ingress,
> correct?
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 26 Nov 2014 11:00:48 +0800

Folks,

I did a chair-review that I sent to the authors. In that review (the
rest is pretty much editorial) I clearly miss the the "non-relationship" 
with 4379.

I think what I see from the discussion between Sam and Ron are
that we want to:

- borrow the message format from 4379
- create a new message typ
- I with Sam that that message type should be named to avoid being
   confused with MPLS Echo Request and MPLS Echo Reply
- whether we'd like to register this message type in the "Message
   Type" registry in "Multi-  Protocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" is an open question.
- but since the new message type will come out of the "Standards
   Action" registry the document needs to be Standards Track.

/Loa

On 2014-11-26 07:56, Sam Aldrin wrote:
> the model and format of packet structure, etc, I do not have a problem
> as such, provided the draft text is worded that way.
> Not just for the reasoning purposes, but adds clarity to what you intend
> to do and not confuse readers with LSP ping.
> them in the terminology section. For ex: 'Self Ping Message' or
> something else.
>
> RFC4379 may not define different message formats for Echo Request and
> Echo Reply, it clearly identifies those message types.
>
> cheers
> -sam
>
>
> On Tue, Nov 25, 2014 at 3:28 PM, Ronald Bonica <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Sam and Carlos,____
>
>     __ __
>
>     You are correct in that LSP Self-ping has very little to do with LSP
>     Ping [RFC 4379]. In fact, aside from borrowing the message format,
>     it has **nothing** to do with RFC 4379]! ____
>
>     __ __
>
>     Rationale follows:____
>
>     __ __
>
>     __-__LSP Self-ping messages do not carry the router alert message____
>
>     __-__Transit and egress LSRs don’t examine or process LSP Ping
>     messages; they simply forward them____
>
>     __-__Only the ingress LSR listens for LSP Self Ping messages____
>
>     __-__The ingress LSR listens for LSP Self Ping messages on a
>     different port than it listens for LSP Ping messages____
>
>     __-__The ingess LSR never responds to an LSP Self Ping message.____
>
>     __ __
>
>     I will make this explicit in the next version of the draft.____
>
>     __ __
>
>     Sam,____
>
>     __ __
>
>     You raise another point that Loa also raised in his chairs review.
>     RFC 4379 does not specify Echo Request and Echo Reply messages. It
>     specifies a single Echo message with a Message Type field (request
>     or reply). In draft-bonica-mpls-self-ping, I retain that
>     terminology. However, Loa suggests that I refer to an Echo Reply
>     message for clarity. I tend to agree with Loa. What do you think?____
>
>     __ __
>
>                                                                                                                                                       Ron____
>
>     ____
>
>     __ __
>
>     *From:*Sam Aldrin [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Shah, Himanshu; Nobo Akiya (nobo); Shahram Davari; Thomas
>     Nadeau; [email-masked] <mailto:[email-masked]>
>
>
>     *Subject:* Re: [mpls] draft-bonica-mpls-self-ping: Response to
>     comments from the mike____
>
>     __ __
>
>     Ron,____
>
>     __ __
>
>     I do not think the reason specifying it as LSP ping is correct. ____
>
>     Although you are using LSP ping Echo reply like packet format, it is
>     not LSP ping packet as it doesn't confirm to RFC4379.____
>
>     For ex: MPLS Echo Reply is only sent when MPLS Echo Request is
>     received. Neither does it detect any dataplane failures, which is
>     the title of the RFC. ____
>
>     __ __
>
>     Hence, I am not convinced that this ID warrants informational RFC,
>     which is based on RFC4379.____
>
>     __ __
>
>     But if you want to keep the ID out side the perview of RFC4379, then
>     it should be updated accordingly and discussion should be on those
>     lines.____
>
>     __ __
>
>     cheers____
>
>     -sam____
>
>         On Nov 21, 2014, at 2:19 PM, Ronald Bonica <[email-masked]
>         <mailto:[email-masked]>> wrote:____
>
>         __ __
>
>         Shah,____
>
>         ____
>
>         Because there are no interoperability implications, there is no
>         need for a standards track RFC. However, because LSP Ping sends
>         traffic off-box, an INFORMATIONAL RFC is appropriate. LSP Ping
>         traffic might be detected by counters, intrusion detection
>         devices and firewalls. We should document all of the OAM traffic
>         that we generate.____
>
>         ____
>
>                                             Ron____
>
>         ____
>
>         ____
>
>         *From:*Shah, Himanshu [mailto:[email-masked]]
>         *Sent:*Thursday, November 20, 2014 7:05 PM
>         *To:*Nobo Akiya (nobo); Sam Aldrin; Shahram Davari
>         *Cc:*Thomas Nadeau; Ronald Bonica; [email-masked]
>         <mailto:[email-masked]>
>         *Subject:*RE: [mpls] draft-bonica-mpls-self-ping: Response to
>         comments from the mike____
>
>         ____
>
>         /Understand documenting helpful techniques (more useful during
>         restoration/re-optimization cases) as informational RFC, but I
>         believe IETF usually/____
>
>         /entertains proposals which has interoperability implications,
>         AFAIK./____
>
>         //____
>
>         /Which is what others are saying as well…/____
>
>         //____
>
>         /Thanks,/____
>
>         /himanshu/____
>
>         //____
>
>         *From:*Nobo Akiya (nobo) [mailto:[email-masked]]
>         *Sent:*Thursday, November 20, 2014 6:23 PM
>         *To:*Sam Aldrin; Shahram Davari
>         *Cc:*Shah, Himanshu; Thomas Nadeau; Ronald Bonica;[email-masked]
>         <mailto:[email-masked]>
>         *Subject:*RE: [mpls] draft-bonica-mpls-self-ping: Response to
>         comments from the mike____
>
>         ____
>
>         Thanks for not shooting me Sam but I’m really not the messengerJ____
>
>         ____
>
>         If there is a good proposal that covers set of LSP types with
>         [virtually] no imitations, then documenting such proposal has an
>         value, IMHO.____
>
>         ____
>
>         sufficient value to be pursued as an informational document, but
>         I’m not hopeless that something could come out of this.____
>
>         ____
>
>         Thanks!____
>
>         ____
>
>         -Nobo____
>
>         ____
>
>         *From:*Sam Aldrin [mailto:[email-masked]]
>         *Sent:*Thursday, November 20, 2014 2:57 PM
>         *To:*Shahram Davari
>         *Cc:*Nobo Akiya (nobo); Shah, Himanshu; Thomas Nadeau; Ronald
>         Bonica;[email-masked] <mailto:[email-masked]>
>         *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response to
>         comments from the mike____
>
>         ____
>
>         Hi Nobo,____
>
>         ____
>
>         [without shooting the messenger]____
>
>         ____
>
>         In addition to what you listed, would like to see details on how
>           this ID will improve the performance at Egress should be
>         clarified.____
>
>         i.e. IP routing Vs OAM process (w/o FEC validation). Also, how
>         this model helps if reverse IP path is not available
>         (inter-domain, reverse path broken, non-routable ingress IP
>         address) and to what gain?____
>
>         ____
>
>         There are many ways the LSP ping is being used, both as
>         proprietary and also part of eco system.____
>
>         If we go by the logic that this ID is needed, we will have slew
>         of new ID’s detailing different usage models.____
>
>         ____
>
>         Hence, I totally agree with what Shahram and others have
>         indicated.____
>
>         ____
>
>         -sam____
>
>         ____
>
>             On Nov 20, 2014, at 11:15 AM, Shahram Davari
>             <[email-masked] <mailto:[email-masked]>> wrote:____
>
>             ____
>
>             Hi,____
>
>
>             Since the procedures in this draft generates and processes
>             the test packets on the same router and since other routers
>             just forward normally,  why do we even need a draft? There
>             is no interoperability requirements, and each vendor can
>             implement what they like.____
>
>             ____
>
>             Thanks____
>
>             Shahram____
>
>             ____
>
>             *From:*mpls [mailto:[email-masked]]*On Behalf Of*Nobo
>             Akiya (nobo)
>             *Sent:*Thursday, November 20, 2014 10:57 AM
>             *To:*Shah, Himanshu; Thomas D. Nadeau; Sam Aldrin
>             *Cc:*Ronald Bonica;[email-masked] <mailto:[email-masked]>
>             *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response
>             to comments from the mike____
>
>             ____
>
>             Hi,____
>
>             ____
>
>             Sort of summarizing what’s been stated but here’s my
>             observation of draft-bonica-mpls-self-ping.____
>
>             ____
>
>             1.LSP Ping and BFD MPLS already do what is being proposed.____
>
>             2.Ron needs a mechanism that is more efficient on egress
>             LSRs, with respect to resources and operational aspects.____
>
>             3.Any probe packet having destination IP address as the
>             ingress LSR has limitations in terms of how effective it can
>             verify the DP readiness.____
>
>             4.The proposal by Ron is limited to those LSPs that signal
>             via ordered mode (ex: LDP independent mode will not work) -
>             same problem as (3).____
>
>             ____
>
>             If the intent of draft-bonica-mpls-self-ping is just to
>             document what has been implemented or what is being
>             implemented, I’d like to request followings to be captured
>             in the document.____
>
>             -limitations (3 and 4) so that readers are aware of them.____
>
>             -usage of non-127/8 address as destination IP address in
>             MPLS echo request/reply deviates from RFC4379.____
>
>             ____
>
>             If the intent of draft-bonica-mpls-self-ping is to advocate
>             a mechanism for efficient MPLS DP readiness test, and I’d
>             like to request that:____
>
>             -requirements (2) are well captured.____
>
>             -S-BFD be evaluated (as it addresses the efficiency
>             requirements and does not have limitations described by 3
>             and 4).____
>
>             ____
>
>             Himanshu, I have one comment in-line below. Please look for
>             [NOBO].____
>
>             ____
>
>             ____
>
>             *From:*mpls [mailto:[email-masked]]*On Behalf
>             Of*Shah, Himanshu
>             *Sent:*Thursday, November 20, 2014 10:36 AM
>             *To:*Thomas D. Nadeau; Sam Aldrin
>             *Cc:*Ronald Bonica;[email-masked] <mailto:[email-masked]>
>             *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response
>             to comments from the mike____
>
>             ____
>
>             /This is exactly what I said at Mic./____
>
>             /We have been deploying MPLS for a while and if such DP
>             active verification was necessary, vendors have solved it
>             without/____
>
>             /standard specific solution, may that be BFD or self-ping./____
>
>             //____
>
>             /One of the argument made was that client BFD session
>             detects that “tunnel is active but DP is not”./____
>
>             /Does it imply there is some kind of UNI signaling going on
>             between PE and CE to indicate that tunnel has become/____
>
>             /active, commence data? And the idea is that PE will refrain
>             notification until self-ping verify DP active?/____
>
>             //____
>
>             /If that is not the case then this technique is not even
>             useful – self ping is not actually causing the DP to become
>             active,/____
>
>             /If it doesn’t become active in the time window, what is PE
>             going to do?/____
>
>             //____
>
>             [NOBO] That is another interesting aspect of the whole
>             solution. However, I believe that the problem scope of this
>             document is much smaller: ingress LSR to detect readiness of
>             RSVP signaled LSP. For RSVP signaled LSP, only the LSP that
>             is “passing the test” can be tied to the tunnel as the
>             active LSP, so at least the ingress LSR will not pump
>             traffic into the tunnel without knowing whether DP
>             end-to-end is ready or not. Assuming that there are other
>             ways to get to the egress LSR from this ingress LSR, then
>             the problem is solved. Otherwise the ingress LSR will drop
>             the traffic but the problem is contained to that network
>             node (i.e. packets are not traversing un-ready LSP).____
>
>             ____
>
>             Thanks!____
>
>             ____
>
>             -Nobo____
>
>             ____
>
>             ____
>
>             //himanshu/____
>
>             //____
>
>             *From:*mpls [mailto:[email-masked]]*On Behalf
>             Of*Thomas D. Nadeau
>             *Sent:*Thursday, November 20, 2014 9:43 AM
>             *To:*Sam Aldrin
>             *Cc:*Ronald Bonica;[email-masked] <mailto:[email-masked]>
>             *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response
>             to comments from the mike____
>
>             ____
>
>             ____
>
>             description of a device/vendor feature that automates the
>             basic procedures of 4379/etc.. This can and has been done
>             for quite some time using other means such as onboard
>             automated scripts/actions after paths are
>             established/signaled. I say this not to be glib, but because
>             I built such a thing about 10 years ago that has been
>             deployed widely.  Also, as Sam says, there is some deviation
>             from RFC4379 which we should ask is worth the additional
>             complication (and required implementation + associated
>             delay/etc...) versus just using the existing means. ____
>
>             ____
>
>             The bottom line is that we should be asking ourselves
>             whether or not this something we really need to standardize.____
>
>             ____
>
>             —Tom____
>
>             ____
>
>             ____
>
>             ____
>
>                 On Nov 19, 2014:10:28 PM, at 10:28 PM, Sam Aldrin
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:____
>
>                 ____
>
>                 Hi Ron,____
>
>                 ____
>
>                 Still trying to understand the need for the draft,
>                 hence, have few of questions and need clarifications.
>                 Appreciate your response in advance.____
>
>                 ____
>
>                 1. (clarification q) The Ingress LSR sends the Echo
>                 request, with destination IP address to self, and
>                 forwards to Egress LSR (sec 2), correct?  Is this the
>                 only thing which identifies the Ingress LSR or something
>                 else too?____
>
>                 2. What happens if there is LSP breakage or something
>                 and the Echo request ends up on transit LSR? Doesn't it
>                 process? I see that draft says, this will avoid control
>                 plane processing. How so? The packet is forwarded from
>                 ingress to egress, which means, the egress will have to
>                 process the packet i.e. look up the ip address to send
>                 it back to ingress.____
>
>                 ____
>
>                 Draft says "The egress LSR forwards the MPLS Echo
>                 message to its destination, the____
>
>                     ingress LSR.  The egress LSR forwards the MPLS Echo message exactly____
>
>                     as it would forward any other packet."____
>
>                   ____
>
>                 Could you explain, how egress forwards the packet back to ingress w/o looking up the packet IP header i.e. in the data plane and no additional control plane of OAM process?____
>
>                 3. Is the assertion that, if Echo Reply is received back
>                 at the ingress then it is failure, rather it should
>                 receive Echo Request back at Ingress, correct?____
>
>                 4. Why can't you use LSP proxy ping to self via Egress?____
>
>                 ____
>
>                 Will followup with additional questions, if any, based
>                 on your responses.____
>
>                 ____
>
>                 cheers____
>
>                 -sam____
>
>                 ____
>
>                     On Nov 19, 2014, at 8:38 AM, Ronald Bonica
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:____
>
>                     ____
>
>                     Folks
>
>                     2) Self-ping does not diagnose FIB programming
>                     errors in which an LSR other than the egress
>                     de-encapsulates and forwards the packet.
>                     3) How does Self ping verify a bidirectional LSP's
>                     readiness to carry traffic in both directions?
>                     4) Why does MPLS Self ping use MPLS Echo packets, as
>                     opposed to ICMP echo packets or some other packet
>                     format?
>
>                     Responses follow:
>
>                     1) Why not use BFD?
>
>                     Self Ping is an extremely light-weight protocol. A
>                     typical Self Ping session emits one or two packets
>                     and terminates less than one second after
>                     initiation. Self-ping requires no configuration or
>                     control plane resources on the egress LSR.
>
>                     By contrast, BFD is designed to verify
>                     bi-directional connectivity over a longer period of
>                     time. Therefore, MPLS Self Ping is appropriate in
>                     2) Self-ping does not diagnose programming errors in
>                     which an LSR other than the egress de-encapsulates
>                     and forwards the packet.
>
>                     Self Ping is designed to verify LSP readiness
>                     without consuming control plane resources on the
>                     egress router. It is not designed to diagnose
>                     programming errors in which an LSR other than the
>                     egress de-encapsulates and forwards the packet.
>                     Mechanisms that diagnose such issues are available
>                     3) How does Self ping verify a bidirectional LSP's
>                     readiness to carry traffic in both directions?
>
>                     In order to verify bidirectional LSP readiness, RSVP
>                     instantiates two LSP Self Ping sessions, one at each
>                     end of the LSP. The LSR at one end of the LSP
>                     initiates a self ping session when it receives a
>                     RESV message. The LSR at the other end of the LSP
>                     initiates a Self Ping Session when it sends a RESV
>                     message. Each LSP endpoint forwards traffic over the
>                     LSP only after the LSP Self Ping session terminates
>                     successfully
>
>                     LSP Self Ping could have used many packet formats.
>                     The only hard requirement was to have one 64-bit
>                     field in which the 64 bit session identifier could
>                     be encoded. The MPLS Echo packet was convenient
>                     because its Senders Handle is 64-bits long.
>
>                     https://www.ietf.org/mailman/listinfo/mpls____
>
>                 ____
>
>                 https://www.ietf.org/mailman/listinfo/mpls____
>
>     __ __
>
>
>
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64