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

From: John Scudder <[email-masked]>
Date: Fri, 26 Apr 2019 21:14:39 +0000

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
.
   Possible reasons for an error are (for more reasons see also
   [RFC7606]):

   o  Incorrect implementation of this specification - the encoding/
      decoding of the NLRI or traffic action extended-communities do not
      comply with this specification.

   o  Unknown Flow Specification extensions - The sending party has
      implemented a Flow Specification NLRI extension unknown to the
      receiving party.

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. For reference, here’s section 7.2:

   The traffic-rate-packets extended community uses the same encoding as
   the traffic-rate-bytes extended community.  The floating point value
   carries the maximum packet rate in packets per second.  A traffic-
   rate-packets of 0 should result in all traffic for the particular
   flow to be discarded.  On encoding the traffic-rate-packets MUST NOT
   be negative.  On decoding negative values MUST be treated as zero
   (discard all traffic).

   Interferes with: No other BGP Flow Specification traffic action in
   this document.

Note, the traffic-rate-packets code point is from the Generic Transitive Experimental Use Extended Community Sub-Types registry, which has a FCFS range available. So all that is needed in order to get a code point is for someone (perhaps one of the authors) to ask IANA for one.

Unless there is strong support in the WG to waive the WG's implementation requirement for these two items, we’ll hold for implementation. (Another option would be to revise the draft to remove the non-implemented items, but we should only do that if there’s indication nobody intends to implement them. At present I don’t see reason to believe that.)

Thanks,

—John

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 29 Apr 2019 15:05:36 -0400

John:
<wg chair hat off >
<co-author hat on> 
On the second point, please note that the registry has two types:  FCFS and IETF Review.   I believe the authors believed it was being allocated out of the IETF Review portion.  

As a co-author, I believe that the implementations assumed the IETF Review code space.   Therefore, I humbly suggest that the implementation status is correct. 

My recollection is that the WG suggested IETF Review space to keep it clear.   I ask that you do a specific call on this point.   

Sue Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Friday, April 26, 2019 5:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] Update on advancement of rfc5575bis draft, implementations

Hi All,

Thanks,

—John
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: John Scudder <[email-masked]>
Date: Mon, 29 Apr 2019 21:24:20 +0000

Fair enough — dear WG, if there are strong opinions about whether the code point should be allocated out of one space or the other (Sue is correct of course that there are two spaces), please send them. This is independent of whether you think we should (or shouldn’t) hold for implementation. If the WG wants to use IETF Review space, and doesn’t want to waive the implementation requirement, then that implies we should do an early allocation request. If that’s what the WG and/or authors prefer, that’s OK too, please let me know in that case so we can kick it off.

I did do a short search of my IDR mbox and past meeting minutes and didn’t find past discussion of what space to use, but of course I might have missed it. In any case, it’s fine to ask again.

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.

When I’ve been involved in setting up registries, my reasons for separating them into FCFS/IETF Review ranges has been that the IETF Review process provides a check on the danger of unrestrained allocation. But experience has shown there hasn’t been a practical problem with rampant code point consumption, and in retrospect the same purpose would have been served by dividing the range into FCFS and Reserved, except the latter approach wouldn’t lead to uncertainty about which range to allocate from.

Anyway, I have no dogmatic need for the allocation to be done one way or the other, just trying to suggest the most expeditious.

Thanks,

—John

> On Apr 29, 2019, at 3:05 PM, Susan Hares <[email-masked]> wrote:
> 
> John:
> <wg chair hat off >
> <co-author hat on> 
> I’ve just finished reviewing the document shepherd’s writeup (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Drfc5575bis_shepherdwriteup_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=TfRYwH5AB5aZxgKUrGRlASwDCwcvZ4RuJwXJk6STCFE&s=vr9enODIMN9OFaSrOpbCJHnEy-2sgKxoZ3S7SlVbloY&e=) and Implementation report (https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_idr_wiki_draft-2Dietf-2Drfc5575bis-2520implementations&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=TfRYwH5AB5aZxgKUrGRlASwDCwcvZ4RuJwXJk6STCFE&s=7kddWh2C8Bl_7SH4Q3yZYoNsyDJb-KZV6mmNcxy3FY4&e=) 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.
> 
> ..
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=TfRYwH5AB5aZxgKUrGRlASwDCwcvZ4RuJwXJk6STCFE&s=WpSEE7nr6jCue0idIvKhSMSDmiTF2tejOy9pqR3i21I&e=
>