Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

From: Ronald Bonica <[email-masked]>
Date: Tue, 14 Oct 2014 19:36:07 +0000

Folks,

Please review and comment

                         Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2014 3:28 PM
> To: Ronald Bonica; EXT - [email-masked]; Raveendra Torvi;
> Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT -
> [email-masked]; EXT - [email-masked]; Michael Conn;
> Dante Pacella; EXT - [email-masked]
> Subject: New Version Notification for draft-bonica-mpls-self-ping-00.txt
> 
> 
> A new version of I-D, draft-bonica-mpls-self-ping-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:		draft-bonica-mpls-self-ping
> Revision:	00
> Title:		LSP Self-Ping
> Document date:	2014-10-14
> Group:		Individual Submission
> Pages:		7
> URL:            http://www.ietf.org/internet-drafts/draft-bonica-mpls-self-ping-
> 00.txt
> Status:         https://datatracker.ietf.org/doc/draft-bonica-mpls-self-ping/
> Htmlized:       http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00
> 
> 
> Abstract:
>    This memo describes LSP Self-ping.  An ingress LSR can use LSP Self-
>    ping to verify that an LSP is ready to carry traffic.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: "Osborne, Eric" <[email-masked]>
Date: Tue, 14 Oct 2014 20:59:27 +0000

This basically says "send an echo reply to yourself over your own LSP".  Right?  All the procedures in section 2 (the first 8 bullet points) seem like implementation details.

Why do you mandate the CS6 DSCP?  Surely there's room for setting whatever else I want?

How likely is it that the egress LSR will receive a packet with its own source and drop it due to RPF or anti-spoofing?  Strict RPF seems like it would drop the packet, as does feasible; not sure about loose.  If nothing else, any changes to RPF needed to allow this should be covered in the security section.

eric

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 3:36 PM
To: [email-masked]
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Folks,

                         Ron

> [email-masked]; EXT - [email-masked]; Michael 
> Conn; Dante Pacella; EXT - [email-masked]
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

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

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 14 Oct 2014 21:20:07 +0000

Hi Ron,
thank you for bringing this work to discussion. I agree that lightweight mechanism to verify LSP availability is useful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to reference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case<https://tools.ietf.org/html/draft-ietf-bfd-seamless-use-case-00> document believe addresses the problem stated in the Self-ping draft. Perhaps you can review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Validation in particular.

Greatly appreciate your feedback.

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: [email-masked]
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Folks,

                         Ron

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> To: Ronald Bonica; EXT - [email-masked]<mailto:[email-masked]>; Raveendra Torvi;
> [email-masked]<mailto:[email-masked]>; EXT - [email-masked]<mailto:[email-masked]>; Michael
> Conn; Dante Pacella; EXT - [email-masked]<mailto:[email-masked]>

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 14 Oct 2014 21:32:48 +0000

Hi Ron,

I agree with Greg that a light weight mechanism to verify LSP availability is useful, and S-BFD may be a good fit for your needs.

One comment in draft-bonica-mpls-self-ping-00.

[snip from draft-bonica-mpls-self-ping-00, Section 2]
   If the protocol messages used to establish the LSP were delivered
   over IPv4 [RFC0791] the probe message is an ICMPv4 [RFC0792] Echo
   Reply.  If the protocol messages used to establish the LSP were
   delivered over IPv6 [RFC2460] the probe message is an ICMPv6
   [RFC4443] Echo Reply.  In either case, the contents of the ICMP
   message are as follows:

   o  Source Address equals the address of the egress LSR

   o  Destination Address equals the address of the ingress LSR
[snip]

Destination address having a valid IP address (i.e. address of ingress LSR) means that this probe will come back to the ingress LSR when:
- transit LSR false pops and forwards (due to incorrect label programming)
- transit LSR false forwards elsewhere and happens to terminates at some other network nodes via different LSP (due to incorrect label programming)

Certain packets over such LSP (ex: VPN) will likely get dropped even though proposed probe reports success, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.

When applied to the LDP independent mode, proposed probe will have the same "false positive" issue with "end-to-end LSP not ready" case as well.

Thanks!

-Nobo

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Hi Ron,

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Folks,

                         Ron

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Oct 2014 11:36:54 -0400

> I agree with Greg that a light weight mechanism to verify LSP availability is useful, and S-BFD may be a good fit for your needs.

FWIW, this discussion may also be relevant to be cc'd to lime@ietf.  

-- Jeff

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 16 Oct 2014 01:13:18 +0000

Hi Eric,

Thanks for reading the draft. Responses inline.....

> From: Osborne, Eric [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2014 4:59 PM
> This basically says "send an echo reply to yourself over your own LSP".  Right?

[RPB] 
Exactly!

> All the procedures in section 2 (the first 8 bullet points) seem like
> implementation details.

[RPB] 
Some of those implementation details are important. For example, LSP readiness is verified, even if Echo Reply messages don't return in the order that they were sent.

> Why do you mandate the CS6 DSCP?  Surely there's room for setting

[RPB] 
Good point! For example, if your network doesn't support multiple classes of service, there is no reason to set the DSCP bits at all.

In the next version of the draft, I will downgrade this to a recommendation.

> 
> How likely is it that the egress LSR will receive a packet with its own source
> and drop it due to RPF or anti-spoofing?  Strict RPF seems like it would drop
> the packet, as does feasible; not sure about loose.  If nothing else, any
> changes to RPF needed to allow this should be covered in the security
> section.

[RPB] 
[RPB] 
Good catch! In some scenarios, the egress LSR will drop the probe. Examples are:

- the LSP penultimate hop pops and the egress LSR enforces RPF checking
- the LSP does not penultimate hop pop but the egress LSR enforces RPF checking *after* removing the MPLS header

I will mention this in the security considerations section. Operators and/or implementations may have to work around this.

                                                         Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 16 Oct 2014 18:16:29 +0000

Hi Greg,

Thanks for reviewing the document!

One drawback of the approach outlined in draft-ietf-bfd-seamless-use-case is that it requires the egress LSR to implement new BFD procedures. By contrast, LSP Self-ping does not impose any new requirements upon the egress.

                                                        Ron

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Hi Ron,

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Folks,

                         Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 16 Oct 2014 18:44:10 +0000

Hi Nobo,

Thanks for reviewing this document. Comments inline.....

                                             Ron

[RPB]
LSP Self-ping is an extremely lightweight mechanism that verifies the availability of the data plane. It does not verify that the LSP follows the ERO, or even that it terminates on the correct egress LSR.

In the rare cases when the LSP has been programmed incorrectly, it is appropriate to invoke heavier-weight diagnostic tools.

[RPB]
True. LSP Self-ping is not applicable for LDP independent mode.

                                                               Ron

Thanks!

-Nobo

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Hi Ron,

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Folks,

                         Ron

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 17 Oct 2014 01:22:32 +0000

Hi Ron,

Thanks for your response. Please see in-line with [NOBO].

From: Ronald Bonica [mailto:[email-masked]]
Sent: Thursday, October 16, 2014 2:44 PM
To: Nobo Akiya (nobo); Gregory Mirsky; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Hi Nobo,

                                             Ron

[RPB]

[NOBO] "verifies the availability of the data plane" depends on which data plane you are referring to. The proposed verifies the IP data plane from some nodes to self, which some node could the egress LSR. The proposed does not verify the availability of the LSP (i.e. MPLS data plane), which I believe is the verification that the proposal is trying to provide.

In Section 3:

[snip]
   By contrast, LSP Self-ping does not consume any control plane
   resources at the egress LSR, and relies solely on the data plane of
   the egress LSR, making it more suitable as a tool for checking LSP
   readiness when dealing with a large number of LSPs.
[snip]

It might be beneficial to clarify above text that the proposed attempts to check the LSP readiness but has limitations as described previously.

[NOBO]  It is also those "rare cases" that causes some of the biggest issues in networks. If something similar (i.e. light weight and quick) can be done truly in-band to catch even those "rare cases", then I think that will be a good mechanism to [also] pursue.

Thanks!

-Nobo

[RPB]

                                                               Ron

Thanks!

-Nobo

Hi Ron,

        Regards,
                Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt

Folks,

                         Ron