Re: [Idr] Paul Wouters' Discuss on draft-ietf-idr-long-lived-gr-06: (with DISCUSS)

[John Scudder <[e-mail]>]

Hi Paul,

I see Amanda has already answered the second part of your DISCUSS (thanks, Amanda).

Regarding whether the spec should update RFC 4724, I remember considering it during the development of the spec, and deciding not to. As we both know, the semantics of Updates: are sadly underspecified. My own understanding of it is, does an implementor who implements only the older spec, need to know about the newer spec? If that’s the test, then this spec doesn’t update 4724, because the language you quoted only applies if the newer spec is in play:

                        If such a reset occurs for a session for
   which the LLGR Capability has also been exchanged, the following
   procedures apply.

But it’s still perfectly viable to implement GR without implementing LLGR, and an implementor doing so doesn’t need to be bothered about this spec.

If you have a different understanding of Updates: that would motivate adding it to this document, let me know your reasoning and I’m happy to consider adding it. (And then maybe we can collaborate on a doomed-from-the-start draft to define semantics for Updates:, or to deprecate it and introduce a new header with defined semantics.)

Thanks,

—John

> On Aug 9, 2023, at 10:31 PM, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-idr-long-lived-gr-06: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DE8jLuGugzU3n_eDoAOLWjFdWaUhbNPGdnOVXoriExGg6W61ChtNqCShoupgFsMirkywKPKjKP-8$
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-long-lived-gr/__;!!NEt6yMaO-gk!DE8jLuGugzU3n_eDoAOLWjFdWaUhbNPGdnOVXoriExGg6W61ChtNqCShoupgFsMirkywKAfFA8_z$
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> These two DISCUSSes should be easy to resolve :)
> 
> 
>        The following text in Section 4.2 of the GR specification [RFC4724] no longer applies:
>        [...]
>        and the following procedures are specified instead:
>        [...]
> 
> Shouldn't this be indicated with an Updates: 4724 clause ?
> 
> 
> 
> The well-known BGP community "LLGR_STALE" and "NO_LLGR" used by this document
> are listed in the IANA registry as defined by draft-uttaro-idr-bgp-persistence
> which expired in 2019.  If this is an early allocation, this value might vanish
> from the registry ? I'm not sure what the exact process would be to ensure those
> values remain in the registry and that these can be safely used by this document.
> 
> Then in the IANA Considerations, it claims _this_ document is adding these entries
> to the IANA Registry?
>        This document introduces a new BGP well-known community
>        "LLGR_STALE" for marking long-lived stale routes, and another
>        well-known community "NO_LLGR" to mark routes that should not
>        be retained if stale.
> 
> So I guess that removes my concern by these entries expiring. I am assuming that this
> document taking over these entries is okay, I just wanted to confirm that with the
> responsible AD, the IETF Secretariat and IANA :-)
> 
> 
> 
> 
>