Early Review of draft-ietf-idr-wide-bgp-communities-07
review-ietf-idr-wide-bgp-communities-07-rtgdir-early-lindem-2022-05-16-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-idr-wide-bgp-communities-07 - BGP Community Container Attribute
Reviewer: Acee Lindem
Review Date: 5/16/2022
IETF LC End Date: N/A
Intended Status: Proposed Standard

Summary:

This document defines an extendible framework for future BGP community
definition. It defines a common BGP Community Container attribute header and
TLV encodings for BGP wide communities. The BGP Wide Community definition
is quite flexible and the onus is put on future documents to precisely define
the semantics of specific BGP Wide Communities.

The document is well written - especially given the complex encodings.


I have some minor concerns about this document that I think should be
resolved before publication.


Major Issues: None

Minor Issues:

   1. The definition of local BGP wide communities implies either that operator are using
      their own custom BGP implementations in their domains or that implementations
      provide a set of APIs and/or a powerful BGP Wide Community policy language. Should
      the draft provide some non-normative guidance or at least point this out and state
      that it is out of scope?

   2. It wasn't clear to me why undefined Atoms are ignored and the BGP Wide Community
      is still used. Similarly, undefined parameters result in the BGP Wide Community
      being ignored. I think the draft should explain impetus for the three error actions –
      ignore Atom only, ignore  BGP Wide Community, and treat as malformed.

   3. Should sections 6 and 10.1 include BGP Large Communities where standard and
      extended communities are referenced?

   4. In the example in Section 9, please define what the argument (2-8) means on
      first use. I'm assuming it means the number of AS prepends?

   5. Remove the Change History in section 12.

Nits: See diffs attached to Email. These changes are suggested to both correct some
minor errors and improve readability.

Thanks,
Acee