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

[Jeffrey Haas <[e-mail]>]

Jim,

On Sat, Oct 15, 2022 at 12:27:33PM +0000, UTTARO, JAMES wrote:
> From: Jeffrey Haas <[e-mail]> 
> 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
> 
> [Jim U>] Maybe old school but widely used ( At least at A&T ).. EVPN is
> different as state is disseminated via the control plane.. To what degree
> that matters is based on use case i.e PW or VPLS and TBH I am working
> through how LLGR should be applied for this technology. BGP 3107 was also
> a candidate when the NHs were disseminated via a RR, but at this time we
> do not use an RR. Also currently under consideration is VPNV4 service.

Thanks for your consideration as one of the authors.  As you're probably
aware, vendors that implement this feature have applied it to a number of
address families as an option.  Since VPLS was explicitly mentioned, it
seemed wise to extend comment to EVPN.

> 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.
> 
> [Jim U>] Agreed.

Excellent.  Hopefully we can expect this to be updated in a revision soon.

> 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
> 
> [Jim U>] Agreed

Also excellent.

> 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.
> 
> [Jim U>] My reading of this is nice to have but not necessary. 

Once the draft authors have come to some consensus here, we'll consider the
fate of that document.  Thanks.

> 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.
> 
> [Jim U>] Agreed.
> 
> 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".
> 
> [Jim U>] No. If we do then what about setting it below the keepalive/holdtime values ? 

That's the joy of edge cases.

The value zero is explicitly mentioned because it's something one would look
for as part of review for impacts on an implementation.  Operationally, what
I think we're both highlighting is that even though the behavior is perhaps
clear when the value of this timer is low, it's not worth doing unless
you're going to put a _useful_ value in there.

Perhaps consult with your co-authors and determine if you want to mention
this detail or remain silent on it.

> IANA Considerations:
> Current assignments in IANA currently point to draft-uttaro.  Please add text to request updates to this document.
> 
> [Jim U>] Not sure what that means but yes.

The IANA registry for each of the code points currently points to the old
draft.  You will want some text updating the registry allocations to point
to the current text and RFC-to-be.

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

Same for this!

-- Jeff