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

["UTTARO, JAMES" <[e-mail]>]

Comments In-Line

Thanks,
	Jim Uttaro

-----Original Message-----
From: Jeffrey Haas <[e-mail]> 
Sent: Friday, October 14, 2022 1:47 PM
To: [e-mail]
Cc: [e-mail]
Subject: Comments on draft-ietf-idr-long-lived-gr-01

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

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

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.

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

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. 

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 ? 

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