[Idr] Comments on draft-ietf-idr-long-lived-gr-01

Jeffrey Haas <jhaas@pfrc.org> Fri, 14 October 2022 17:46 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664B9C1524CB; Fri, 14 Oct 2022 10:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 I-3NqCat403O; Fri, 14 Oct 2022 10:46:56 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4D053C14CE29; Fri, 14 Oct 2022 10:46:55 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 77C3E1E35A; Fri, 14 Oct 2022 13:46:54 -0400 (EDT)
Date: Fri, 14 Oct 2022 13:46:54 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: draft-ietf-idr-long-lived-gr@ietf.org
Cc: idr@ietf.org
Message-ID: <20221014174653.GA30657@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ZzoOFJtHfEhZ3SOsdOyB_tkrhNU>
Subject: [Idr] Comments on draft-ietf-idr-long-lived-gr-01
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2022 17:46:57 -0000

LLGR Authors,

The following was noted while I was reviewing the draft for Working Group
Last Call.  I'd encourage the rest of the Working Group to provide similar
review.

1. Introduction

The introduction calls out technologies such as VPLS.  Consider what text
might be appropriate to highlight the use of this mechanism for EVPN.
(VPLS is old school!)

4.2 Session Resets

:    If a "Long-lived Stale Time" timer is running for a peer, it MUST NOT
:    be updated (other than by manual operator intervention) until the
:    peer has established and synchronized a new session.  The session is
:    termed "synchronized" once the EoR has been received from the peer.

I think "synchronized" may need some work.  It likely isn't necessary to
wait on all expected end-of-ribs to be received from the remote BGP speaker.
Instead, a given AFI/SAFI is synchronized when the end-of-rib has been
received for that AFI/SAFI.

4.5 Multicast VPN

While this discussion might be slightly premature, implementors that are
responding to the WGLC are suggesting they don't have support for this
section.  It is likely that the easiest option to advance this document is
to remove this section.

5.  Deployment Considerations

This section refers to the stale document draft-ietf-idr-bgp-bestpath-selection-criteria.
Please verify that you wish this reference to be maintained, and perhaps
counsel the WG on whether we should push that document to completion.

Misc.:
Keyur points out in off-list discussion that the draft is silent on route
resolvability while the routes are stale.  This may be because the expected
behavior is BGP-normal and that stale routes are expected to obey route
resolution.  I'm unclear if any text is desired to cover this.

Error Handling:

Is it worth calling out any special behavior when Long-lived Stale Time is
zero?  Yes, it's possible that the answer "that's dumb, the behavior is
obvious, don't do that".

IANA Considerations:
Current assignments in IANA currently point to draft-uttaro.  Please add
text to request updates to this document.

The Flags for Address Family currently doesn't have an IANA registry.
Have this added as a new registry similar to "BGP Graceful Restart Flags" in
the BGP Parameters at IANA.

-- Jeff