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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 2 Dec 2016 04:04:22 +0000

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.

---

From: Ignas Bagdonas <[email-masked]>
Date: Fri, 2 Dec 2016 06:31:12 +0000

Hi Alvaro,

Thank you for your review!

On 02/12/2016 04:04, Alvaro Retana (aretana) wrote:
> 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.
>

Will edit those.

Thank you.

Ignas

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 2 Dec 2016 13:46:50 +0000

On 12/2/16, 1:31 AM, "Ignas Bagdonas" <[email-masked]> wrote:

Ignas:

Hi!

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

Removing and ignoring are obviously different things…  The text above is fine with me, but I would ask: what do the current implementations do?  If they remove (as originally specified), then I would suggest you keep that.

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

Question for you:  do you want the operators to use 0, 65535, and 4294967295 whenever they want (which is what the new text says), OR, do you want them not to use them because they could be used later for a special purpose (which is what the original text seemed to indicate)??

I’m having a hard time with this document “reserving” any value because the number space is not really one where values are assigned (in the typical IANA sense: create a registry, etc. – and I doubt you want to make it that way)…but the contents can be (SHOULD) what is contained in an already existing registry (ASNs) that has distributed control.

Assuming that you would prefer the operators NOT to use 0, 65535, and 4294967295, then here’s my suggestion:

OLD> (Section 2)

   The Global Administrator field is intended to allow different

   Autonomous Systems to define BGP Large Communities without collision.

   This field SHOULD either be one of the reserved values as defined

   below, or an Autonomous System Number (ASN).  If it is a reserved

   value, then the Local Data Parts are as defined by the reserved

   value.  If it is an ASN then the Local Data Parts are to be

   interpreted as defined by the owner of the ASN.

NEW>

   The Global Administrator field is intended to allow different

   Autonomous Systems to define BGP Large Communities without collision.

   This field SHOULD be an Autonomous System Number (ASN).  The use of

   Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT

   RECOMMENDED.

…and then eliminate Section 5…

If you really want operators not to use the Reserved ASNs ever because a special use may be though up later, then use “MUST NOT” above.

Thanks!

Alvaro.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 2 Dec 2016 08:57:08 -0500

> Removing and ignoring are obviously different things…  The text above is fine with me, but I would ask: what do the current implementations do?  If they remove (as originally specified), then I wou…

What do you think would be a good minimal change to clarify? How about changing the word "duplicate" to "redundant"?

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

NEW:
   Duplicate BGP Large Community values MUST NOT be transmitted.  A
   receiving speaker MUST silently remove redundant BGP Large Community
   values from a BGP Large Community attribute.

--John

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 2 Dec 2016 14:01:43 +0000

That works for me too.

On 12/2/16, 8:57 AM, "John G. Scudder" <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 2, 2016, at 8:46 AM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:
Removing and ignoring are obviously different things…  The text above is fine with me, but I would ask: what do the current implementations do?  If they remove (as originally specified), then I would suggest you keep that.

OLD:

NEW:

--John

---

From: Ignas Bagdonas <[email-masked]>
Date: Fri, 2 Dec 2016 14:30:52 +0000

Alvaro,

> community - analogous to applying
>
> Large Community value, and
>
> Removing and ignoring are obviously different things…  The text above 
> is fine with me, but I would ask: what do the current implementations 
> do?  If they remove (as originally specified), then I would suggest 
> you keep that.
>

The implementations that I am familiar with do interpret first instance 
of the community value and do not react (=ignore) any other instances of 
the same community value on the receive side. Whether it is truly first 
instance as it appears on the wire or the first instance of the sorted 
received community is an implementation detail, the outcome is that 
single community value is interpreted only once. Therefore on the 
transmit side there are no duplicate values. This is based on decoding, 
processing, and then encoding the community attribute and not forwarding 
it as a binary object only - I am not aware of any implementation that 
does that. Could anyone familiar with implementations that behave 
differently please speak up?

> > > values.  Section 2 says that the “Global Administrator 
> field…SHOULD either be one of the reserved
>
> Question for you:  do you want the operators to use 0, 65535, and 
> 4294967295 whenever they want (which is what the new text says), OR, 
> do you want them not to use them because they could be used later for 
> a special purpose (which is what the original text seemed to indicate)??
>

Communities - any type, standard, extended, large, wide - for practical 
cases are aligned with AS numbers. As there are reserved AS numbers that 
potentially could be used for some future extensibility functionality, 
in the same way community values equal to those AS numbers are reserved 
for potential future extensibility - it is a mechanism to ensure 
functional parity of the namespaces for AS numbers and community values. 
My personal interpretation of the new text for sections 2 and 5 is that 
reserved values could be present in the global administrator field but 
then in that case local parts have specific, predefined meaning and are 
not used for arbitrary values (that meaning is not defined today 
though). Therefore as AS number values of 0, 65535 and 0xffffffff are 
reserved and should not be used as defined today (this is the key part - 
today), corresponding community values should follow the same procedure.

> I’m having a hard time with this document “reserving” any value 
> because the number space is not really one where values are assigned 
> (in the typical IANA sense: create a registry, etc. – and I doubt you 
> want to make it that way)…but the contents can be (SHOULD) what is 
> contained in an already existing registry (ASNs) that has distributed 
> control.
>
Indeed the intention is not to define a new registry if that can be 
avoided. Community values follow AS number values (technically it is 
just an uint32_t number that has an interpretation of AS number value).

> 4294967295, then here’s my suggestion:
Yes, the intention is exactly that - reserved values should not be used.

> If you really want operators not to use the Reserved ASNs ever because 
> a special use may be though up later, then use “MUST NOT” above.
>

Personally I agree with this text.

Ignas

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Dec 2016 10:30:07 -0500

> On Dec 2, 2016, at 9:30 AM, Ignas Bagdonas <[email-masked]> wrote:
> 
> The implementations that I am familiar with do interpret first instance of the community value and do not react (=ignore) any other instances of the same community value on the receive side. Whether it is truly first instance as it appears on the wire or the first instance of the sorted received community is an implementation detail, the outcome is that single community value is interpreted only once. Therefore on the transmit side there are no duplicate values. This is based on decoding, processing, and then encoding the community attribute and not forwarding it as a binary object only - I am not aware of any implementation that does that. Could anyone familiar with implementations that behave differently please speak up? 

Implementations that tend toward memory conserving typically implement it this way:
- Sort the elements.  (They have set semantics, so order is irrelevant.)
- Remove duplicate entries (redundant as John says)
- Having done the above, check against a data store for a previously existing version.  If it exists, simply bump its refcount.

The above gives the property of "discard redundant on receive".  If a similar canonicalization is done on entries that are to be sent with routes, it also removes duplicates/redundant entries on send.

Modern languages in many cases provide "set" semantics and would similarly give the above properties a bit more automatically.

That said, implementations need neither use modern languages (or mechanisms in those languages) or might not be memory conserving.  Thus, the text recommending removing redundant entries is still a good idea.

-- Jeff

---

From: Michael H Lambert <[email-masked]>
Date: Fri, 2 Dec 2016 10:40:25 -0500

> On 2 Dec 2016, at 08:57, John G. Scudder <[email-masked]> wrote:
> 

Just for clarification:  Does "speaker" in this context refer to a BGP speaker implementing large communities, and, by inference, excludes BGP speakers not supporting large communities?

Thanks,

Michael

---

From: Job Snijders <[email-masked]>
Date: Fri, 2 Dec 2016 16:44:54 +0100

On Fri, Dec 02, 2016 at 10:40:25AM -0500, Michael H Lambert wrote:
> >> Removing and ignoring are obviously different things…  The text
> >> above is fine with me, but I would ask: what do the current
> >> implementations do?  If they remove (as originally specified), then
> >> I would suggest you keep that.
> > 
> > What do you think would be a good minimal change to clarify? How
> > about changing the word "duplicate" to "redundant"?
> > 
> > OLD:
> Just for clarification:  Does "speaker" in this context refer to a BGP
> speaker implementing large communities, and, by inference, excludes
> BGP speakers not supporting large communities?

This only applies to BGP speakers who understand the Large Community. To
speakers without Large Community support, it will just be an optional
transitive attribute which is passed on in verbatim.

Kind regards,

Job

---

From: heasley <[email-masked]>
Date: Fri, 2 Dec 2016 17:14:53 +0000

> I’m having a hard time with this document “reserving” any value because the number space is not really one where values are assigned (in the typical IANA sense: create a registry, etc. – and I doub…

0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by RFC 1997
communities for well-known communities.  It is the intention to use 65535 if
in the future it is desirable to define large well-known communities.  The
other two should not be used because they are invalid ASNs and could lead to
collision.  This all seems prudent to me.

> …and then eliminate Section 5…

no, do not eliminate section 5.

---

From: heasley <[email-masked]>
Date: Fri, 2 Dec 2016 17:17:28 +0000

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

The intent was to indicate to implementers that the field may be of any
value and therefore should not be constrained.  Is it not then normative?
or should that be expressed in another manner?

---

From: Job Snijders <[email-masked]>
Date: Fri, 2 Dec 2016 18:28:28 +0100

On Fri, Dec 02, 2016 at 05:14:53PM +0000, heasley wrote:
> 0 and 4294967295 are reserved ASNs, as is 65535 and 65535 is used by
> RFC 1997 communities for well-known communities.  It is the intention
> to use 65535 if in the future it is desirable to define large
> well-known communities.  The other two should not be used because they
> are invalid ASNs and could lead to collision.  This all seems prudent
> to me.
> 
> > Assuming that you would prefer the operators NOT to use 0, 65535,
> > and 4294967295, then here’s my suggestion:
> > 
> > OLD> (Section 2)
> > 

The text that used to be section 5 is better served through a separate
document I think. Jon Mitchell and myself are working on a document to
assist in that matter. This document is not published yet.

The first sentence of section 5 was moved into the section 2. The second
sentence says what the document is _not_, and a forward looking
statement of what could happen. There is no cost to removing that if we
carry that torch over into a new document. Let me know if you want to
help work on draft-mitchell-idr-large-communities-registry.

Kind regards,

Job

---

From: heasley <[email-masked]>
Date: Fri, 2 Dec 2016 17:34:41 +0000

> assist in that matter. This document is not published yet.

seems silly to spread it across 2 documents.  it is not a complex subject
and its already been expressed that there is no desire to specify any
well-knowns at this time.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Dec 2016 12:37:38 -0500

> On Dec 2, 2016, at 12:14 PM, heasley <[email-masked]> wrote:
> 

As I'd unfortunately learned this year, people still operationalize the use of even regular communities in the low and high value (0/65535) global admins in RFC 1997 communities.

Given the huge push for "parity" with 1997, being too restrictive in this document seems unwise. 

We have two audiences that any cautions need to be made to:
- For developers, if you're not cautious about your wording on reserved values, they keep you from configuring stuff in those ranges.
- For operators, you want to tell them "these values either are not globally unique and have the possibility of collisions, or may run afoul of future compatibility mechanisms for well known communities in rfc 1997 space".

-- Jeff

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 2 Dec 2016 17:43:32 +0000

On 12/2/16, 12:17 PM, "heasley" <[email-masked]> wrote:

Hi!

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

> or should that be expressed in another manner?

In Section 2, where the Large Community is defined, it already says this: “The Global Administrator field…SHOULD be an Autonomous System Number (ASN).”  The “SHOULD” leaves the door open for it to be anything.

The text above, which comes later, is just repeating the fact already covered in Section 2.

Alvaro.

---

From: heasley <[email-masked]>
Date: Fri, 2 Dec 2016 19:28:51 +0000

> The text above, which comes later, is just repeating the fact already covered in Section 2.

ok.  I'd still leave it as it was, but whatever.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 2 Dec 2016 21:23:40 +0000

communities (of any kind) are stored in a table.
Routes that have communities attached just keep a reference to the community.
Suppose three routes are received with the community attributes:
(1:1, 2:2), (2:2, 1:1), (1:1, 1:1, 2:2) respectively.
The system will store only (1:1, 2:2) and the three routes will reference that one community.

Therefore, duplicates are removed and order of transmission is of no significance.

Thanks,
Jakob.

From: Jeffrey Haas [mailto:[email-masked]]
Sent: Friday, December 02, 2016 7:30 AM
To: Ignas Bagdonas <[email-masked]>
Cc: Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-large-community-09

On Dec 2, 2016, at 9:30 AM, Ignas Bagdonas <[email-masked]<mailto:[email-masked]>> wrote:

-- Jeff