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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 9 Mar 2015 17:05:28 +0000

Hi,

I was asked to provide an MPLS RT Review of the following document, by March 11th:
https://tools.ietf.org/html/draft-bonica-mpls-self-ping-04 <https://tools.ietf.org/html/draft-bonica-mpls-self-ping-04>

I have read the document, and I appreciate the problem it is attempting to solve. LSP data-plane verification without consuming egress control-plane resources.

The document is well written, and the Self-ping concept well described.

I do have a number of (both minor and major) concerns with the approach as described, however:

Intended status: Informational

Abstract

   LSP Self-ping is a new, light-weight protocol that ingress LSRs can
   use to verify an LSPs readiness to carry traffic.

This document is effectively defining a new protocol, which effectively updates RFC-2119 level procedures in STD RFC 4379 (details below), but it does not say so.

   The ingress LSR forwards the probe through the LSP under test.  If
   the LSP is ready to forward traffic, the egress LSR receives the
   probe.  Because the probe is addressed to the ingress LSR, the egress
   LSR forwards the probe back to the ingress.  When the ingress LSR
   receives the probe, it has verified LSP readiness without consuming
   control plane resources at the egress LSR.

There are a few potential issues with this overall approach:
These procedures assume that an LSP is either sane, or broken such that the probes will get lost. However, a real-world problem is the one in which an LSP is broken mid-stream such that the labels are popped and the packet is “released”. These probes will find their way to the source, telling that the LSP is OK, but in fact the LSP is broken mid-stream, and real traffic will be blackholes.
Similarly, if an LSP is misprogrammed in forwarding such that it is switched to a different label, this will not be detected.
The way in which the packet is constructed might not pass uRPF check.

#1 and #2 seem to somewhat defeat the purpose, because of these two false positives. #3 is a false negative.

As a thought — has S-BFD been considered such that it can detect mis-connection with minimal egress resource use? Those probes seem a bit better than LSP Ping ones.

   example, LSP Self-ping cannot detect a misrouted LSP.  Furthermore,
   LSP Self-ping cannot be used to verify LSPs that were signaled using
   LDP independent mode.

Should a more generic approach be preferred, applicable to any LSP?

   The ingress LSR executes the following procedure until verification-
   status equals TRUE or retries is less than 1:

   o  Format a MPLS Echo Reply [RFC4379] message

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

This seems to be forbidden as per RFC 4379, which says:
https://tools.ietf.org/html/rfc4379#section-4.5 <https://tools.ietf.org/html/rfc4379#section-4.5>
4.5.  Sending an MPLS Echo Reply
   An MPLS echo reply is a UDP packet.  It MUST ONLY be sent in response
   to an MPLS echo request.

   In either case, message contents are as follows:

   o  IP Source Address is configurable.  By default, it is the address
      of the egress LSR

   o  IP Destination Address is the address of the ingress LSR

This construction will fail uRPF.

Also, what about the use of the Router-Alert (option / label)?

   LSP Self-ping fails if all of the following conditions are true:

   o  The Source Address of the MPLS Echo Reply message is equal to its
      default value (that is, the address of the egress LSR)

   o  The penultimate hop pops the MPLS label

   o  The egress LSR executes Unicast Reverse Path Forwarding (uRPF)
      procedures

These conditions are some of which I was referring to above. Do they drastically reduce the usefulness and applicability of this method?

4.  Rejected Approaches

Has S-BFD been considered?

Many thanks in advance for considering these comments.

Best,

— Carlos.