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

[John Scudder <[e-mail]>]

Hi Again,

I think I can cover the rest of these with a single combined reply.

> On Oct 14, 2022, at 1:46 PM, Jeffrey Haas <[e-mail]> wrote:
> 
> 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!)
> 

[Session Resets section moved to other thread]

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

Removed in local copy. If we need this in the future, it can be progressed as a separate spec.

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

It’s only in there as an example so can easily be removed. Done in local copy.

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

Your overall assumption (business as usual) is correct as far as I’m concerned. But in fact, the draft *does* speak directly to that question. Section 5: "The procedures of this document do not alter the route resolvability requirement of [RFC4271] Section 9.1.2.1.. Because of this, it will commonly be the case that "stale" IBGP routes will only continue to be used if the router depicted in the next hop remains resolvable”.

That seems unambiguous to me?

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

The actual answer is in Section 4.2: "If the value of the "Restart Time" or the "Long-lived Stale Time" is zero, the duration of the corresponding period would be zero seconds.” (And it goes on to explain that if LLST = 0 then the procedures of the LLGR spec don’t apply.)

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

Done in local copy.

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

Will do.

Thanks,

—John