From nobody Tue Sep 1 14:25:08 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760E83A10EC; Tue, 1 Sep 2020 14:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 SkvM_Sdm7GC1; Tue, 1 Sep 2020 14:25:00 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 6E60A3A0417; Tue, 1 Sep 2020 14:24:59 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id s205so3312817lja.7; Tue, 01 Sep 2020 14:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4iDZopkvUYFyDHkD/7RgDB300B3J+JKtIjIaIBsVCUc=; b=RaivAXzvrfsL4x86fCoBJyFGIVXhl0gatjfYIl29hBPtZy4vQVikDZrXglD7vSo96e LBB9wUlZxcUzdDajesyZ00kAQ57NZ/48F4Gh2yZI0LY+Jb0ZoM3Z26/7UYFw1PHg2m9X iO2SVP6aZ3O7VRnEXyvvu7daShpycMyrWkOO9jnroZOcIkUkYRplxzancBhfMmsfux+n rtKyTEU0+ELy+5pUfy+xrJwM64B109QaLJmfXYH3BbJU/27U2t7qr1dyaXnjfFT7YtFJ RJsFPA2UeHcPU9fwY9erFz4t7vLpSfgj0azM626OOPx8pNPM3g+LKhkNYznYuXvkelgX lCsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4iDZopkvUYFyDHkD/7RgDB300B3J+JKtIjIaIBsVCUc=; b=gIkq6ITVZHTY+DITiSrKLMOi5/LmatV2I9FjbJhcKsE8KvBSK4srUoB49fUl6SHzSw GjKHKjCVeE7wxbEl/ghWd4w2gSe/sco2H4TxmlsXxoHbfVTM1OLYU7vYhrNpdhbgliNS d3UjOKRSPh704USiqSlNlT92e1drqbNXagqYXGlriPBNgSe3TwumbvGpFHPVzl3i3A0D Ah94a+Wbv+mMPPr3mcP2vsuAx/XGKvjDStdNHBBu5/O3+VC/AJGaTCx/PnwzS+S5LzUR Qbm9ai6L5GGLHWfcRzA3/QN7m/rcaXtk9MZ4sz2ge9hEUB7SePJWlT8WCx4A5zKNOigq /3ug== X-Gm-Message-State: AOAM533wU/gazQMMG4xOcU+MPblSN3tZjQhxXXq+65145PmkF0syb4Ma g1WHYgGt2ha7OG5puiHBBT9A5g/CGCRVd+ODdT4RVTzG X-Google-Smtp-Source: ABdhPJxRLw2gpn5lnICrCS7Q2t5e6HqNkcy6YYe7YPrOcVtS/cTws7/KpYaoCAFQI888dLm/7dyta0q4vl0zthJhoVA= X-Received: by 2002:a2e:87c4:: with SMTP id v4mr1610022ljj.8.1598995496823; Tue, 01 Sep 2020 14:24:56 -0700 (PDT) MIME-Version: 1.0 References: <149978159930.12344.18347332855391607627@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Tue, 1 Sep 2020 14:24:44 -0700 Message-ID: To: mpls , MPLS Working Group Cc: Routing Directorate , "draft-ietf-mpls-bfd-directed@ietf.org" , "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary="00000000000095faba05ae4726d9" Archived-At: Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-mpls-bfd-directed-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 21:25:06 -0000 --00000000000095faba05ae4726d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear MPLS WG Chairs, as noted at the WG meeting during IETF-108, all technical comments from the early RtgDir review have been addressed. The draft was updated and includes the Operational Considerations section explaining the use of the controlled reverse path of a BFD session in the combination with periodic MPLS LSP ping. Also, the Implementation Status section hs been added to report one known implementation of the mechanism defined in the draft. The authors discussed the status of the draft and ask your consideration for the WG LC. Regards, Greg (on behalf of the authors) On Tue, Aug 4, 2020 at 7:39 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, > > Since I originated the =E2=80=9Cearly review=E2=80=9D, and my email is in= cluded in the > =E2=80=9CTo=E2=80=9D line, I feel I should respond and comment. > > The review mentioned below is over 3 years old, over 1,100 days old. > > Before and after that =E2=80=98early review=E2=80=99 there have been seve= ral others. > > My perspective continues to be that the method in mpls-bfd-directed is no= t > sensible =E2=80=94 what works well for MPLS LSP Ping as a command/respons= e paradigm > to choose a return path, does not extend to long-lived sessions such as > BFD. Scanning through the current revision of the document, it continues = to > be underspecified to the point of being harmful. > > Best, > > Carlos. > > > 2020/08/04 =E5=8D=88=E5=BE=8C6:39=E3=80=81Greg Mirsky =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > > Dear All, > as we've discussed at the MPLS WG meeting at IETF-108, I've been given an > action point to match updates to the draft-ietf-mpls-bfd-directed with th= e > RtgDir early review comments. Please find notes from the authors in-line > under GIM>> and Mach>> tags. > Welcome your questions, comments. > > Regards, > Greg (on behalf of the authors) > > ---------- Forwarded message --------- > From: Carlos Pignataro > Date: Tue, Jul 11, 2017 at 7:00 AM > Subject: Rtgdir early review of draft-ietf-mpls-bfd-directed-07 > To: > Cc: , , < > bfd-chairs@ietf.org> > > > 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 > 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 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>> Need to note that after bootstrapping a BFD session over MPLS LSP > with the MPLS LSP Ping that includes the BFD Discriminator TLV, > MPLS LSP Ping is periodically sent according to Section 3.2 RFC 5884: > Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault > detection: > ... > iii) LSP Ping is used to periodically verify the control plane > against the data plane by ensuring that the LSP is mapped to > the same FEC, at the egress, as the ingress. > [Mach] If the return LSP goes down, then the BFD session should go down a= s > well, this's one of the goals that this solution is trying to achieve. Fo= r > example, in some case, it want the forward and reverse paths share the sa= me > route and fate. The return path down normally means the forward path is > down as well. > > 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. > [Mach] As above, this result is desired in the case that requires the > forward and reverse path share route and fate. It should be kept down unt= il > the specified return path recovered. > > 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>> We've added the Operational Considerations section that describes > how the local BFD system using periodic MPLS LSP Ping can monitor the > viability of the Reverse path. Particularly, the text that describes this= : > If any of defined in > [RFC7110] sub-TLVs used in BFD Reverse Path TLV, then the periodic > verification of the control plane against the data plane, as > recommended in Section 4 [RFC5884], MUST use the Return Path TLV, as > per [RFC7110], with that sub-TLV. By using the LSP Ping with Return > Path TLV, an operator monitors whether at the egress BFD node the > reverse LSP is mapped to the same FEC as the BFD session. Selection > and control of the rate of LSP Ping with Return Path TLV follows the > recommendation of [RFC5884]: "The rate of generation of these LSP > Ping Echo request messages SHOULD be significantly less than the rate > of generation of the BFD Control packets. An implementation MAY > provide configuration options to control the rate of generation of > the periodic LSP Ping Echo request messages." > > 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>> The goal of the proposed mechanism is not to avoid bootstrapping a > BFD over MPLS LSP session or simulate Echo Response/Reply behavior but to > control the path the remote BFD system uses to transmit BFD control packe= ts > in BFD Asynchronous mode. > [Mach] The purpose of this draft is to specify a particular return path, > S-BFD cannot specify the return path, thus cannot satisfy the requirement= . > > 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>> Thank you for the helpful editorial suggestion. > > 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 path from the remote BFD system may traverse the same nodes and > links traversed by the BFD control packets transmitted from the ingress > LER, i.e., be co-routed. But the proposed mechanism is more generic and > allows an operator to control the path traversed by a BFD control packet > transmitted by the egress LER. > > [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>> Two latter two. We've clarified that by the following update: > OLD TEXT: > [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. > NEW TEXT: > [RFC5884] and [RFC7726] set rules for using BFD > asynchronous mode over IP/MPLS LSPs, while not defining means to > control the path an egress BFD system uses to send BFD control > packets towards the ingress BFD system. > > 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>> If the objective of controlling the path from the egress to the > ingress system is to monitor such path, then detecting a defect in the > forwarding path fulfills the objective. > > 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>> The document defines an optional mechanism to control the BFD > Reverse path. The default behavior, if the BFD Reverse Path TLV is not > included in the MPLS LSP Ping with the BFD Discriminator TLV, remains, as > you've noted - over 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: > GIM>> We've removed references to RFC 5586. > > "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? > GIM>> The Operational Considerations section includes the following text: > Suppose an operator planned network maintenance activity that > possibly affects FEC used in the BFD Reverse Path TLV. In that case, > the operator MUST avoid the unnecessary disruption using the LSP Ping > with a new FEC in the BFD Reverse Path TLV. But in some scenarios, > proactive measures cannot be taken. Because the frequency of LSP > Ping messages will be lower than the defect detection time provided > by the BFD session. As a result, a change in the reverse-path FEC > will first be detected as the BFD session's failure. In such a case, > the ingress BFD node SHOULD immediately transmit the LSP Ping Echo > request with Return Path TLV to verify whether the FEC is still > valid. If the failure was caused by the change in the FEC used for > the reverse direction of the BFD session, the ingress BFD node SHOULD > bootstrap a new BFD session using another FEC in BFD Reverse Path > TLV. > > 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 this. Below is the update in the working > version of the draft: > OLD TEXT: > 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 the value in > BFD Discriminator TLV. > NEW TEXT: > This > document defines a new TLV, BFD Reverse Path TLV, that MAY contain > none, one or more sub-TLVs that can be used to carry information > about the reverse path for the BFD session that is specified by the > value in BFD Discriminator TLV. > > and one more: > OLD TEXT: > Reverse Path field contains a sub-TLV > NEW TEXT: > 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>> The text was re-worked to avoid using "default": > If no sub-TLVs are found in the BFD > Reverse Path TLV, the egress BFD peer MUST revert to using the local > policy based decision as described in Section 7 [RFC5884], i.e., > routed 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? > GIM>> Echo Reply with the error code is to indicate that the reverse path > is not available at the egress LSR. The local policy at the egress BFD > system may command the transmission of a BFD control packet from egress t= o > the ingress if the Reverse Path is not available. > And, again, what if the path is found at bootstrap but > lost afterwards? > GIM>> Section 5 includes text that provides information on handling such = a > scenario. > > 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. > GIM>> If the objective is to verify that the reverse path works, then > detecting a defect fulfills the task. > 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. > GIM>> That scenario is discussed in the Security Considerations section i= n > RFC 7110. A reference to RFC 7110 was added: > > Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], > [RFC8029], and [RFC7110] apply to this document. > > 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. > > > --00000000000095faba05ae4726d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear MPLS WG Chairs,
as noted at the WG meeting during= IETF-108, all technical comments from the early RtgDir review have been ad= dressed. The draft was updated and includes the Operational Considerations = section explaining the use of the controlled reverse path of a BFD session = in the combination with periodic MPLS LSP ping. Also, the Implementation St= atus section hs been=C2=A0added to report one known implementation of the m= echanism=C2=A0defined in the draft. The authors discussed the status of the= draft and ask your consideration for the WG LC.

R= egards,
Greg (on behalf of the authors)

On Tue, Aug 4, 2020 = at 7:39 PM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi,

Since I originated the =E2=80=9Cearly review=E2=80=9D, and my email is= included in the =E2=80=9CTo=E2=80=9D line, I feel I should respond and com= ment.

The review mentioned below is over 3 years old, over 1,100 days old.

Before and after that =E2=80=98early review=E2=80=99 there have been s= everal others.=C2=A0

My perspective continues to be that the method in mpls-bfd-directed=C2= =A0is not sensible =E2=80=94 what works well for MPLS LSP Ping as a command= /response paradigm to choose a return path, does not extend to long-lived s= essions such as BFD. Scanning through the current revision of the document, it continues to be underspecified to= the point of being harmful.

Best,

Carlos.


2020/08/04 =E5=8D=88=E5=BE=8C6:39=E3=80=81Greg Mirsky <gregimirsky@gmail.com>= ;=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:


Dear All,
as we've discussed at the MPLS WG meeting at IETF-108, I've be= en given an action point to match updates to the draft-ietf-mpls-bfd-direct= ed with the RtgDir early review comments. Please find notes from the author= s in-line under GIM>> and Mach>> tags.
Welcome your questions, comments.

Regards,
Greg (on behalf of the authors)

---------- Forwarded message --------= -
From: Carlos Pignataro <cpignata@cisco.= com>
Date: Tue, Jul 11, 2017 at 7:00 AM
Subject: Rtgdir early review of draft-ietf-mpls-bfd-directed-07
To: <rtg-dir@ietf.= org>
Cc: <mpls@ietf.org>, <draft-ietf-mpls-bfd-directed.all@ietf.org>, <bfd-chairs@ietf.org= >


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
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

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>> Need to note that after bootstrappin= g a BFD session over MPLS LSP with the MPLS LSP Ping that includes the BFD = Discriminator TLV,
MPLS LSP Ping is periodically sent according to = Section 3.2 RFC 5884:
=C2=A0 =C2=A0Hence, BFD is used in conjunction w= ith LSP Ping for MPLS LSP fault
=C2=A0 =C2=A0detection:
...
=C2=A0 =C2=A0 iii) LSP Ping is used to periodica= lly verify the control plane
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0against the data plane by ensuring that t= he LSP is mapped to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the same FEC, at the egress, as the ingre= ss.
[Mach] If the return LSP goes down, then the BFD= session should go down as well, this's one of the goals that this solu= tion is trying to achieve. For example, in some case, it want the forward a= nd reverse paths share the same route and fate.=C2=A0 The return path down normally means the forward path is do= wn as well.

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.=C2=A0
[Mach]=C2=A0As above, this result is desired in = the case that requires the forward and reverse path share route and fate. I= t should be kept down until the specified return path recovered.

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>> We've added the Operational Cons= iderations section that describes how the local BFD system using periodic M= PLS LSP Ping can monitor the viability of the Reverse path. Particularly, t= he text that describes this:
=C2=A0 =C2=A0If any of defined in
=C2=A0 =C2=A0[RFC7110] sub-TLVs used in BFD Reverse Path TLV, then the peri= odic
=C2=A0 =C2=A0verification of the control plane against the data plane, as =C2=A0 =C2=A0recommended in Section 4 [RFC5884], MUST use the Return Path T= LV, as
=C2=A0 =C2=A0per [RFC7110], with that sub-TLV.=C2=A0 By using the LSP Ping = with Return
=C2=A0 =C2=A0Path TLV, an operator monitors whether at the egress BFD node = the
=C2=A0 =C2=A0reverse LSP is mapped to the same FEC as the BFD session.=C2= =A0 Selection
=C2=A0 =C2=A0and control of the rate of LSP Ping with Return Path TLV follo= ws the
=C2=A0 =C2=A0recommendation of [RFC5884]: "The rate of generation of t= hese LSP
=C2=A0 =C2=A0Ping Echo request messages SHOULD be significantly less than t= he rate
=C2=A0 =C2=A0of generation of the BFD Control packets.=C2=A0 An implementat= ion MAY
=C2=A0 =C2=A0provide configuration options to control the rate of generatio= n of
=C2=A0 =C2=A0the periodic LSP Ping Echo request messages."

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>> The goal of the proposed mechanism i= s not to avoid bootstrapping a BFD over MPLS LSP session or simulate Echo R= esponse/Reply behavior but to control the path the remote BFD system uses t= o transmit BFD control packets in BFD Asynchronous mode.
[Mach] The purpose of this draft is to specify a= particular return path, S-BFD cannot specify the return path, thus cannot = satisfy the requirement.

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>> Thank you for the helpful editorial = suggestion.

=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 path from the remote BFD system = may traverse the same nodes and links traversed by the BFD control packets = transmitted from the ingress LER, i.e., be co-routed. But the proposed mech= anism is more generic and allows an operator to control the path traversed by a BFD control packet transmitted by the e= gress LER.

=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>> Two latter two. We've clarified = that by the following update:
OLD TEXT:
=C2=A0 =C2=A0[RFC5884] and [RFC7726] set rules o= f 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.=C2=A0
NEW TEXT:
[RFC5884] and [RFC7726] set rules for using BFD
=C2=A0 =C2=A0asynchronous mode over IP/MPLS LSPs, while not defining means = to
=C2=A0 =C2=A0control the path an egress BFD system uses to send BFD control=
=C2=A0 =C2=A0packets towards the ingress BFD sys= tem.=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>> If the objective of controlling the = path from the egress to the ingress system is to monitor such path, then de= tecting a defect in the forwarding path fulfills the objective.

=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>> The document defines an optional mec= hanism to control the BFD Reverse path. The default behavior, if the BFD Re= verse Path TLV is not included in the MPLS LSP Ping with the BFD Discrimina= tor TLV, remains, as you've noted - over IP.

=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:
GIM>> We've removed references to RFC = 5586.

=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*.

=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>> The Operational Considerations secti= on includes the following text:
=C2=A0 =C2=A0Suppose an operator planned network= maintenance activity that
=C2=A0 =C2=A0possibly affects FEC used in the BFD Reverse Path TLV.=C2=A0 I= n that case,
=C2=A0 =C2=A0the operator MUST avoid the unnecessary disruption using the L= SP Ping
=C2=A0 =C2=A0with a new FEC in the BFD Reverse Path TLV.=C2=A0 But in some = scenarios,
=C2=A0 =C2=A0proactive measures cannot be taken.=C2=A0 Because the frequenc= y of LSP
=C2=A0 =C2=A0Ping messages will be lower than the defect detection time pro= vided
=C2=A0 =C2=A0by the BFD session.=C2=A0 As a result, a change in the reverse= -path FEC
=C2=A0 =C2=A0will first be detected as the BFD session's failure.=C2=A0= In such a case,
=C2=A0 =C2=A0the ingress BFD node SHOULD immediately transmit the LSP Ping = Echo
=C2=A0 =C2=A0request with Return Path TLV to verify whether the FEC is stil= l
=C2=A0 =C2=A0valid.=C2=A0 If the failure was caused by the change in the FE= C used for
=C2=A0 =C2=A0the reverse direction of the BFD session, the ingress BFD node= SHOULD
=C2=A0 =C2=A0bootstrap a new BFD session using another FEC in BFD Reverse P= ath
=C2=A0 =C2=A0TLV.

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>> Thank you for pointing this. Below i= s the update in the working version of the draft:
OLD TEXT:
=C2=A0 =C2=A0This
=C2=A0 =C2=A0document defines a new TLV, BFD Reverse Path TLV, that MUST co= ntain a
=C2=A0 =C2=A0single sub-TLV that can be used to carry information about the=
=C2=A0 =C2=A0reverse path for the BFD session that is specified by the valu= e in
=C2=A0 =C2=A0BFD Discriminator TLV.
NEW TEXT:
=C2=A0 =C2=A0This
=C2=A0 =C2=A0document defines a new TLV, BFD Reverse Path TLV, that MAY con= tain
=C2=A0 =C2=A0none, one or more sub-TLVs that can be used to carry informati= on
=C2=A0 =C2=A0about the reverse path for the BFD session that is specified b= y the
=C2=A0 =C2=A0value in BFD Discriminator TLV.

and one more:
OLD TEXT:
Reverse Path field contains a sub-TLV
NEW TEXT:
Reverse Path field contains none, one or more su= b-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>> The text was re-worked to avoid usin= g "default":
=C2=A0 =C2=A0If no sub-TLVs are found in the BFD=
=C2=A0 =C2=A0Reverse Path TLV, the egress BFD peer MUST revert to using the= local
=C2=A0 =C2=A0policy based decision as described in Section 7 [RFC5884], i.e= .,
=C2=A0 =C2=A0routed over IP network.

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?=C2=A0
GIM>> Echo Reply with the error code is to= indicate that the reverse path is not available at the egress LSR. The loc= al policy at the egress BFD system may command the transmission of a BFD co= ntrol packet from egress to the ingress if the Reverse Path is not available.
And, again, what if the path is found at bootstr= ap but
lost afterwards?
GIM>> Section 5 includes text that provide= s information on handling such a scenario.

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.
GIM>> If the objective is to verify that the reverse path works, then= detecting a defect fulfills the task.
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.
GIM>> That scenario is discussed in the Se= curity Considerations section in RFC 7110. A reference to RFC 7110 was adde= d:

=C2=A0 =C2=A0Security considerations discussed i= n [RFC5880], [RFC5884], [RFC7726],
=C2=A0 =C2=A0[RFC8029], and [RFC7110] apply to this document.

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.


--00000000000095faba05ae4726d9-- From nobody Wed Sep 16 08:01:19 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7033A0475; Wed, 16 Sep 2020 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 tYvLo6_fJhHu; Wed, 16 Sep 2020 08:01:09 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 E5D973A041B; Wed, 16 Sep 2020 08:01:08 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id b6so8592679iof.6; Wed, 16 Sep 2020 08:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6h/EOEJXnV/kAEipkTLGKdCJv63WUzeeLrCxZ3BdxWM=; b=PosNOII98XuWSHqusTGK6xamMJk1KnZjjmLuwzsRr+cM+HybYatEKqA3ZuRMBjCj9+ x6rDTTqdja3X4ev1nO1qjFgC+0roYUw+1aL4qT4fadECrZAKI/9EKJ0axt7BIS2yZNBL yt3EGNuT1Ic6WcTHncNjhz7WZTrX7eYoTb8tSjEDic3L+dUcyrvxu7vVgen89wtl1d0T Tc+/LAEIi5vvzEdgC2W2n8v4U2LUnVI/J4wmnP8rv88DB07gm8wO9qB2+CXuFlc3NoH1 Up+oejM9mZzSV/jsVzDt4M6yEn2tZqhLc3vn8yjXZerql50ehijOCAfeShlLT3QQW2eR ksqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6h/EOEJXnV/kAEipkTLGKdCJv63WUzeeLrCxZ3BdxWM=; b=MRUDVXbkQy3CduFh8EpANj4FyLoV0TF3SFb/VtD7en+XESB9Y0cioVXkymeji3O1gm gTfH9EMRI/GJ7Ka8YDkW0CKICoil8wGEdA1AZH/7KkTFQseASQoWc3DOavjG+ZUGRwT7 I9niQsyVKOmBVG6yg/2r6hODVwoJ7VISXBcGjMAf0q641tMj+QnOfpplBBPv3+jX6enR OWuhVfpZtp9Ea/AepKK3+vAQ3p4d9eZ7PjbkOcAKqT67Qz/GuE8V2yLUNqrVDUFjcLLG 7jXf2LRVt3WZaryEPBO6Tckd7sfb0ln6jANEkzJlpkam2fCRSP0hSHu7u7w8rbgNcFDT EH+Q== X-Gm-Message-State: AOAM532h9gtw4oilCe+XxCf4Ot1s8+FYiXGrRyYqUPM2YTdAGA415etI 0IGvucEpSbJWyEA0XR9Jv1LNWPObbT+k89WjPSLOh4BXOms= X-Google-Smtp-Source: ABdhPJxQYJ0N5kbmR9QtiGub/K1UkahaRJYicvalh64qytduM8kzKnZgqdIObqP48cf4OEIo9dnY0W+VvRqqZuRhPbE= X-Received: by 2002:a5d:9842:: with SMTP id p2mr10276091ios.113.1600268466802; Wed, 16 Sep 2020 08:01:06 -0700 (PDT) MIME-Version: 1.0 References: <156707010100.21081.6369578151637642112@ietfa.amsl.com> In-Reply-To: <156707010100.21081.6369578151637642112@ietfa.amsl.com> From: Kireeti Kompella Date: Wed, 16 Sep 2020 08:00:55 -0700 Message-ID: To: Susan Hares Cc: rtg-dir@ietf.org, draft-ietf-mpls-rmr.all@ietf.org, mpls@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="00000000000082520d05af6f897b" Archived-At: Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-rmr-11 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2020 15:01:11 -0000 --00000000000082520d05af6f897b Content-Type: text/plain; charset="UTF-8" Hi Sue, Sorry for the very late reply. Thank you for reviewing this draft (again!). The comments you had for the -09 were addressed; the -13 version addresses your comments to the -11 version. See inline. On Thu, Aug 29, 2019 at 2:15 AM Susan Hares via Datatracker < noreply@ietf.org> wrote: > Reviewer: Susan Hares > Review result: Has Nits > > Authors: Thank you for continuing to refine this document. > Status: editorial nits: > > #1 - Section 3.3 paragraph 1, last sentence > old/RMR is primarly intended for operation at the packet layer; > however, parallel links at hte lambda or fiber layer result in > parallel links at the packet layer./ > > question: Did you want to say /may result/ intead of /result/ > Definitely better with "may". #2 - Section 3.7 - Would be easier to read if you included a diagram. > #3 - Section 4.4 - Would be easier to read if you included a diagram > > Rational for requesting diagram: You are explaining the technology > that requires additional TLVs in other protocols (IGPS) > Added diagrams to both the above sections. #4 - Section 5 - (editorial only) This one section jars the reader > to ask "why am I bothered with this section." > > I understand why you want to make this clear that this point. > However, in section 1 you lay out the protocols. Do you also want to > do this here? Either choice works technically. However this > document is dually focused: summary of RMR concepts to > those writing future specifications and RMR to those > desiring to install these solutions. Does this section help > those desiring to install these solutions to find the other document? > Deleted. Thanks again for the reviews, Kireeti --00000000000082520d05af6f897b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sue,

Sorry for the very late reply.

Thank you = for reviewing this draft (again!).=C2=A0 The comments you had for the -09 w= ere addressed; the -13 version addresses your comments to the -11 version.<= /div>

See inline.

On Thu, Aug 29, 2019 at 2:15 AM Sus= an Hares via Datatracker <noreply@ie= tf.org> wrote:
Reviewer: Susan Hares
Review result: Has Nits

Authors: Thank you for continuing to refine this document.=C2=A0
Status: editorial nits:=C2=A0

#1 - Section 3.3 paragraph 1, last sentence
old/RMR is primarly intended for operation at the packet layer;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however, parallel links at hte lambda or fiber l= ayer result in
=C2=A0 =C2=A0 =C2=A0 parallel links at the packet layer./

question:=C2=A0 Did you want to say /may result/ intead of /result/

Definitely better with "may".
<= div>
#2 - Section 3.7 - Would be easier to read if you included a diagram.
#3 - Section 4.4 - Would be easier to read if you included a diagram

Rational for requesting diagram: You are explaining the technology
that requires additional TLVs in other protocols (IGPS)

Added diagrams to both the above sections.

=
#4 - Section 5 - (editorial only)=C2=A0 This one section jars the reader to ask "why am I bothered with this section."=C2=A0 =C2=A0

I understand why you want to make this clear that this point.
However, in section 1 you lay out the protocols. Do you also want to
do this here?=C2=A0 =C2=A0Either choice works technically.=C2=A0 However th= is
document is dually focused: summary of RMR concepts to
those writing future specifications and RMR to those
desiring to install these solutions.=C2=A0 =C2=A0Does this section help those desiring to install these solutions to find the other document?
<= /blockquote>

Deleted.

=
Thanks again for the reviews,
Kireeti
--00000000000082520d05af6f897b--