Re: [RTG-DIR] Rtgdir early review of draft-ietf-mpls-bfd-directed-07

["BRUNGARD, DEBORAH A" <[e-mail]>]

Much thanks Carlos for your review!
Deborah


> -----Original Message-----
> From: Carlos Pignataro [mailto:[e-mail]]
> Sent: Tuesday, July 11, 2017 10:00 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; bfd-
> [e-mail]
> Subject: Rtgdir early review of draft-ietf-mpls-bfd-directed-07
> 
> Reviewer: Carlos Pignataro
> Review result: Has Issues
> 
> Hello
> 
> I have been selected to do a routing directorate “early” review of this draft.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2Dbfd-
> 2Ddirected_&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=fNoppFpdpAL1k24Ox
> IY2W0DZajMRBM8B72Nk3OtMjEA&s=wB6Y9Hhrd5tH8fcBJQDUj3Kt4gtLOGSxNq
> VGmtCII1U&e=
> 
> 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
> ​https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=fNoppFpdpAL1k24Ox
> IY2W0DZajMRBM8B72Nk3OtMjEA&s=UveGilLeWwbO4jbOxOfNYJH6hHaujJr9ul
> Brq0dwCKU&e=
> 
> 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.