BGP Communities for Data Collection
draft-ietf-grow-collection-communities-08

New versions were necessary to solve an IANA assignment issue that got discovered after approval. -8 solved this problem and is not significantly different from -6 and should be the basis of rfc publication.

[Ballot discuss]
Not clear if any consideration has been given to how collecting data in these
communities will affect BGP update packaging. If the assumption is that these
will not be used edge-to-edge across the Internet, this should be spelled out
and some guidence should be given.

[Ballot comment]
Reviewed by Michael Patton, Gen-ART



Trivial typos to be fixed in RFC production
-------------------------------------------

Section 2 "referred to coloring" => "referred to as coloring"

Section 3 "RFC 1997 communities encoded as" =>
  "RFC 1997 communities are encoded as"

Section 3 "the providers AS number" => "the provider's AS number"

Section 3 "where  16 bit AS number" =>
  "where  is the 16 bit AS number"

Section 3 " is the encoding of the value" is pretty
  meaningless, I think to be consistent with the earlier text,
  the last word should be "classification".

Section 3.1 "(0x1F2 == 4338 decimal)" => "(0x10F2 == 4338 decimal)"

Section 4 "an Regional Internet Registry" =>
  "a Regional Internet Registry"

Reference [EXTCOMM] is to -06 but that draft is now at -07

[Ballot discuss]
From review by Michael Patton, Gen-ART:

Summary: This draft is on the right track but has open issues, described
in the review.

There are two important comments, followed by lots of typos that I
found.  The first concern needs to be addressed and then get
re-reviewed before the document is acceptable.  Doing something about
the other would be nice, but I'd be willing to let it slide if pushed.
The typos should, of course, be fixed.  Since fixing the main concerns
will require spinning another draft, the typos can be done at the same
time, although they are of the trivial kind that can just be fixed at
RFC final production.


My primary concern is that in Section 3.1 the formats and examples are
inconsistent.  Since this is the crux of the document, I think these
errors make it unacceptable in the current form.  At the end of the
table the notation  is explained, but was never, in fact, used in
the table.  That notation is, however, used in the following diagram.
I think this would read better with the parts in a slightly different
order.  This description also says that  is 5 bits, which is also
what the diagram shows, but the table only has 4 bits, where does the
other bit go?  Then, in the example, "the low order 16 bits" has only
15 bits, and thus the hex encoding would depend on where the missing
bit goes.  Assuming that the binary codes shown in the table should
have one additional leading 0 results in the hex value shown, so I
expect that's what was intended.  Does that mean that the Reserved
values start at 0111111111111111?  There is also a simple numerical
typo in the example, see the typos section.


My other concern is over the amount of detail in the definitions.
Since these are supposed to be used by readers to decide which routes
are which category, it seems that more detail should be provided.  The
fact that the detail is actually deferred to one of the Informative
references concerns me.

[Ballot comment]
>    BGP, and (ii). traffic exchange between A and B is settlement-free.

Defn. of settlement-free?

>    Internal more specific routes are those routes which are frequently

s/more specific/more-specific/

section 2.5. which vs. that

>    Service providers often have settlement free interconnections with an

s/settlement free/settlement-free/

>    this community as 10876:4338 (0x1F2 == 4338 decimal).

s/0x1F2/0x10f2/?

[Ballot discuss]
A one character typo, resolvable with this RFC-Editor's note:

RFC-Editor:

At the top of page 9, please replace

OLD:
  Note that a configuration language might allow the specification of
  this community as 10876:4338 (0x1F2 == 4338 decimal).

to
NEW:
  Note that a configuration language might allow the specification of
  this community as 10876:4338 (0x10F2 == 4338 decimal).

[Ballot comment]
Comment from Pekka Savola from the ops directorate:

However, what this document implicitly aims to do (whether knowingly
or not) is describe a BCP for *internal* communities, not just for
exporting to data collectors.  Who would bother to just munge their
communities to exactly these values just for data collection?

[Ballot comment]
Nit:

In Definitions, "referred to coloring"--> "referred to as coloring"

In 2.1.

  A and B are defined to be peers when (i). A and B exchange routes via
  BGP, and (ii). traffic exchange between A and B is settlement-free.

I found it odd that this section did not define the term "transit".  It is
mentioned in the introduction and touched on 2.9.  As a term of art,
it is hard to discuss "peering" without discussing "transit", since so
many of the operational discussions revolve around when one is used
versus the other. 

I am not suggesting that "transit" should be its own category (the more specific
categories given look fine), but it does seem like it would be useful to
include a definition and possibly indicate which categories fall under that grouping. 

As a purely individual preference, I think it would be interesting to pull anycast
routes out of the other special purpose routes, because I suspect the growth
in that particular special purpose.  But this reflects my own research interest,
and possibly not the best design.

[Ballot comment]
After the table in section 3.1, the legend includes:
  :
  :  is the 5-bit Region
  :
  However,  is not used in the table.  Rather, the possible values of
  are enumerated.  The legend entry should be replaced with an
  explanation.

Comments from Sue Hares:

Two comments:

1) editorial - should fix

Section 3.1 calls out reserved values.
Can these reserved values be used by
a bgp sender or not?  This was unclear.

I think it would be good that these
values are free for assignment.  In any case
this section is generally not clear.

2) security section - 6

The add/delete/drop of the BGP communities
is glossed over with the text:

Section 6:

"While this document introduces no additional security
considerations into the BGP protocol, the information
contained in the communities defined in this document
may in some cases reveal network structure that was not
previously visible outside the provider's
network.  As a result, care should be taken when exporting
such communities to route collectors. "

The point is with add/delete/drop of communities
the bgp speaker can lie, give false information, subvert
the Community coloring of the information. 

Section 6.1

"An operator may choose to overwrite its
internal communities with values specified
in this document."

The rest of the section warns about over-runs of the
maximum packet size 4096.  It does not indicate that
add/delete/drop of information may give erroneous
information to the route collectors.

While the use of the community is still valid, it
should contain a bit stronger warning label.
(yep.. just like smoking use without care may kill
your network.)