[mpls] Opsdir last call review of draft-ietf-mpls-bfd-directed-27
Joe Clarke via Datatracker <noreply@ietf.org> Fri, 12 April 2024 17:18 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72694C151069; Fri, 12 Apr 2024 10:18:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-mpls-bfd-directed.all@ietf.org, last-call@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171294228645.36819.2486980913632249384@ietfa.amsl.com>
Reply-To: Joe Clarke <jclarke@cisco.com>
Date: Fri, 12 Apr 2024 10:18:06 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/pbDjeb6PKUXiOZ8tcpuZNoRgd60>
Subject: [mpls] Opsdir last call review of draft-ietf-mpls-bfd-directed-27
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2024 17:18:06 -0000
Reviewer: Joe Clarke Review result: Has Nits I have been asked to review this document on behalf of the OPS directorate. While overall, I found the document readable and clear, I do have a few comments and a question, so I chose a state of Has Nits. However, I feel it is mostly ready. I also appreciate the Operational Considerations section and the additional MTU text suggested by Andrew. One comment I have is around terminology and abbreviations. I know this is an mplswg document, but you did expand BFD and LSP. I think it would be helpful to expand FEC and LSR, too. The other comment I have is around use ingress and egress "BFD peer". I like this terminology, but you have cases in Section 1 where you use ingress and egress BFD "system". In Section 3.1, you mix in "egress LSR". In Section 5, you mix in "ingress BFD node". I would suggest consistent terminology. I like peer and peer LSR also works for me. On that topic, thank you for the example in Section 4. I would just add that perhaps you label or describe node A as the ingress BFD peer [LSR] and H as the egress BFD peer [LSR]. It would help tie the figure to the rest of the text. Finally, my question. In the Operational Consideration, what would (or should) happen to the underlying service while the LSP ping is processed in the case of reverse-path FEC failure? Is there guidance to provide to maintain service while this new session might be established?
- [mpls] Opsdir last call review of draft-ietf-mpls… Joe Clarke via Datatracker
- Re: [mpls] Opsdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Opsdir last call review of draft-ietf-… Joe Clarke (jclarke)
- Re: [mpls] Opsdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Opsdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Opsdir last call review of draft-ietf-… Joe Clarke (jclarke)
- Re: [mpls] Opsdir last call review of draft-ietf-… Greg Mirsky