diff --git a/draft-ietf-grow-wkc-behavior.xml b/draft-ietf-grow-wkc-behavior.xml
index 2dd93ec..d52b209 100644
--- a/draft-ietf-grow-wkc-behavior.xml
+++ b/draft-ietf-grow-wkc-behavior.xml
@@ -129,13 +129,13 @@
attribute may modify this attribute according to the local
policy."
- A basic operational need is to add or remove one or more
- communities to the received set. Another common need is to replace
- all received communities with a new set. To simplify the second
- case, most BGP policy implementations provide syntax to "set"
- community that operators use to mean "remove any/all communities
- present on the update received from the neighbor, and apply this set
- of communities instead."
+ One basic operational need is to add or remove one or more
+ communities to the received 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
+ to mean "remove any/all communities present on the route, and apply
+ this set of communities instead."
Some operators prefer to write explicit policy to delete unwanted
communities rather than using "set;" i.e. using a "delete community
@@ -144,7 +144,8 @@
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"
- behaviors.
+ behaviors, which we refer to collectively as each implementation's
+ '"set" directive.'
@@ -168,10 +169,10 @@
In this section we document the syntax and observed behavior of
the "set" directive in several popular BGP implementations.
- In Juniper Networks' JunOS, "community set" removes all received
+ In Juniper Networks' Junos OS, "community set" removes all received
communities, Well-Known or otherwise.
- In Cisco Systems' IOS-XR, "set community" removes all received
+ In Cisco Systems' IOS XR, "set community" removes all received
communities except for the following:
@@ -184,16 +185,16 @@
65535:65281 NO_EXPORT
65535:65282 NO_ADVERTISE
65535:65283 NO_EXPORT_SUBCONFED (or local-AS)
- Communities not removed by Cisco IOS/XR
+ Communities not removed by Cisco IOS XR
- IOS-XR does allow Well-Known communities to be removed one at a
+ IOS XR does allow Well-Known communities to be removed one at a
time by explicit policy; for example, "delete community accept-own".
- Operators are advised to consult IOS-XR documentation and/or Cisco
+ Operators are advised to consult IOS XR documentation and/or Cisco
Systems support for full details.
- On Brocade NetIron: "set community X" removes all communities and
- sets X.
+ 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.
@@ -201,16 +202,21 @@
In OpenBSD's OpenBGPD, "set community" does not remove any
communities, Well-Known or otherwise.
+ Nokia's SR OS has several directives that operate on communities.
+ Its "set" directive is called using the "replace" keyword, replacing
+ all communities, Well-Known or otherwise, with the specified
+ communities.
+
The IANA publishes a list of Well-Known Communities .
- IOS-XR's set of well-known communities that "set community"
+ 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
+ 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].
@@ -221,8 +227,7 @@
-
+
Care should be taken when establishing new -like attributes (large communities, wide
@@ -238,13 +243,17 @@
Vendors SHOULD clearly document the behavior of "set" directive
in their implementations.
- Vendors MUST ensure that any Well-Known Communities specified
- after this document's publication are removed by their "set"
- directive.
+ Vendors MUST ensure that their implementations' "set" directive
+ treatment of any specific community does not change if/when that
+ community becomes a new Well-Known Community through future
+ standardization. For most implementations, this means that the
+ "set" directive MUST continue to remove the community; for those
+ implementations where the "set" directive removes no communities,
+ that behavior MUST continue.
Given the implementation inconsistencies described in this
document, network operators are urged never to rely on any implicit
- understanding of a neighbor ASN's bgp community handling. I.e.,
+ understanding of a neighbor ASN's BGP community handling. I.e.,
before announcing prefixes with NO_EXPORT or any other community to
a neighbor ASN, the operator should confirm with that neighbor how
the community will be treated.
@@ -271,10 +280,11 @@
-
+
The authors thank Martijn Schmidt, Qin Wu for the Huawei data
- point, Job Snijders, David Farmer,John Heasley, and Jakob Heitz.
+ point, Greg Hankins, Job Snijders, David Farmer, John Heasley, and
+ Jakob Heitz.
@@ -286,7 +296,7 @@
- IANA Well-Known Comunities
+ IANA Well-Known Communities