Subject: [Idr] RTG-DIR REVIEW: draft-ietf-idr-large-community-08

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Nov 2016 09:46:45 -0500

RTG-DIR REVIEW: draft-ietf-idr-large-community-08

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request (as is the case here). The purpose of the 
review is to provide assistance to the Routing ADs. For more information 
about the Routing Directorate, please see 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-idr-large-community-08.txt

Reviewer: Danny McPherson

Review Date: November 14, 2016

Intended Status: Standards Track

Summary:

I have no major concerns with the content of this document and believe 
it is ready for publication.  Some minor comments are provided below, 
although only with the intention to inform the authors, WG, and routing 
ADs during their deliberations with regard to the publication of this 
document.

Comments:

I believe the draft is technically sound and addresses an immediate 
operational need in a pragmatic manner.

Major Issues:

I have no “Major” issues with this I-D, I believe it is ready for 
publication as a Standards Track RFC.

Minor Issues:

S.2: Regarding the change in the -08 version to "MUST NOT" in "Duplicate 
BGP Large Community values MUST NOT be transmitted", I agree with John 
Scudder's November 14th email to the IDR WG on this topic, connecting it 
to RFC 2119 definitions and Postel's law.  I believe MUST NOT is a good 
statement, particularly when considering implications of lazy 
implementations doing things such as including duplicates when creating 
aggregates such as outlined in S.3.  Upon further consideration, to 
Peter Hessler's question on the same mailing list thread, perhaps RFC 
1997 and 4360 communities SHOULD have such a restriction - for the sake 
of global routing system hygiene, at least!

S.3: Regarding an aggregate inheriting all the BGP Large Communities 
from all of the aggregated routes, it would seem to me such an 
instruction may result in unintended operational impacts where regional 
or other intra-AS and routing policy functions based on community are 
promoted to the aggregate and trigger undesirable behavior.  Operators 
should certainly be aware of the potential implications of this in their 
operational environments.

S.7: I believe the reference to S.11 of RFC 7454 is appropriate, 
although upon rereading I am not sure I agree with the advice of that 
BCP.  Specifically, suggesting that communities not be scrubbed on 
ingress (other than to enforce "high order bit" feasibility) leads to 
more unique path attributes that result in systemic effects (e.g., less 
efficient update packing, more memory consumption and unnecessary global 
routing system state, path churn resulting from community changes, 
etc..).  Of course, that's well outside the scope of this document but 
this will certainly have implications related to those practices, as 
well as the default "scrubbing" practices by many operators.

S.8: The editors call for the RFC Editor to remove section 8 
"Implementation Status" before publication.  I believe there is value in 
keeping this section in the document in order to memorialize the current 
implementation and operational status of the proposal, unless the 
intention is to create an external "Implementation Report" associated 
with Large Communities now or at a later time when progression along the 
Standards Track is desired.

S.11: That's a solid list of acknowledgements there, it may be simpler 
to list who didn't contribute :-)

Nits:

None.

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 00:18:29 +0900

Dear Danny,

(snipped some text)

On Mon, Nov 14, 2016 at 09:46:45AM -0500, Danny McPherson wrote:
> it is ready for publication.
> 
> Minor Issues:
> 
> S.2: Regarding the change in the -08 version to "MUST NOT" in
> "Duplicate BGP Large Community values MUST NOT be transmitted", I
> agree with John Scudder's November 14th email to the IDR WG on this
> topic, connecting it to RFC 2119 definitions and Postel's law.  I
> believe MUST NOT is a good statement, particularly when considering
> implications of lazy implementations doing things such as including
> duplicates when creating aggregates such as outlined in S.3.  Upon
> further consideration, to Peter Hessler's question on the same mailing
> list thread, perhaps RFC 1997 and 4360 communities SHOULD have such a
> restriction - for the sake of global routing system hygiene, at least!

I agree rationale. I wish I had learned earlier on in this process more
about some of the nuances between MUST and SHOULD.

To put this in different words: if the paragraphs remains as it was
(like in -07) with the words "SHOULD", implicitly we acknowledge that
there _might_ be a semantic meaning in signalling duplicate communities.

For instance, if community "1:2:3" means "prepend at location X", I'd
never want an abomination implementation to exist in this multiverse
where it would be legal routing policy construct to match "if community
1:2:3 is present _twice_ in the attribute, prepend twice".

By changing the wording to MUST, it becomes clear that the presence of
duplicate Large Community has no intrinsic meaning, and is just the
artifact of a software bug on the sending side. This was the WGs
intention all along because that is how we understand and treat RFC1997
comms too.

The s/SHOULD/MUST/ change does not trigger any software updates for any
of the currently known implementations. However it does (or should) put
Q&A people on higher alert.

> "Implementation Status" before publication.  I believe there is value
> in keeping this section in the document in order to memorialize the
> current implementation and operational status of the proposal, unless
> the intention is to create an external "Implementation Report"
> associated with Large Communities now or at a later time when
> progression along the Standards Track is desired.

I'd rather scrub the document clean before publishing, and in doing so
avoid creating any suggestion for the future readers, years from now,
that the implementation is limited to a subset of software.

Over time, software may start to support large communities or drop
support for large communities.

A more lively overview of implementations is available here:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-community%20implementations
(inside ietf scope) and here http://largebgpcommunities.net/implementations/
(maintained outside ietf scope)

> to list who didn't contribute :-)

Attestation and acknowledgement are important.

Kind regards,

Job

---

From: Sander Steffann <[email-masked]>
Date: Mon, 14 Nov 2016 17:24:10 +0100

Hi Job,

> there _might_ be a semantic meaning in signalling duplicate communities.

I agree that there MUST NOT be semantic meaning in duplicate communities. How about:

"""
Duplicate BGP Large Community values SHOULD NOT be transmitted.  A
receiving speaker SHOULD silently remove duplicate BGP Large
Community values from a BGP Large Community attribute. If a community
value is received multiple times this MUST NOT be treated differently
than a community value that is received only once.
"""

as a middle ground?

Cheers,
Sander

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 14 Nov 2016 13:28:55 -0500

Danny:

Thank you for reviewing this document carefully!

Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Danny McPherson
Sent: Monday, November 14, 2016 9:47 AM
To: [email-masked]; [email-masked]
Subject: [RTG-DIR] RTG-DIR REVIEW: draft-ietf-idr-large-community-08

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request (as is the case here). The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Summary:

I have no major concerns with the content of this document and believe it is ready for publication.  Some minor comments are provided below, although only with the intention to inform the authors, WG, and routing ADs during their deliberations with regard to the publication of this document.

Comments:

I believe the draft is technically sound and addresses an immediate operational need in a pragmatic manner.

Major Issues:

Minor Issues:

Nits:

None.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 15 Nov 2016 13:52:27 +1100

> On 15 Nov. 2016, at 3:24 am, Sander Steffann <[email-masked]> wrote:

I think this test is a good way forward.

Geoff

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 16 Nov 2016 08:17:15 +0900

Geoff and Sander,

> On Nov 15, 2016, at 11:52 AM, Geoff Huston <[email-masked]> wrote:

I got a little confused because the conversation took place in two threads. However, in looking at time stamps I think Sander's proposal quoted above was overtaken by his later, in the other thread:

On Nov 15, 2016, at 8:36 AM, Sander Steffann <[email-masked]> wrote:
> Please count me as neutral on the issue. I'm fine with either wording, 

and so on (this is in the thread "One week extension to WGLC for draft-ietf-idr-large-community"). So, unless Sander says otherwise, I'll suppose his concern from this thread has also been addressed without need for "middle ground" text. I think the case for why the "SHOULD" text is not needed and is (mildly) harmful has been made already, but to summarize for convenience: Since we agree "there MUST NOT be semantic meaning in duplicate communities", there seems no value in leaving the door ajar (with a SHOULD) for such semantically meaningless dups to be transmitted anyway. There also seems no practical value to leaving it ajar for them to be stored on receipt, although as a practical matter there's not going to be a way to detect this in a black-box test as long as the MUST NOT transmit and MUST NOT have semantic meaning parts are honored. The value of MUST discard duplicates is principally in telling the implementor "you don't need to go to any trouble to store dups much less affording them special semantics." 

Geoff, if you feel there is a need for the "middle ground" text quoted above, I would be interested in knowing why. (We could also chat f2f if that's easier for you.) Or if your concerns have also been assuaged, if you could confirm that to the list it would be helpful.

Thanks,

--John