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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 May 2019 17:16:13 -0400

John,

On Mon, Apr 29, 2019 at 09:24:20PM +0000, John Scudder wrote:
> I’ll add with my co-chair hat off and individual contributor hat on, to my way of thinking I would always choose FCFS over IETF Review, because it provides all the same benefits with less overhead. I guess you can argue that an “IETF Review” code point does benefit from the eponymous IETF Review, but practically speaking since we are at the point where WGLC has been completed and we’re virtually ready to advance the document, the review applied in either case will be exactly the same. So, if implementors are ready to go, they can have a code point before the end of the week with FCFS, whereas it will be longer than that if we do IETF Review/Early Allocation.

While I'm generally sympathetic to your point about FCFS being the faster of
the two, we're so close to being out the door on the RFC that IETF Review
with early allocation would be fine.  We might as well use it, or otherwise
just get reclassify it as FCFS as well. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 May 2019 17:22:22 -0400

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.

---

From: Christoph Loibl <[email-masked]>
Date: Sun, 19 May 2019 11:15:57 +0000

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
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 15.05.2019, at 21:22, Jeffrey Haas <[email-masked]> wrote:
> 
> John,
> 
> _______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: John Scudder <[email-masked]>
Date: Mon, 20 May 2019 11:17:30 +0000

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

IETF Review code points are indeed ordinarily assigned when the RFC is shipped. You’re correct this doesn’t work right with our IDR procedures. Jeff has proposed that in this case we simply move ahead with shipping the RFC regardless, if we do so it would cause the code point to be allocated with no further ado.

Otherwise, the workaround is the procedures from RFC 7120, "Early IANA Allocation of Standards Track Code Points”. You can refer to the RFC for the full details of how it works, but the summary of how we do it in IDR is:

1. Someone (typically but not required to be an author) requests early allocation of a code point.
2. Assuming the chairs don’t have some objection (there would be none in this case), the chairs offer the WG a chance to object (typically a two-week consensus call).
3. Assuming there’s support (sometimes in the form of “no objections”) the chairs proceed to request the early allocation. 
4. Before the allocation can be done, the Area Director also has to approve.

As you can see, the process can be expected to take +/- 3 weeks or so, once a request is made.

The First Come, First Served (FCFS) procedure (and much more) is in RFC 8126, "Guidelines for Writing an IANA Considerations Section in RFCs”. You can also see https://www.iana.org/help/protocol-registration for a concise version. The summary is:

1. Someone (typically but not required to be an author) requests allocation of a code point using the IANA form https://www.iana.org/form/protocol-assignment
2. There is no step 2. That’s all. IANA typically turns the request around in one working day or so.

As I mentioned earlier the registry in question has FCFS and IETF Review ranges, so any of the three solutions above can work (but for the first solution to work, we’d have to waive the normal WG process).

Regards,

—John

---

From: John Scudder <[email-masked]>
Date: Tue, 28 May 2019 14:21:21 +0000

Hi All,

In considering this further, I find myself sufficiently persuaded by Jeff’s position, in particular the shorter version he offered in a private note: "the level of rigor is perhaps excessive with regard to optional features”. Fair enough, in my opinion as a WG we should continue to be rigorous (ish) with respect to core aspects of a specification, but when it comes to optional features perhaps we can say non-implementation isn't blocking.

To be clear, I think in a perfect world a spec be fully implemented, and if it’s not, we pull out the non-implemented optional parts, put them in a different draft, advance the core spec, and leave the non-implemented parts in draft form until they become implemented. But that loads the authors and the WG with more work, so it may be better to respect the adage that “perfect is the enemy of good enough”. It’s true the WG has advanced plenty of other specs like this in the past (including RFC 4271!), for whatever that’s worth. The proposal is that as long as the non-implemented parts are genuinely optional and don’t impact the core feature or core BGP protocol, we’ll consider it potentially acceptable (though not preferable!) to proceed. 

If there’s any strong objection to advancing the document with this rationale, please follow up by the end of the week, otherwise I’ll go ahead and send the document to the IESG.

Thanks,

—John