Early Review of draft-ietf-mpls-bfd-directed-07
(document currently at 11)
Routing Area Directorate
||Draft last updated
Rtgdir Early review of -07 by Carlos Pignataro
The draft has a Long history, at the moment we are in doing the 3rd WG LC - the former last call was not successful because of an IPR issue/disclosure. With the new Version the authors state that the IPR is not applicable anymore. Carlos Pignataro (cpignata) [email@example.com] has volunteered to be one of the reviewers.
||07 (document currently at 11)
I have been selected to do a routing directorate “early” review of this draft.
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
Reviewer: Carlos Pignataro
Review Date: Early July, 2017
Intended Status: Standards Track
I have significant concerns about this document.
I also recommend a BFD WG Chair or appointee to review this document.
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.
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
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
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]."
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
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.