Subject: [mpls] Rtgdir early review of draft-ietf-mpls-bfd-directed-07

From: Carlos Pignataro <[email-masked]>
Date: Tue, 11 Jul 2017 06:59:59 -0700

Reviewer: Carlos Pignataro
Review result: Has Issues

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

The MPLS chairs have requested an early review from the directorate with the
objective of improving document quality.  This document has had three
unsuccessful WG LCs.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-mpls-bfd-directed-07.txt
Reviewer: Carlos Pignataro
Review Date: Early July, 2017
Intended Status: Standards Track

Summary:
I have significant concerns about this document.
I also recommend a BFD WG Chair or appointee to review this document.

Comments:

First, I have a general concern about the architectural approach in this
document.

This document is modeled after RFC 7110. RFC 7110 describes the specification
of a return path for MPLS LSP Ping. MPLS LSP Ping uses a request/reply
command/response paradigm, in which receipt of an Echo Request elicits the
generation of an Echo Reply.

BFD for MPLS, however, uses a different approach and paradigm (as per RFC
5884). An MPLS LSP Ping packet is used as a bootstrap, signaling discriminator
value for a persistent BFD session. After the MPLS LSP Ping signals the
Discriminator (via MPLS LSP Ping TLV) to use, then BFD control messages are
sent back and forth.

However, while the BFD session is UP and  BFD control messages and being sent
back and forth, and while no MPLS LSP Ping packets are sent after bootstrapping
-- what happens if the return path changes (e.g., the return LSP goes down,
gets unconfigured, etc.)?

In that case, not only this mechanism can actually make things worst, because
it results in a false negative, but also the document does not specify how the
system should recover. The I-D seems to assume complete topological
invariability for it to work long-term, since it does not specify any mechanism
to update or to deal with such a failure or change scenario.

On the other hand, there is already a BFD mechanism without the bootstrapping
setup and with a command/response like behavior, that is S-BFD, RFC 7881. That
one is notably missing from this draft.

Further, there seem to be a number of potentially erroneous assumptions made,
see below.

Additional Comments:

     Bidirectional Forwarding Detection (BFD) Directed Return Path

The title should include that this is *only* for MPLS BFD.

   When a BFD session monitors an explicitly routed unidirectional path
   there may be a need to direct egress BFD peer to use a specific path
   for the reverse direction of the BFD session.

Scope: is this solution targeted only for "explicitly routed unidirectional
path", and the solution to have the reply come back the exact reverse
direction? That does not seem to be the case and the solution.

   [RFC5880], [RFC5881], and [RFC5883] established the BFD protocol for
   IP networks.  [RFC5884] and [RFC7726] set rules of using BFD
   asynchronous mode over IP/MPLS LSPs.  These standards implicitly
   assume that the egress BFD peer will use the shortest path route
   regardless of route being used to send BFD control packets towards
   it.

Is "These standards" referring to the three former or the four latter?

   For the case where a LSP is explicitly routed it is likely that the
   shortest return path to the ingress BFD peer would not follow the
   same path as the LSP in the forward direction.  The fact that BFD
   control packets are not guaranteed to follow the same links and nodes
   in both forward and reverse directions is a significant factor in
   producing false positive defect notifications, i.e. false alarms, if
   used by the ingress BFD peer to deduce the state of the forward
   direction.

There may be an implicit mis-assumption in this text and overall approach: the
fact that traffic flows on one direction does not imply that the reverse
direction using the same interfaces and nodes would actually be consequently
properly programmed and working.

   This document defines the BFD Reverse Path TLV as an extension to LSP
   Ping [RFC8029] and proposes that it is to be used to instruct the
   egress BFD peer to use an explicit path for its BFD control packets
   associated with a particular BFD session.

This text assumes that the BFD return path is MPLS. However, my understanding
from RFC 5884 is that this is not necessarily the case, and the return can be
IP.

   When BFD is used to monitor unidirectional explicitly routed path,
   e.g.  MPLS-TE LSP, BFD control packets in forward direction would be
   in-band using the mechanism defined in [RFC5884] and [RFC5586].

Which BFD uses RFC 5586? RFC5586 says that is not needed:

   "Some of these functions can be supported using existing
   tools such as Virtual Circuit Connectivity Verification (VCCV)
   [RFC5085], Bidirectional Forwarding Detection for MPLS LSPs (BFD-
   MPLS) [BFD-MPLS], LSP-Ping [RFC4379], or BFD-VCCV [BFD-VCCV]."

And then:

   o  a failure detection by ingress node on the reverse path cannot be
      interpreted as bi-directional failure unambiguously and thus
      trigger, for example, protection switchover of the forward
      direction without possibility of being a false positive.

   To address this scenario the egress BFD peer would be instructed to
   use a specific path for BFD control packets.

But using a specific path for return cannot either imply "interpreted as
bi-directional failure unambiguously", so the scenario is not *addressed*.

   The BFD Reverse Path TLV carries information about the path onto
   which the egress BFD peer of the BFD session referenced by the BFD
   Discriminator TLV MUST transmit BFD control packets.  The format of
   the BFD Reverse Path TLV is as presented in Figure 1.

What does the remote endpoint do with that "MUST" if the return FEC goes away?

There also seem to be some self-contradiction. This document says:

   LSP ping, defined in [RFC8029], uses BFD Discriminator TLV [RFC5884]
   to bootstrap a BFD session over an MPLS LSP.  This document defines a
   new TLV, BFD Reverse Path TLV, that MUST contain a single sub-TLV
   that can be used to carry information about the reverse path for the
   BFD session that is specified by value in BFD Discriminator TLV.

And then says:

   Reverse Path field contains a sub-TLV.

But then says:

   None, one or more sub-TLVs MAY be included in the BFD Reverse
   Path TLV.  If none sub-TLVs found in the BFD Reverse Path TLV, the
   egress BFD peer MUST revert to using the default, i.e., over IP
   network, reverse path.

So is it only one, or none/one/multiple?

I believe it needs to be multiple since then a Tunnel can be specified. But the
document as-is seems self-contradicting.

Further, where has that "default" been defined as "over IP network"?

There's another contradiction here:

   If the egress LSR cannot find the path specified in the Reverse Path
   TLV it MUST send Echo Reply with the received Reverse Path TLV and
   set the Return Code to "Failed to establish the BFD session.  The
   specified reverse path was not found" Section 3.3.  The egress BFD
   peer MAY establish the BFD session over IP network as defined in
   [RFC5884].

So the response is "Failed to establish the BFD session." But then it MAY
establish the session? And, again, what if the path is found at bootstrap but
lost afterwards?

4.  Use Case Scenario

The fact that A-B-C-D-G-H works does not mean that the reverse, H-G-D-C-B-A,
will work.

6.  Security Considerations

   Security considerations discussed in [RFC5880], [RFC5884], [RFC7726],
   and [RFC8029], apply to this document.

There seem to be additional security considerations with returns taking
explicit paths, and should be expanded in here.

Net-net, I do have concerns about this document. I believe it is not ready to
advance, and could use more whiteboard time as well as a review by BFD experts.

Best,

Carlos Pignataro.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 12 Jul 2017 19:19:04 -0700

Dear Carlos,
thank you for sharing your detailed comments to the draft. Please find
response in-line and tagged GIM>>.

Regards,
Greg

> gets unconfigured, etc.)?

GIM>> Proposed in the draft mechanism to direct the reverse direction of
the BFD session onto specific MPLS LSP effectively puts the reverse
direction in the same environment as the forward direction of the BFD
session. What happens to the forward direction of the BFD session over MPLS
LSP if the LSP goes down? That must be detected as LSP failure and clients
of the BFD session, I'd expect, will be notified (that is rather outside of
BFD RFCs but we understand why and how proactive OAM is used). If the LSP
gets unconfigured before the BFD session, then, I assume, that will be
detected as LSP failure too. I think that these are very fundamental
scenarios but they are not discussed in RFC 5884 either.

In that case, not only this mechanism can actually make things worst,
> because
GIM>> I disagree with your conclusion that  the draft does not include
mechanism to switch the reverse path of the BFD session in Up state.
Firstly, the BFD Reverse Path TLV MAY be included in LSP Ping at any moment
in time, not only when bootstrapping BFD session. Secondly, the draft
states that if BFD Reverse Path TLV contains none sub-TLVs, then the
reverse path MUST be switched to IP network, which is the default behavior
per RFC 5884.

> one is notably missing from this draft.
GIM>> Frankly, I fail to find relevance of S-BFD to the proposed mechanism.
But if you insist on discussing S-BFD, then I see that its echo-like
mechanism that does not create state on the far end of S-BFD session rather
complicates potential mechanism to control the return path.

> The title should include that this is *only* for MPLS BFD.
GIM>> Accept this editorial change.

> direction? That does not seem to be the case and the solution.
GIM>> The mechanism is applicable to BFD over MPLS LSP. The quote
emphasizes one of use cases. Will prepend it , "without loss of generality
..." in the next version.

> Is "These standards" referring to the three former or the four latter?
GIM>> Thank you for pointing to the ambiguity. The reference to the latter
two. Will clarify in the next version.

> properly programmed and working.
GIM>> The proposed mechanism is optional and, of course, it has been
assumed that the operator will verify availability and liveliness of the
LSP to be used for the reverse direction of the given BFD session.

> from RFC 5884 is that this is not necessarily the case, and the return can
GIM>> You're absolutely correct in interpretation of RFC 5884, the reverse
direction of BFD session over MPLS LSP is always over IP. The proposed
mechanism provides option to change the default reverse path if and when
network operator sees that beneficial.

> Which BFD uses RFC 5586? RFC5586 says that is not needed:
GIM>> Can you please clarify what is not needed according to RFC 5586? LSP
Ping? BFD over MPLS-TP LSP?

> bi-directional failure unambiguously", so the scenario is not *addressed*.
GIM>> The proposed mechanism to control the reverse path of the BFD session
may improve determinism of defect detection in certain use cases.

> What does the remote endpoint do with that "MUST" if the return FEC goes
GIM>> Please see my response to the very first question. This is the same
situation as for the ingress LER per RFC 5884.

> So is it only one, or none/one/multiple?
GIM>> Thank you for pointing to this. In the next version will change to
explicitly state:

Reverse Path field contains none, one or more sub-TLVs.

> Further, where has that "default" been defined as "over IP network"?
GIM>> As per RFC 5884, the BFD control packets in reverse direction of the
BFD over MPLS LSP session are sent over IP.

> establish the session? And, again, what if the path is found at bootstrap
GIM>> Please see the response to the first question.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Jul 2017 05:04:00 -0400

Greg,

> reverse path MUST be switched to IP network, which is the default behavior

I'm not sure I agree with your conclusion.  As best I'm aware,
implementations only bootstrap their sessions to start with lsping.  I don't
recall discussion about procedures for updating existing sessions.  This may
be a fault of my memory - would you clarify where you believe this is
covered in 5884?

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Jul 2017 02:06:01 -0700

Hi Jeff,
true, the RFC 5884 does not discuss handling of subsequent LSP Ping with
the same BFD Discriminator value in BFD Discriminator TLV. My reference to
RFC 5884 is to point that the default, implied path for the reverse
direction of the BFD session is over IP network and that how this draft
interprets BFD Reverse Path TLV with none- sub-TLVs included. And yes,
nodes that would support this draft MUST handle subsequent LSP Ping Echo
Request with BFD Discriminator and BFD Reverse TLVs.

Regards,
Greg

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Jul 2017 05:23:32 -0400

> Request with BFD Discriminator and BFD Reverse TLVs.

I don't believe the procedure updating 5884 to change existing session
properties is called out in the -directed document.  I don't have a strong
opinion about the use case of whether such updates are desired or not.
That's a decision for the MPLS WG.  However, I do think such procedure needs
to be clear if it's desired.  This is part of Carlos' point.

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Jul 2017 02:24:33 -0700

Hi Jeff,
thank you for pointing that the use of LSP Ping to update the existing BFD
session should be explicitly documented in the draft. I agree that this is
valid request and, if the MPLS WG agrees, will add it in the next version
along what I've outlined in our discussion.

Regards,
Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 18 Jul 2017 10:32:24 +0000

> On Jul 17, 2017, at 11:13 AM, Jeffrey Haas <[email-masked]> wrote:
> 
>> interprets BFD Reverse Path TLV with none- sub-TLVs included.

Greg, I cannot find any default behavior specified in RFC 5884. Section 7, paragraphs 6 and 7 talk about and either/or. 

>> And yes,

This, along with its associated "how" is missing from the draft. 

> to be clear if it's desired.  This is part of Carlos' point.

Jeff, indeed. 

> -- Jeff

Thanks!

-- Carlos.