Re: [Last-Call] Opsdir last call review of draft-ietf-mpls-bfd-directed-27
Greg Mirsky <gregimirsky@gmail.com> Sun, 14 April 2024 09:03 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE37C14F69E; Sun, 14 Apr 2024 02:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INOOVFWtPV_d; Sun, 14 Apr 2024 02:03:34 -0700 (PDT)
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4465AC14F619; Sun, 14 Apr 2024 02:03:34 -0700 (PDT)
Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-617ddc988f5so25786827b3.2; Sun, 14 Apr 2024 02:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713085413; x=1713690213; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZCcoY6VoTKYNEQSasf4wKT3BWMHcnZ87+4BeSUnJqi4=; b=ON5/CulGQnW+fotNtIVp1tOPxYn2UFVASwz9YmVDRW+m77mqaZLXt1Uzsgcq2M6dDt Z1W3Xo3UsHwXIV4+s7e8zNDRM+sp0ie6nwTZEaYkUuWi9y53pIbGk5HosaFNhKreMMml tj/5/P9o3Nl4HJwQagBDk6d1Z/PaCV2iISLRUR489/581KJojHRj9QwhVxVqtiMxw39A nQOuYnerJxq40y84tOxsThh1gqmkzbc0gaiFjxKYzCQAk2QHpnUxGEtTi6Ow/a2fvaJE La3PXmpHdaCOjAPkJWIsiheQJ9UzGpl8gGFAqdzS9C+qpo9WyNu61i1z8HRZus1rFgU+ QzPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713085413; x=1713690213; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZCcoY6VoTKYNEQSasf4wKT3BWMHcnZ87+4BeSUnJqi4=; b=BdYkiP8lUq8I25wXYokuuopqVKVZNpHRUdFRIx/T75TbbOvdBdO+Rm/uzI+Md9sHSI 219hMrSXdvS/DLGqK/I6SYT0ipPZd/a9LeR8QF4e/7wRjAd76gyglOIft3i7jKrw/d2B sjOsaSLSE4Ed2k4UidRJBJ9MlP5Dx9Yi37sGVhAuLUiI5Nzye0hwFhTVllkifSCpng6o ituOR60esf94ZDQwFb8LQfR1sOCuA6AUWQZfW2imWJPYkcmbcjL0vhDIiSbanP3raitr wMcI4OAL6KG9zvyIfzb0vAELVY7QJ9PuEsXeosnYMTa7fNXx68gdt38xJFhqlW0dF7JD q5vA==
X-Forwarded-Encrypted: i=1; AJvYcCVKxAdpuErymkcAL5hKpjoaA8cjwUQqVl+ig39KgR5KTsEFGGjECkirnLcz5ss8z5iib5Nb3nFlQ1DUzVg9RZtDuiadJKXKOnzZdgarMBVjhTTCb6vu6gQKkCOYLYo/DvR0krnb3Gb9BL1UDvmq3O25d9DVYr1J2wcJqdEP
X-Gm-Message-State: AOJu0YyFLYf2Dblc4wssk/Rc7A8xPE8i0x7tOSd52dWHd+FZjOUn95qe gayknW2GJC7ERqLz016a2seFEWHcUOTb1kPg/IanWI7gCe+7fKYF/dT4UULuJ8VRrP27m2yqZsq uZhkDO0g6xG5/75cvJBmmSe58IbgdiFYFI08=
X-Google-Smtp-Source: AGHT+IFkERE0BOhRS3si/YKBiuoW6AgwfpOr6hcBic6SVsOm7x/TTEV26jAsoVVgI+2PhE6uzocEvzSXr3SCt6z6/0A=
X-Received: by 2002:a81:8349:0:b0:615:1f78:465a with SMTP id t70-20020a818349000000b006151f78465amr6182352ywf.20.1713085413277; Sun, 14 Apr 2024 02:03:33 -0700 (PDT)
MIME-Version: 1.0
References: <171294228645.36819.2486980913632249384@ietfa.amsl.com>
In-Reply-To: <171294228645.36819.2486980913632249384@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 14 Apr 2024 11:03:22 +0200
Message-ID: <CA+RyBmVr96atALM3p5jAPxux-r-4-Q-OnULuUcQ_dwAAP1=HMg@mail.gmail.com>
To: Joe Clarke <jclarke@cisco.com>
Cc: ops-dir@ietf.org, draft-ietf-mpls-bfd-directed.all@ietf.org, last-call@ietf.org, mpls@ietf.org
Content-Type: multipart/mixed; boundary="0000000000008836c406160ac7a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/NeYuNlH-gTv5jduJVHtdTKoMqd0>
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-mpls-bfd-directed-27
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Apr 2024 09:03:39 -0000
Hi Joe, thank you for your thoughtful comments and suggestions. Please find my notes below tagged by GIM>>. Also, attached is the new working version of the draft. Regards, Greg On Fri, Apr 12, 2024 at 7:18 PM Joe Clarke via Datatracker <noreply@ietf.org> wrote: > 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. > GIM>> Added. > > 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". GIM>> Thank you for the suggestion. In most instances, it is a remote LSR that is the actor processing MPLS echo request. Updated as you've suggested. But on one occasion I changed to "egress BFD peer" as follows: OLD TEXT: the egress LSR MUST transition to transmitting periodic BFD Control messages as defined in Section 7 [RFC5884]. NEW TEXT: the egress BFD peer MUST transition to transmitting periodic BFD Control messages as defined in Section 7 [RFC5884]. In Section 5, > you mix in "ingress BFD node". I would suggest consistent terminology. I > like > peer and peer LSR also works for me. GIM>> Found two occurences and applied update, as you suggested. > > 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. > GIM>> Thank you for your consideration and the advice. As the text explains operation with MPLS Echo Request messages to bootstrap controlled BFD sessions, I've labeled nodes A and H as ingress and egress LSR peers respectively. Now, the text is as follows: In the network presented in Figure 2, ingress LSR peer A monitors two tunnels to the egress LSR peer H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap a BFD session to monitor the first tunnel, the ingress LSR peer A MUST include a BFD Discriminator TLV with Discriminator value (e.g., foobar-1) and MAY include a BFD Reverse Path TLV that references H-G-D-C-B-A tunnel. To bootstrap a BFD session to monitor the second tunnel, ingress LSR peer A, MUST include a BFD Discriminator TLV with a different Discriminator value (e.g., foobar- 2) [RFC7726] and MAY include a BFD Reverse Path TLV that references H-G-F-E-B-A tunnel. C---------D | | A-------B G-----H | | E---------F Figure 2: Use Case for BFD Reverse Path TLV If an operator needs egress LSR peer H to monitor a path to the ingress LSR peer A, e.g., H-G-D-C-B-A tunnel, then by looking up the list of known Reverse Paths, it MAY find and use the existing BFD session. > > 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? > GIM>> That, in my opinion, is the formative question; thank you for that. It is assumed that the operator controls the network to which the Reverse PAth Control TLV is applied. If theat is the case, the failure of the installed reverse path is a case of the network failure. The operator, I assume that from the ingress BFD peer, is notified, and then can switch the reverse path of the BFD session. I imagine, that there could be other switchover policies, but I believe that it is essential that the ingress BFD peer detects the network failure if the reverse path of the BFD session fails. WDYT?
- [Last-Call] Opsdir last call review of draft-ietf… Joe Clarke via Datatracker
- Re: [Last-Call] Opsdir last call review of draft-… Greg Mirsky
- Re: [Last-Call] Opsdir last call review of draft-… Joe Clarke (jclarke)
- Re: [Last-Call] Opsdir last call review of draft-… Greg Mirsky
- Re: [Last-Call] Opsdir last call review of draft-… Greg Mirsky
- Re: [Last-Call] Opsdir last call review of draft-… Joe Clarke (jclarke)
- Re: [Last-Call] Opsdir last call review of draft-… Greg Mirsky