Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5189D1200C1; Wed, 12 Jul 2017 19:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMZTjqKxmEBq; Wed, 12 Jul 2017 19:19:06 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A5B1241FC; Wed, 12 Jul 2017 19:19:05 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id 16so39886647qkg.2; Wed, 12 Jul 2017 19:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u5xSdyrNWnC2xWBp2ABoGTY+0niSHsDFMNbHlpnVIW4=; b=bElPGB5tQSYWFEKueLQFRI6mD3EwMPBuj+5UvJKRWG3rD/jjrS8HMD4NRViYLjF7mk tMmjjA7FoLpgR6oMbvIeXysZpCHoDCsOfKedgaVapmyR+EdbAyxQz1DZCEsn3p6Tandl YKbDdtZS1xOTysyQoJWhcOOXkWKB0FE5aB+4+BIl7I++JgyK8KJ5DR8x5sVY2LSJ1c5R K26ejB3cvzrd4FwPDWwJf/E2t9EABj2or6FQiZ1XWDgEdCzB7T1PjR0g0JpVXtPnQGVQ f1tAmDkDNqPkVWUjYLk1X9CEN0cvPAOjhPSbqSqzaZUl1PkM/PuiBLdMiz+sThCEDUSW BHeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u5xSdyrNWnC2xWBp2ABoGTY+0niSHsDFMNbHlpnVIW4=; b=dnAn1yBkIutsvzH2xMuwzINEFhhnB//OpWRq81Nz1/ybhdQ9h2uXE32+idFM6fXq8l 2cdLHkZorqwfxnjL0eTmpOnxDmUHjcOB7NA5gZecmbLOtpBUY6bSATbkXR/bcM1tKhRG S7r8CIcyQx2GbMfsREEVeeuAVWkJA4lepCiQeYxMBq1NKKzqbmZkTvL9BGaf0wVx5+hK oWgDGixXmRhBfxOE+3fIciwXYDMbqKeZyW7I/o4In/MmKJy3KqE+30z2UoKGTiIhXtPw fe/PkuLAphZY87IG9ou4ETag+f4Atxsj3hH973g6hwrMCDEmFaNYe9pHwm7EUgwmkQ8M u1KA== X-Gm-Message-State: AIVw110tIsHr7Fue2GCFIwwjgnsPgpTrq/vqsRuodCIyfhgLhmov6J5l WKNWLNHtmOgpme21QP4E3fdIAY936Q== X-Received: by 10.55.162.210 with SMTP id l201mr1867673qke.180.1499912344745; Wed, 12 Jul 2017 19:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Wed, 12 Jul 2017 19:19:04 -0700 (PDT) In-Reply-To: <149978159930.12344.18347332855391607627@ietfa.amsl.com> References: <149978159930.12344.18347332855391607627@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 12 Jul 2017 19:19:04 -0700 Message-ID: To: Carlos Pignataro Cc: rtg-dir@ietf.org, "mpls@ietf.org" , draft-ietf-mpls-bfd-directed.all@ietf.org, bfd-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c06f22e80c0b20554298ec6" Archived-At: Subject: Re: [mpls] Rtgdir early review of draft-ietf-mpls-bfd-directed-07 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 02:19:09 -0000 --94eb2c06f22e80c0b20554298ec6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carlos, thank you for sharing your detailed comments to the draft. Please find response in-line and tagged GIM>>. Regards, Greg On Tue, Jul 11, 2017 at 6:59 AM, Carlos Pignataro wrote: > Reviewer: Carlos Pignataro > Review result: Has Issues > > Hello > > I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D = 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 =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for p= ublication to the > IESG. The early review can be performed at any time during the draft=E2= =80=99s > lifetime > as a working group document. The purpose of the early review depends on t= he > 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 > =E2=80=8Bhttp://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 th= e > 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 a= re > 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 dow= n, > 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 > it results in a false negative, but also the document does not specify ho= w > 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. > 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. > > 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. > 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. > > 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. > GIM>> Accept this editorial change. > > 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 unidirection= al > 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. > 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. > > [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? > GIM>> Thank you for pointing to the ambiguity. The reference to the latter two. Will clarify in the next version. > > 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. > 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. > > 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 ca= n > be > IP. > 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. > > 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: > GIM>> Can you please clarify what is not needed according to RFC 5586? LSP Ping? BFD over MPLS-TP LSP? > > "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*= . > GIM>> The proposed mechanism to control the reverse path of the BFD session may improve determinism of defect detection in certain use cases. > > 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? > GIM>> Please see my response to the very first question. This is the same situation as for the ingress LER per RFC 5884. > > 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? > 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. > 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"? > GIM>> As per RFC 5884, the BFD control packets in reverse direction of the BFD over MPLS LSP session are sent over IP. > > 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? > GIM>> Please see the response to the first question. > > 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 read= y > to > advance, and could use more whiteboard time as well as a review by BFD > experts. > > Best, > > Carlos Pignataro. > > --94eb2c06f22e80c0b20554298ec6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carlos,
thank you for sharing your detailed comme= nts to the draft. Please find response in-line and tagged GIM>>.

Regards,
Greg

On Tue, Jul 11, 2017 at 6:59 AM, Carlos Pi= gnataro <cpignata@cisco.com> wrote:
Reviewer: Carlos Pignataro
Review result: Has Issues

Hello

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this draft.
https://datatracker.ietf.org/doc/= draft-ietf-mpls-bfd-directed/

The routing directorate will, on request from the working group chair, perf= orm
an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for pub= lication to the
IESG. The early review can be performed at any time during the draft=E2=80= =99s 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 th= e
objective of improving document quality.=C2=A0 This document has had three<= br> unsuccessful WG LCs.

For more information about the Routing Directorate, please see
=E2=80=8Bhttp://trac.tools.ietf.org/area/rt= g/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 specificati= on
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<= br> 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 discrimina= tor
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=C2=A0 BFD control messages and bei= ng sent
back and forth, and while no MPLS LSP Ping packets are sent after bootstrap= ping
-- what happens if the return path changes (e.g., the return LSP goes down,=
gets unconfigured, etc.)?

GIM>> P= roposed in the draft mechanism to direct the reverse direction of the BFD s= ession 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 unconfigure= d before the BFD session, then, I assume, that will be detected as LSP fail= ure 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, becau= se
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 mecha= nism
to update or to deal with such a failure or change scenario.
GIM>> I disagree with your conclusion that =C2=A0the draft doe= s 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 an= y moment in time, not only when bootstrapping BFD session. Secondly, the dr= aft states that if BFD Reverse Path TLV contains none sub-TLVs, then the re= verse path MUST be switched to IP network, which is the default behavior pe= r RFC 5884.

On the other hand, there is already a BFD mechanism without the bootstrappi= ng
setup and with a command/response like behavior, that is S-BFD, RFC 7881. T= hat
one is notably missing from this draft.
GIM>> Fr= ankly, 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 tha= t does not create state on the far end of S-BFD session rather complicates = potential mechanism to control the return path.

Further, there seem to be a number of potentially erroneous assumptions mad= e,
see below.

Additional Comments:

=C2=A0 =C2=A0 =C2=A0Bidirectional Forwarding Detection (BFD) Directed Retur= n Path

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

=C2=A0 =C2=A0When a BFD session monitors an explicitly routed unidirectiona= l path
=C2=A0 =C2=A0there may be a need to direct egress BFD peer to use a specifi= c path
=C2=A0 =C2=A0for the reverse direction of the BFD session.

Scope: is this solution targeted only for "explicitly routed unidirect= ional
path", and the solution to have the reply come back the exact reverse<= br> 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.

=C2=A0 =C2=A0[RFC5880], [RFC5881], and [RFC5883] established the BFD protoc= ol for
=C2=A0 =C2=A0IP networks.=C2=A0 [RFC5884] and [RFC7726] set rules of using = BFD
=C2=A0 =C2=A0asynchronous mode over IP/MPLS LSPs.=C2=A0 These standards imp= licitly
=C2=A0 =C2=A0assume that the egress BFD peer will use the shortest path rou= te
=C2=A0 =C2=A0regardless of route being used to send BFD control packets tow= ards
=C2=A0 =C2=A0it.

Is "These standards" referring to the three former or the four la= tter?
GIM>> Thank you for pointing to the ambigu= ity. The reference to the latter two. Will clarify in the next version.=C2= =A0

=C2=A0 =C2=A0For the case where a LSP is explicitly routed it is likely tha= t the
=C2=A0 =C2=A0shortest return path to the ingress BFD peer would not follow = the
=C2=A0 =C2=A0same path as the LSP in the forward direction.=C2=A0 The fact = that BFD
=C2=A0 =C2=A0control packets are not guaranteed to follow the same links an= d nodes
=C2=A0 =C2=A0in both forward and reverse directions is a significant factor= in
=C2=A0 =C2=A0producing false positive defect notifications, i.e. false alar= ms, if
=C2=A0 =C2=A0used by the ingress BFD peer to deduce the state of the forwar= d
=C2=A0 =C2=A0direction.

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 consequentl= y
properly programmed and working.
GIM>> The propo= sed mechanism is optional and, of course, it has been assumed that the oper= ator will verify availability and liveliness of the LSP to be used for the = reverse direction of the given BFD session. =C2=A0

=C2=A0 =C2=A0This document defines the BFD Reverse Path TLV as an extension= to LSP
=C2=A0 =C2=A0Ping [RFC8029] and proposes that it is to be used to instruct = the
=C2=A0 =C2=A0egress BFD peer to use an explicit path for its BFD control pa= ckets
=C2=A0 =C2=A0associated with a particular BFD session.

This text assumes that the BFD return path is MPLS. However, my understandi= ng
from RFC 5884 is that this is not necessarily the case, and the return can = be
IP.
GIM>> You're absolutely correct in inter= pretation of RFC 5884, the reverse direction of BFD session over MPLS LSP i= s always over IP. The proposed mechanism provides option to change the defa= ult reverse path if and when network operator sees that beneficial.=C2=A0

=C2=A0 =C2=A0When BFD is used to monitor unidirectional explicitly routed p= ath,
=C2=A0 =C2=A0e.g.=C2=A0 MPLS-TE LSP, BFD control packets in forward directi= on would be
=C2=A0 =C2=A0in-band using the mechanism defined in [RFC5884] and [RFC5586]= .

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

=C2=A0 =C2=A0"Some of these functions can be supported using existing<= br> =C2=A0 =C2=A0tools such as Virtual Circuit Connectivity Verification (VCCV)=
=C2=A0 =C2=A0[RFC5085], Bidirectional Forwarding Detection for MPLS LSPs (B= FD-
=C2=A0 =C2=A0MPLS) [BFD-MPLS], LSP-Ping [RFC4379], or BFD-VCCV [BFD-VCCV].&= quot;

And then:

=C2=A0 =C2=A0o=C2=A0 a failure detection by ingress node on the reverse pat= h cannot be
=C2=A0 =C2=A0 =C2=A0 interpreted as bi-directional failure unambiguously an= d thus
=C2=A0 =C2=A0 =C2=A0 trigger, for example, protection switchover of the for= ward
=C2=A0 =C2=A0 =C2=A0 direction without possibility of being a false positiv= e.

=C2=A0 =C2=A0To address this scenario the egress BFD peer would be instruct= ed to
=C2=A0 =C2=A0use 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 *address= ed*.
GIM>> The proposed mechanism to control the= reverse path of the BFD session may improve determinism of defect detectio= n in certain use cases.

=C2=A0 =C2=A0The BFD Reverse Path TLV carries information about the path on= to
=C2=A0 =C2=A0which the egress BFD peer of the BFD session referenced by the= BFD
=C2=A0 =C2=A0Discriminator TLV MUST transmit BFD control packets.=C2=A0 The= format of
=C2=A0 =C2=A0the BFD Reverse Path TLV is as presented in Figure 1.

What does the remote endpoint do with that "MUST" if the return F= EC goes away?
GIM>> Please see my response to th= e very first question. This is the same situation as for the ingress LER pe= r RFC 5884.=C2=A0

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

=C2=A0 =C2=A0LSP ping, defined in [RFC8029], uses BFD Discriminator TLV [RF= C5884]
=C2=A0 =C2=A0to bootstrap a BFD session over an MPLS LSP.=C2=A0 This docume= nt defines a
=C2=A0 =C2=A0new TLV, BFD Reverse Path TLV, that MUST contain a single sub-= TLV
=C2=A0 =C2=A0that can be used to carry information about the reverse path f= or the
=C2=A0 =C2=A0BFD session that is specified by value in BFD Discriminator TL= V.

And then says:

=C2=A0 =C2=A0Reverse Path field contains a sub-TLV.

But then says:

=C2=A0 =C2=A0None, one or more sub-TLVs MAY be included in the BFD Reverse<= br> =C2=A0 =C2=A0Path TLV.=C2=A0 If none sub-TLVs found in the BFD Reverse Path= TLV, the
=C2=A0 =C2=A0egress BFD peer MUST revert to using the default, i.e., over I= P
=C2=A0 =C2=A0network, reverse path.

So is it only one, or none/one/multiple?
GIM>> T= hank you for pointing to this. In the next version will change to explicitl= y state:
R= everse Path field contains none, one or more sub-TLVs.

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 n= etwork"?
GIM>> As per RFC 5884, the BFD con= trol packets in reverse direction of the BFD over MPLS LSP session are sent= over IP.

There's another contradiction here:

=C2=A0 =C2=A0If the egress LSR cannot find the path specified in the Revers= e Path
=C2=A0 =C2=A0TLV it MUST send Echo Reply with the received Reverse Path TLV= and
=C2=A0 =C2=A0set the Return Code to "Failed to establish the BFD sessi= on.=C2=A0 The
=C2=A0 =C2=A0specified reverse path was not found" Section 3.3.=C2=A0 = The egress BFD
=C2=A0 =C2=A0peer MAY establish the BFD session over IP network as defined = in
=C2=A0 =C2=A0[RFC5884].

So the response is "Failed to establish the BFD session." But the= n it MAY
establish the session? And, again, what if the path is found at bootstrap b= ut
lost afterwards?
GIM>> Please see the response t= o the first question.=C2=A0

4.=C2=A0 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.=C2=A0 Security Considerations

=C2=A0 =C2=A0Security considerations discussed in [RFC5880], [RFC5884], [RF= C7726],
=C2=A0 =C2=A0and [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 expe= rts.

Best,

Carlos Pignataro.


--94eb2c06f22e80c0b20554298ec6--