[Idr] AD Review of draft-ietf-idr-large-community-09

["Alvaro Retana (aretana)" <[e-mail]>]

Hi!

I just finished reading this document.  Thanks for working on it!

I do have some comments (please see below) that I want to see addressed before IESG Evaluation, but I am starting the IETF Last Call and will schedule the document in the next available Telechat.

Thanks!

Alvaro.


C1. Section 2. (BGP Large Communities Attribute) says that “Duplicate BGP Large Community values MUST NOT be transmitted.  A receiving speaker MUST silently remove duplicate BGP Large Community values from a BGP Large Community attribute.”  Given two identical Large Communities, should the receiver remove both, or just one (the duplicate of the first)?  I think the text as written is subject to interpretation.

C2. There seems to be a contradiction in the expected use of reserved Global Administrator values.  Section 2 says that the “Global Administrator field…SHOULD either be one of the reserved values as defined below, or an Autonomous System Number (ASN)”, but later Section 5 says: “The following Global Administrator values are reserved: 0, 65535, and 4294967295.  Operators SHOULD NOT use these Global Administrator values.”   IOW: “SHOULD use one if the reserved values” and “SHOULD NOT use the reserved values” contradict each other.  It seems to me that because 0, 65535, and 4294967295 are already reserved ASNs, *and* that “the Local Data Parts are to be interpreted as defined by the owner of the ASN”, then only assigned ASNs should ever be used --- *and* given that it is not an error to use an value, then there is no real advantage in reserving anything (again!). Suggestion: reference the RFCs where 0, 65535, and 4294967295 are reserved and just say that those numbers SHOULD NOT be used because if a Special Use Large Community is ever defined, those values may be used.

C3. In Section 6: s/Global Administrator field MAY contain any value/Global Administrator field may contain any value     That “MAY” is not normative, it is just expressing a fact.

C4. A Normative reference to RFC4271 should exist; tag it to the first mention of BGP.

C5. RFC1997 and RFC6793 should be Informative.