diff --git a/draft-ietf-grow-wkc-behavior.xml b/draft-ietf-grow-wkc-behavior.xml index 854cd67..25cbc99 100644 --- a/draft-ietf-grow-wkc-behavior.xml +++ b/draft-ietf-grow-wkc-behavior.xml @@ -77,14 +77,14 @@ - Well-Known BGP Communities are manipulated inconsistently by - current implementations. This results in difficulties for + Well-Known BGP Communities are manipulated differently across + various current implementations. This results in difficulties for operators. Network operators are encouraged to deploy consistent community handling across their networks, taking the inconsistent behaviors from the various BGP implementations they operate into - consideration. This document recommends specific action items to - limit future inconsistency, namely BGP implementors are expected to - not create any further inconsistencies from this point forward. + consideration. This document recommends specific actions to limit + future inconsistency, namely BGP implementors should not create + further inconsistencies from this point forward. @@ -120,8 +120,9 @@ to prevent the introduction of additional divergence in implementations. - This document recommends specific action items to limit future - inconsistency. + This document recommends specific actions to limit future + inconsistency, namely BGP implementors MUST NOT create further + inconsistencies from this point forward. @@ -134,7 +135,7 @@ policy." One basic operational need is to add or remove one or more - communities to the received set. The focus of this document is + communities to the set. The focus of this document is another common operational need, to replace all communities with a new set. To simplify this second case, most BGP policy implementations provide syntax to "set" community that operators use @@ -144,7 +145,7 @@ Some operators prefer to write explicit policy to delete unwanted communities rather than using "set;" i.e. using a "delete community *:*" and then "add community x:y ..." configuration statements in an - attempt to replace all received communities. The same community + attempt to replace all communities. The same community manipulation policy differences described in the following section exist in both "set" and "delete community *:*" syntax. For simplicity, the remainder of this document refers only to the "set" @@ -173,11 +174,11 @@ In this section we document the syntax and observed behavior of the "set" directive in several popular BGP implementations. - In Juniper Networks' Junos OS, "community set" removes all received + In Juniper Networks' Junos OS, "community set" removes all communities, Well-Known or otherwise. - In Cisco Systems' IOS XR, "set community" removes all received - communities except for the following: + In Cisco Systems' IOS XR, "set community" removes all communities + except for the following: @@ -192,16 +193,17 @@ Communities not removed by Cisco IOS XR - IOS XR does allow Well-Known communities to be removed by - explicitly enumerating each one, not in the aggregate; for example, - "delete community accept-own". Operators are advised to consult IOS - XR documentation and/or Cisco Systems support for full details. + IOS XR does allow Well-Known communities to be removed only by + explicitly enumerating one at a time, not in the aggregate; for + example, "delete community accept-own". Operators are advised to + consult IOS XR documentation and/or Cisco Systems support for full + details. On Extreme networks' Brocade NetIron: "set community X" removes all communities and sets X. - In Huawei's VRP product, "community set" removes all received - communities, well-Known or otherwise. + In Huawei's VRP product, "community set" removes all communities, + Well-Known or otherwise. In OpenBSD's OpenBGPD, "set community" does not remove any communities, Well-Known or otherwise. @@ -214,14 +216,14 @@
The IANA publishes a list of Well-Known Communities . + target="IANA-WKC"/>. - IOS XR's set of well-known communities that "set community" - will not overwrite diverges from IANA's list. Quite a few - well-known communities from IANA's list do not receive special - treatment in IOS XR, and at least one specific community on - IOS XR's special treatment list (internet == 0:0) is not really - on IANA's list -- it's taken from the "Reserved" range + IOS XR's set of Well-Known communities that "set community" + will not overwrite diverges from the IANA's list. Quite a few + Well-Known communities from IANA's list do not receive special + treatment in IOS XR, and at least one specific community on IOS + XR's special treatment list (internet == 0:0) is not really on + IANA's list -- it's taken from the "Reserved" range [0x00000000-0x0000FFFF]. This merely notes an inconsistency. It is not a plea to @@ -235,12 +237,18 @@ Care should be taken when establishing new -like attributes (large communities, wide - communities, etc) to avoid repeating this mistake. + communities, etc.), RFCs MUST make clear how the new community + attribute is to to be handled, avoiding repeating + inconsistencies.
+ Network operators are encouraged to limit their use of the "set" + directive (within reason), to improve consistency across + platforms. + Unfortunately, it would be operationally disruptive for vendors to change their current implementations. @@ -278,7 +286,9 @@
- This document has no IANA Considerations. + This document has no IANA Considerations; though the IANA may wish + to refer to this document, if/when published, in .