BGP Large Communities Attribute
draft-ietf-idr-large-community-12

[Ballot comment]
Of course we shall approve this document and make it an RFC!

Thanks for the work.

However, I do agree with Robert Spark's Gen-ART comments re: the first sentence of the Security Considerations section. I'd either remove the sentence, add pointers to other RFCs with actual security implications content, or reformulate to ".... has similar security properties as RFC 1997 (even if those were not documented in that RFC)".

[Ballot comment]
Thanks John for an excellent shepherd writeup.

I see from the abstract: "The attribute is suitable for use with four-octet ASNs."
I also see this text, which doesn't mention four-octet ASNs

  The Global Administrator field is intended to allow different
  Autonomous Systems to define BGP Large Communities without collision.
  This field SHOULD be an Autonomous System Number (ASN), in which case
  the Local Data Parts are to be interpreted as defined by the owner of
  the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295
  [RFC7300]) is NOT RECOMMENDED.

What if the ASN is two bytes, we use padding? How?
Even if we would say: "This field SHOULD be an four-octet Autonomous System Number (ASN)", it doesn't preclude inserting a two-octet ASN in the Global Administrator field.
Isn't it better to specify how?

From RFC 6793:

  Currently assigned two-octet AS numbers are converted into four-octet
  AS numbers by setting the two high-order octets of the four-octet
  field to zero.  Such a four-octet AS number is said to be mappable to
  a two-octet AS number.

===============================
After some discussion on the idr list.

My reasoning has been:
    either you mention that two-octet ASN can be represented in four-octets (RFC6793)
    or you mention: suitable for all ASNs (2 or 4)
It's so obvious to you guys in your community.

Ok, it seems that we're going in circle here.
You guys understood my issue. It was DISCUSSed. I believe the draft should be clearer, but this is not DISCUSS-level point any longer.
Moving to a COMMENT, and trusting the responsible shepherd and AD.

For the record, John's proposal solveds my issue.

    OLD:
      The attribute is suitable for use with four-octet
      Autonomous System Numbers

    NEW:
      The attribute is suitable for use with all Autonomous System Numbers including four-octet
      Autonomous System Numbers

[Ballot comment]
Thanks John for an excellent shepherd writeup.

I see from the abstract: "The attribute is suitable for use with four-octet ASNs."
I also see this text, which doesn't mention four-octet ASNs

  The Global Administrator field is intended to allow different
  Autonomous Systems to define BGP Large Communities without collision.
  This field SHOULD be an Autonomous System Number (ASN), in which case
  the Local Data Parts are to be interpreted as defined by the owner of
  the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295
  [RFC7300]) is NOT RECOMMENDED.

What if the ASN is two bytes, we use padding? How?
Even if we would say: "This field SHOULD be an four-octet Autonomous System Number (ASN)", it doesn't preclude inserting a two-octet ASN in the Global Administrator field.
Isn't it better to specify how?

From RFC 6793:

  Currently assigned two-octet AS numbers are converted into four-octet
  AS numbers by setting the two high-order octets of the four-octet
  field to zero.  Such a four-octet AS number is said to be mappable to
  a two-octet AS number.

===============================
After some discussion on the idr list.

My reasoning has been:
    either you mention that two-octet ASN can be represented in four-octets (RFC6793)
    or you mention: suitable for all ASNs (2 or 4)
It's so obvious to you guys in your community.

Ok, it seems that we're going in circle here.
You guys understood my issue. It was DISCUSSed. I believe the draft should be clearer, but this is not DISCUSS-level point any longer.
Moving to a COMMENT, and trusting the responsible shepherd and AD.

For the record, John's proposal solved the issue.

    OLD:
      The attribute is suitable for use with four-octet
      Autonomous System Numbers

    NEW:
      The attribute is suitable for use with all Autonomous System Numbers including four-octet
      Autonomous System Numbers

[Ballot comment]
The first sentence of section 6 seems to delegate at least some security considerations to RFC 1997. That RFC's  security considerations entirely comprises the statement that the RFC does not discuss security. (This would have been a DISCUSS, but I gather from discussion of the genart review that the authors intend to remove the sentence.)

[Ballot comment]
The first sentence of section 6 seems to delegate at least some security considerations to RFC 1997. That RFC's  security considerations entirely comprises the statement that the RFC does not discuss security. (This would have been a DISCUSS, but I gather from discussion of the genart review, the authors intend to remove the sentence.)

[Ballot discuss]
I see from the abstract: "The attribute is suitable for use with four-octet ASNs."
I also see this text, which doesn't mention four-octet ASNs

  The Global Administrator field is intended to allow different
  Autonomous Systems to define BGP Large Communities without collision.
  This field SHOULD be an Autonomous System Number (ASN), in which case
  the Local Data Parts are to be interpreted as defined by the owner of
  the ASN.  The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295
  [RFC7300]) is NOT RECOMMENDED.

What if the ASN is two bytes, we use padding? How?
Even if we would say: "This field SHOULD be an four-octet Autonomous System Number (ASN)", it doesn't preclude inserting a two-octet ASN in the Global Administrator field.
Isn't it better to specify how?

From RFC 6793:

  Currently assigned two-octet AS numbers are converted into four-octet
  AS numbers by setting the two high-order octets of the four-octet
  field to zero.  Such a four-octet AS number is said to be mappable to
  a two-octet AS number.

[Ballot comment]
One question: Since the Global Administrator field could also be not an ASN, would it be useful to say something about what should be done if an unknow value is received (ignore, remove, log an error...)?

[Ballot comment]
One question: Since the Global Administrator field could also be not an ASN, would it be useful to say somethinga bout what should be done if an unknow value is received (ignore, remove, log an error...)?

[Ballot comment]
High-time we did this thanks.

I think the network reviewers suggestion to leave in the implmentation status is a fine one. it does naturally capture only a moment in time.  but since it points to useful examples of implmentation that's good.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-idr-large-community-09.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY) in the "BGP Path Attributes" subregistry under the "Border Gateway Protocol (BGP) Parameters" registry located at:

https://www.iana.org/assignments/bgp-parameters/

We will make that registration permanent and change the reference to [ RFC-to-be ].

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: idr@ietf.org, idr-chairs@ietf.org, jgs@juniper.net, aretana@cisco.com, draft-ietf-idr-large-community@ietf.org, "John Scudder"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGP Large Communities) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'BGP Large Communities'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the BGP Large Communities attribute, an
  extension to BGP-4.  This attribute provides a mechanism to signal
  opaque information within separate namespaces to aid in routing
  management.  The attribute is suitable for use with four-octet
  Autonomous System Numbers.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-idr-large-community-09 ===

I do have some comments (please see below) that I want to see addressed before IESG Evaluation, but I am starting the IETF Last Call and will schedule the document in the next available Telechat.

Thanks!

Alvaro.


C1. Section 2. (BGP Large Communities Attribute) says that “Duplicate BGP Large Community values MUST NOT be transmitted.  A receiving speaker MUST silently remove duplicate BGP Large Community values from a BGP Large Community attribute.”  Given two identical Large Communities, should the receiver remove both, or just one (the duplicate of the first)?  I think the text as written is subject to interpretation.

C2. There seems to be a contradiction in the expected use of reserved Global Administrator values.  Section 2 says that the “Global Administrator field…SHOULD either be one of the reserved values as defined below, or an Autonomous System Number (ASN)”, but later Section 5 says: “The following Global Administrator values are reserved: 0, 65535, and 4294967295.  Operators SHOULD NOT use these Global Administrator values.”  IOW: “SHOULD use one if the reserved values” and “SHOULD NOT use the reserved values” contradict each other.  It seems to me that because 0, 65535, and 4294967295 are already reserved ASNs, *and* that “the Local Data Parts are to be interpreted as defined by the owner of the ASN”, then only assigned ASNs should ever be used --- *and* given that it is not an error to use an value, then there is no real advantage in reserving anything (again!). Suggestion: reference the RFCs where 0, 65535, and 4294967295 are reserved and just say that those numbers SHOULD NOT be used because if a Special Use Large Community is ever defined, those values may be used.

C3. In Section 6: s/Global Administrator field MAY contain any value/Global Administrator field may contain any value    That “MAY” is not normative, it is just expressing a fact.

C4. A Normative reference to RFC4271 should exist; tag it to the first mention of BGP.

C5. RFC1997 and RFC6793 should be Informative.

Document Writeup for Working Group Documents

As required by RFC 4858, this is the current template for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


Proposed Standard. The title page header indicates "Standards Track". This is pretty much self-evidently the right thing.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


  This document describes the Large BGP Communities attribute, an
  extension to BGP-4.  This attribute provides a mechanism to signal
  opaque information within separate namespaces to aid in routing
  management.  The attribute is suitable for use with four-octet ASNs.
 
  This remedies the lack of four-octet ASN support in RFC 1997, which
  has been identified as a problem by the operational community.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


Tl;dr: There is good consensus to move forward with -09 of the draft. Details about points of debate (all of which have been resolved to the level of "rough consensus" with good engagement from the WG) are below.

There was an unusually high level of engagement in the process throughout, and it proceeded both more intensely and more quickly than usual. A few points deserve to be highlighted.

First, there was controversy during the document adoption phase. The functionality provided by the large communities specification represents a subset of the functionality provided by an earlier working group document, draft-ietf-idr-wide-bgp-communities. Some members of the working group, including but not limited to several of the authors of the wide communities document, took the position that it would be better to implement wide communities, or perhaps a restricted profile of wide communities, rather than specifying a semantically similar yet incompatible subset. Ultimately this position did not prevail. The (rough) consensus position was that the wide communities specification was "too complicated", that the operator community had an urgent need for exactly and only the functionality represented in large communities, and that keeping the functionality restricted with no feature creep whatsoever permitted was the best strategy. The document was adopted on this basis, and the topic was not substantially re-litigated during the working group last call.

Second, there was disagreement during the working group last call about the exact specification of the Global Administrator field. For reference, the relevant excerpt from Section 2 of the spec:

  Each BGP Large Community value is encoded as a 12-octet quantity, as
  follows:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Global Administrator                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Local Data Part 1                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Local Data Part 2                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Global Administrator:  A four-octet namespace identifier.
...
  The Global Administrator field is intended to allow different
  Autonomous Systems to define BGP Large Communities without collision.
  This field SHOULD be either one of the reserved values as defined
  below, or an Autonomous System Number (ASN).  If it is a reserved
  value, then the Local Data Parts are as defined by the reserved
  value.  If it is an ASN then the Local Data Parts are to be
  interpreted as defined by the owner of the ASN.
 
The debate, although wide-ranging, can be summarized as being between SHOULD, MUST and MAY in this text.

To summarize the respective arguments:

SHOULD: Although the expectation is that an ASN will be used in this field, as a practical matter there is no way for a router to enforce this restriction. Furthermore, many working group members felt that although use of an Autonomous System number in this position was the best practice, it would be inappropriate for the IETF to try to legislate what value an operator configured. The RFC 2119 definition of "SHOULD" was considered to strike the right balance of almost, but not quite, mandating the practice. There was clear, although not unanimous, consensus for this position. During the course of document development, including during the working group last call, several improvements were suggested and incorporated into the document to try to clarify these nuances.

MUST: If the expectation is an ASN will be used, unless the working group can propose a reasonable exception case,  the document should not falsely imply that operators have the freedom to put anything they like in the first field. The strongest proponent of this point of view was Tom Petch, and his view is summed up in his message https://www.ietf.org/mail-archive/web/idr/current/msg16699.html:

Which in turn is seems to be taking us away from the aim of this work,
as stated recently by John, namely,

"When the working group accepted the draft as a work item, I think it
was pretty clear from the extensive conversation at that time, that the
intent was to replicate RFC 1997, not to improve it. "

The freedom to put anything you feel like putting in the first field is
not replicating RFC 1997, it is a significant (IMHO) change and the
sense I get is that many here want that as an 'improvement'.  For me, it
is a hazard to the Internet, not an improvement (which is why I oppose
it).  I am with Brian on this.

The working group was not convinced that selecting SHOULD rather than MUST constituted a hazard to the Internet.

MAY: This was again a position advanced most strongly (perhaps exclusively) by Tom Petch. https://www.ietf.org/mail-archive/web/idr/current/msg16631.html:

MUST be an ASN works for me, or, paradoxically, MAY be an ASN (since
then it should be obvious the fields cannot be relied on);

I'm not certain MAY was intended as a serious proposal, and the working group didn't follow up on it further. I include it here for completeness.

To round out the contrary view Tom's original message opposing the document is at https://www.ietf.org/mail-archive/web/idr/current/msg16600.html. The arguments are as summarized above. One final point worth observing is that RFC 1997 does use MUST type language (of course it predates RFC 2119) in the analogous portion of the spec:

  The community attribute values ranging from 0x0000000 through
  0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

  The rest of the community attribute values shall be encoded using an
  autonomous system number in the first two octets. 

Thus, the choice made in the large communities specification does indeed diverge from that of RFC 1997. It's worth noting that although RFC 1997 uses prescriptive language, no implementation has ever enforced the restriction.

In the end, the working group considered all these points and came to consensus for the text as presented.

Related, draft-snijders-grow-large-communities-usage, "Usage of Large BGP Communities" is currently being discussed in GROW. It's intended to provide additional clarification and color regarding the usage of the various fields in large communities.

While not a point of controversy, it's also worth noting that the working group spent considerable  time discussing canonical representation. Various revisions of the draft shifted between being completely prescriptive, completely lax, and points in between, before finally settling on the text currently present. The current text represents a compromise deemed acceptable by various operators and implementers, and reflects early implementation and deployment experience.

Finally, one WG member (Robert Raszuk) raised concerns regarding the security properties of the proposal, see https://www.ietf.org/mail-archive/web/idr/current/msg16691.html for example. His proposal was essentially to add an additional field to identify the ASN of the party adding a large community (it's worth noting there was no proposal for how to secure this field against being spoofed). There was ample opportunity for the WG to review these comments and there wasn't any consensus to support them.

After the initial WGLC, we ran a short (one week) second WGLC to confirm normative changes made during the first one (the initial WGLC began with -03 and ended with -07). During the second WGLC a few more changes were requested and the end state was -09, reflected by this report.

The second WGLC also achieved consensus, with a few dissenting comments. These were all amply acknowledged and discussed on-list as part of the process.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


There are numerous existing implementations. They are summarized both in the document (noted for removal before publication as RFC) and in the relevant IDR wiki: https://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-large-community%20implementations

The chairs have solicited several RTG-DIR reviews, three of which have been completed (from Geoff Huston, Mach Chen, and Danny McPherson) and reflected in the current (-09) text.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is John Scudder.
The Responsible Area Director is Alvaro Retana.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.


In addition to other reviews listed elsewhere in this report, the Document Shepherd has reviewed several versions of the draft, including the most recent, and considers it ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?


This is one of the most thoroughly-reviewed documents to have been sent to the IESG by IDR in recent years.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


N/A


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


No concerns with the fitness for the document to be advanced.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


Yes:
https://www.ietf.org/mail-archive/web/idr/current/msg16912.html
https://www.ietf.org/mail-archive/web/idr/current/msg16902.html
https://www.ietf.org/mail-archive/web/idr/current/msg16888.html
https://www.ietf.org/mail-archive/web/idr/current/msg16887.html
https://www.ietf.org/mail-archive/web/idr/current/msg16886.html


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


This was one of the most thoroughly debated documents in a recent IDR history. Although consensus is not unanimous, it is strong and reflects a vigorous and engaged working group process.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


idnits runs clean (with one spurious comment).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.


N/A


(13) Have all references within this document been identified as either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


N/A


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


N/A


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


N/A


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).


The IANA section asks for one code point, already early-allocated, to be made permanent.  The section is clear and correctly written. The document does not require any new registries.

There is some question as to whether it might be prudent to create a registry anyway, to increase the visibility of the "reserved bgp large community values" (section 5) and manage any further proposed extensions. A followup draft has been proposed to do this (forthcoming). In my opinion, the document is complete without creation of this registry, and IMO its creation doesn't need to be blocking on advancement of this document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


N/A


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.


N/A


Internet SocietyAMSHome

Request for posting confirmation emailed to previous authors: "Nick Hilliard" , "Job Snijders" , idr-chairs@ietf.org, "Ignas Bagdonas" , "Keyur Patel" , "Jakob Heitz" , "Adam Simpson"