[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
- [Idr] Comments on draft-ietf-idr-long-lived-gr-01 Jeffrey Haas
- Re: [Idr] Comments on draft-ietf-idr-long-lived-g… UTTARO, JAMES
- Re: [Idr] Comments on draft-ietf-idr-long-lived-g… Jeffrey Haas
- [Idr] "Synchronized" in LLGR [was: Re: Comments o… John Scudder
- Re: [Idr] Comments on draft-ietf-idr-long-lived-g… John Scudder
- Re: [Idr] Comments on draft-ietf-idr-long-lived-g… Jeffrey Haas
- Re: [Idr] "Synchronized" in LLGR [was: Re: Commen… Jeffrey Haas
- Re: [Idr] "Synchronized" in LLGR [was: Re: Commen… John Scudder
- Re: [Idr] Comments on draft-ietf-idr-long-lived-g… John Scudder
- Re: [Idr] Comments on draft-ietf-idr-long-lived-g… Jeffrey Haas