randy/draft-wkc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

section on xr/iana inconsistency

Browse source
This commit is contained in:
Randy Bush 2018-02-12 08:21:53 +09:00
parent e68cc58c22
commit 05ae8218fa
1 changed files with 41 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

48
draft-ymbk-grow-wkc-behavior.xml
View file

@ -59,7 +59,7 @@
</address>
</author>
<author fullname="Dave Ward" initials="D." surname="Ward">
<author fullname="Serpil Bayraktar" initials="S." surname="Bayraktar">
<organization>Cisco Systems</organization>
<address>
<postal>
@ -69,7 +69,7 @@
<code>95134</code>
<country>United States of America</country>
</postal>
<email>dward@cisco.com</email>
<email>serpil@cisco.com</email>
</address>
</author>
@ -128,18 +128,18 @@
<t>One common operational need is to add or remove one or more
communities to the current set. Another common need is to replace
all received communities with a new set as defined by policy. All
BGP policy implementations we know of provide a "set community"
directive that operators use to mean "remove any/all communities
present on the update received from the neighbor, and apply this
set of communities instead."</t>
BGP policy implementations we know of provide syntax to "set" a
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."</t>
</section>
<section anchor="diffs" title="Community Manipulation Policy Differences">
<t>Vendor implementations differ in the treatment of certain
Well-Known communities when modified using the "set community"
directive. Some replace all communities including the Well-Known
Well-Known communities when modified using the syntax to "set" the
community. Some replace all communities including the Well-Known
ones with the new set, while others replace all non-Well-Known
Communities but do not modify any Well-Known Communities that are
present.</t>
@ -152,7 +152,7 @@
<section anchor="impls" title="Documentation of Vendor Implementations">
<t>In Juniper Networks' JunOS, "set community" removes all received
<t>In Juniper Networks' JunOS, "community set" removes all received
communities, Well-Known or otherwise.</t>
<t>In Cisco Systems' IOS-XR, "set community" removes all received
@ -176,6 +176,24 @@
community accept-own". Operators are advised to consult IOS-XR
documentation and/or Cisco Systems support for full details.</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"
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
[0x00000000-0x0000FFFF].</t>
<t>This merely notes an inconsistency. It is not a plea to
'protect' the entire IANA list from "set community."</t>
</section>
</section>
<section anchor="note" title="Note for Those Writing RFCs for New
@ -196,8 +214,8 @@
inclusion in this document, especially if their behavior differs
from the examples described.</t>
<t>Vendors MUST NOT create additional communities that the "set
community" directive would not modify.</t>
<t>Vendors MUST NOT create additional communities that the command
to "set" the community would not modify.</t>
</section>
@ -223,6 +241,14 @@
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?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>
<author/>
<date/>
</front>
</reference>
</references>
</back>