Skip to main content

Early Review of draft-ietf-idr-wide-bgp-communities-07
review-ietf-idr-wide-bgp-communities-07-opsdir-early-clarke-2022-06-03-00

Request Review of draft-ietf-idr-wide-bgp-communities-06
Requested revision 06 (document currently at 11)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2022-05-31
Requested 2022-04-29
Requested by Keyur Patel
Authors Robert Raszuk , Jeffrey Haas , Andrew Lange, Bruno Decraene , Shane Amante , Paul Jakma
I-D last updated 2022-06-03
Completed reviews Secdir Early review of -07 by Linda Dunbar (diff)
Opsdir Early review of -07 by Joe Clarke (diff)
Rtgdir Early review of -07 by Acee Lindem (diff)
Comments
Please review and provide comments!
Assignment Reviewer Joe Clarke
State Completed
Request Early review on draft-ietf-idr-wide-bgp-communities by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/Cqzz2f1Po0k1azPnIObkSxLkEKU
Reviewed revision 07 (document currently at 11)
Result Has issues
Completed 2022-06-03
review-ietf-idr-wide-bgp-communities-07-opsdir-early-clarke-2022-06-03-00
Sorry for the late review.  I have been tasked to review this document on
behalf of the Ops Directorate.  This document defines a new BGP path attribute
called the BGP Community Container as well as a Wide Community type.  That
said, it is not immediately clear from the abstract what this document really
does.  It isn't until Section 2 where it becomes clearer.

While I appreciate Section 7 on operational considerations, it struck me that
the statement, "in supporting both standard and BGP Wide Communities, allow for
their easy inbound and outbound processing" was not terribly instructive. 
Perhaps an example of what the authors would consider "easy" in this case would
be useful.

Some more comments below:

Section 4.4.2

s/a list of a Atoms/a list of Atoms/

In the paragraph, "When no exclude targets are required..." does this assume
that an empty Exclude Targets TLV is to be ignored?  The paragraph states that
implementations must be able to accept this, but does not make it clear what to
do in that case once it is accepted.

While I think you answer this in a later section, is there a need to have a
"match none" as well to correspond to the Targets TLV "match all" behavior?  My
final read of the document says no, but I wanted to be thorough.

===

Section 4.4.3

s/a list of a Atoms/a list of Atoms/

s/too many or two few/too many or too few/

I have the same comment here as in Section 4.4.2.  If the parameters are empty
how exactly should the receiving router behave?  Why not just make these a
strong MUST NOT encode if they are empty to remove any ambiguity?

===

Section 5

s/Contaners/Containers/

s/removed by BGP Speaker/removed by BGP Speakers/

===

Section 5.1

Is the 0xFFFFFFFF AS Atom value the same as leaving off a Targets TLV?

===

Section 5.2

The last sentence should use the same normative language as in Section 5 (i.e.,
SHALL be considered malformed)

===

Section 9.2

s/AS_PATH prepend 4 TIMES TO/AS_PATH prepend 4 times/

Not _sure_ this is correct, but I couldn't quite grok the sentence as written.