Re: [Idr] Update on advancement of rfc5575bis draft, implementations

[Jeffrey Haas <[e-mail]>]

John,

On Fri, Apr 26, 2019 at 09:14:39PM +0000, John Scudder wrote:
> Tl;dr: rfc5575bis is almost ready to advance but is missing implementation of two features. It also needs a code point, which is available from a FCFS registry, so easily acquired. Unless there’s strong support to waive the WG’s implementation requirement, we’ll hold on advancing it for now. Details below.
> 
> 
> Hi All,
> 
> I’ve just finished reviewing the document shepherd’s writeup (https://datatracker.ietf.org/doc/draft-ietf-idr-rfc5575bis/shepherdwriteup/) and Implementation report (https://trac.ietf.org/trac/idr/wiki/draft-ietf-rfc5575bis%20implementations) for draft-ietf-idr-rfc5575bis-14. I’d like to thank all those who contributed to the very helpful and readable implementation report. I see two issues I want to discuss in the WG.
> 
> First, the implementation report line item for whether the implementation supports "Error-Handling and Future NLRI Extensions” is answered “no” across the board, though the Junos report does note that "As of Junos 19.1, unknown NLRI component types may result in session reset. Work is in progress to conform to 5575-bis behavior”. 
> 
> I would like the WG to discuss whether to wait until we have reports of implementations of the behavior before we progress the document, or whether to progress it without implementation. For reference, what’s being referred to is section 11:
> 
>    In case BGP encounters an error in a Flow Specification UPDATE
>    message it SHOULD treat this message as Treat-as-withdraw according
>    to [RFC7606] Section 2
> .

I'll note that this is SHOULD.  At the moment, neither do.  However, much of
the reason for our work on the -bis was to fix behaviors we knew were
broken.  While pedantically the implementations are compliant (they do not,
even though it's strongly recommended), future implementations and existing
implementations in the future would eventually converge to the desired
behavior, IMO.

> Second, the implementation report line item for "Traffic Rate in Packets” is "pending IANA cp assignment” across the board, with the annotation "note that without the IANA allocation, all implementations cannot comply with this specification”. 
> 
> Again, I would like the WG to decide whether to wait until we have implementation to proceed, or whether to proceed without implementation.

IMO, implementations are free to ignore actions even when supported.  (E.g.
for security reasons.)  The feature is useful and will likely show up in the
near future.

I believe we should ship the RFC with the known compliance points expected
to be resolved in implementations in the (hopefully) near future. [1]

-- Jeff

[1] It's not as if we've never shipping something that had long standing
issues.  There's a reason I tend to bring up discussion about
ATOMIC_AGGREGATE as part of my BGP history lessons.