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

[Ignas Bagdonas <[e-mail]>]

Hi Alvaro,

Thank you for your review!


On 02/12/2016 04:04, Alvaro Retana (aretana) wrote:
>
> 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.
>
The intention is to react on the first instance of the duplicate 
community - analogous to applying RFC7606 to the contents of the large 
community path attribute itself. Would a following text address your 
comment:

A receiving speaker MUST act on the first instance of duplicate BGP 
Large Community value, and MUST silently ignore any other occurrence of 
such duplicated values. Duplicate BGP Large Community values MUST NOT be 
transmitted.

This reverses the receive and transmit handling - ignore any subsequent 
duplicate community values and do not send duplicates. Whether an 
implementation actually removes anything or just ignores is an internal 
matter to the implementation.


> 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.
>
For section 2: Global Administrator field SHOULD be an Autonomous System 
Number (ASN) or one of the reserved values defined in Section 5.

For section 5: Global Administrator values corresponding to reserved use 
Autonomous System Number values of 0 [RFC7607], 65535 [RFC7300], and 
4294967295 [RFC7300] are reserved.

Would this work?

> 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.
>

Will edit those.

Thank you.

Ignas