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

Hi,

I fully agree with Jeffrey’s comments.

However, I do not 100% understand the correct process regarding the traffic-rate-packets code-point. If we want to assign it from the IETF review code space do we need to ship the RFC first (if this is the case, I sense a deadlock condition)?

While we are sitting here waiting, Thomas merged my Github pull request (treat-as-withdraw Section 11) into ExaBGP and I am only waiting for a code-point to file another pull request for the traffic-rate-packets action (commiting the source without a proper cp seems to be rather unpopular ;-)   

How can we proceed here?

Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 15.05.2019, at 21:22, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> 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.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>