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.htmlhttps://www.ietf.org/mail-archive/web/idr/current/msg16902.htmlhttps://www.ietf.org/mail-archive/web/idr/current/msg16888.htmlhttps://www.ietf.org/mail-archive/web/idr/current/msg16887.htmlhttps://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