Shepherd writeup

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

    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

	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.

	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 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 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:
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.


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.


(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?


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


(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.)


(11) Identify any ID nits the Document Shepherd has found in this document. (See 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.


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


(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?


(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.


(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.


(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.


(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.


Internet SocietyAMSHome