-03 published

draft-ietf-grow-wkc-behavior.xml

@@ -129,13 +129,13 @@
     attribute may modify this attribute according to the local
     policy."</t>
 
-    <t>A basic operational need is to add or remove one or more
+    <t>One basic operational need is to add or remove one or more
-    communities to the received set.  Another common need is to replace
+    communities to the received set.  The focus of this document is
-    all received communities with a new set.  To simplify the second
+    another common operational need, to replace all communities with a
-    case, most BGP policy implementations provide syntax to "set"
+    new set.  To simplify this second case, most BGP policy
-    community that operators use to mean "remove any/all communities
+    implementations provide syntax to "set" community that operators use
-    present on the update received from the neighbor, and apply this set
+    to mean "remove any/all communities present on the route, and apply
-    of communities instead."</t>
+    this set of communities instead."</t>
 
     <t>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.</t>
+    behaviors, which we refer to collectively as each implementation's
+    '"set" directive.'</t>
 
     </section>
 
@@ -168,10 +169,10 @@
     <t>In this section we document the syntax and observed behavior of
     the "set" directive in several popular BGP implementations.</t>
 
-    <t>In Juniper Networks' JunOS, "community set" removes all received
+    <t>In Juniper Networks' Junos OS, "community set" removes all received
     communities, Well-Known or otherwise.</t>
 
-    <t>In Cisco Systems' IOS-XR, "set community" removes all received
+    <t>In Cisco Systems' IOS XR, "set community" removes all received
     communities except for the following:</t>
 
     <texttable anchor="cisco">
@@ -184,16 +185,16 @@
           <c>65535:65281</c>  <c>NO_EXPORT</c>
           <c>65535:65282</c>  <c>NO_ADVERTISE</c>
           <c>65535:65283</c>  <c>NO_EXPORT_SUBCONFED (or local-AS)</c>
-        <postamble>Communities not removed by Cisco IOS/XR</postamble>
+        <postamble>Communities not removed by Cisco IOS XR</postamble>
       </texttable>
 
-    <t>IOS-XR does allow Well-Known communities to be removed one at a
+    <t>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.</t>
 
-    <t>On Brocade NetIron: "set community X" removes all communities and
+    <t>On Extreme networks' Brocade NetIron: "set community X" removes
-    sets X.</t>
+    all communities and sets X.</t>
 
     <t>In Huawei's VRP product, "community set" removes all received
     communities, well-Known or otherwise.</t>
@@ -201,16 +202,21 @@
     <t>In OpenBSD's OpenBGPD, "set community" does not remove any
     communities, Well-Known or otherwise.</t>
 
+    <t>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.</t>
+
     <section anchor="ianalist" title="Note on an Inconsistency">
 
       <t>The IANA publishes a list of Well-Known Communities <xref
       target="IANA-WKS"/>.</t>
 
-      <t>IOS-XR's set of well-known communities that "set community"
+      <t>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
+      treatment in IOS XR, and at least one specific community on
-      IOS-XR's special treatment list (internet == 0:0) is not really
+      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].</t>
 
@@ -221,8 +227,7 @@
 
     </section>
     
-  <section anchor="note" title="Note for Those Writing RFCs for New
+  <section anchor="note" title="Note for Those Writing RFCs for New Community-Like Attributes"> 
-				Community-Like Attributes"> 
 
     <t>Care should be taken when establishing new <xref
     target="RFC1997"/>-like attributes (large communities, wide
@@ -238,13 +243,17 @@
     <t>Vendors SHOULD clearly document the behavior of "set" directive
     in their implementations.</t>
 
-    <t>Vendors MUST ensure that any Well-Known Communities specified
+    <t>Vendors MUST ensure that their implementations' "set" directive
-    after this document's publication are removed by their "set"
+    treatment of any specific community does not change if/when that
-    directive.</t>
+    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.</t>
 
     <t>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.</t>
@@ -271,10 +280,11 @@
 
     </section>
 
-  <section anchor="acks" title="Acknowledgements">
+  <section anchor="acks" title="Acknowledgments">
 
     <t>The authors thank Martijn Schmidt, Qin Wu for the Huawei data
-    point, Job Snijders, David Farmer,John Heasley, and Jakob Heitz.</t>
+    point, Greg Hankins, Job Snijders, David Farmer, John Heasley, and
+    Jakob Heitz.</t>
     
     </section>
 </middle>
@@ -286,7 +296,7 @@
     <?rfc include="reference.RFC.1997"?>
     <reference anchor="IANA-WKS" target="https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml">
       <front>
-        <title>IANA Well-Known Comunities</title>
+        <title>IANA Well-Known Communities</title>
         <author/>
         <date/>
       </front>