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

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:idr-bounces@ietf.org] On Behalf Of John Scudder
Sent: Friday, April 26, 2019 5:15 PM
To: idr@ietf.org
Cc: draft-ietf-idr-rfc5575bis@ietf.org
Subject: [Idr] Update on advancement of rfc5575bis draft, implementations

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
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr