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

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

@ -59,7 +59,7 @@
</address> </address>
</author> </author>
<author fullname="Dave Ward" initials="D." surname="Ward"> <author fullname="Serpil Bayraktar" initials="S." surname="Bayraktar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
@ -69,7 +69,7 @@
<code>95134</code> <code>95134</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>dward@cisco.com</email> <email>serpil@cisco.com</email>
</address> </address>
</author> </author>
@ -128,18 +128,18 @@
<t>One common operational need is to add or remove one or more <t>One common operational need is to add or remove one or more
communities to the current set. Another common need is to replace communities to the current set. Another common need is to replace
all received communities with a new set as defined by policy. All all received communities with a new set as defined by policy. All
BGP policy implementations we know of provide a "set community" BGP policy implementations we know of provide syntax to "set" a
directive that operators use to mean "remove any/all communities community that operators use to mean "remove any/all
present on the update received from the neighbor, and apply this communities present on the update received from the neighbor, and
set of communities instead."</t> apply this set of communities instead."</t>
</section> </section>
<section anchor="diffs" title="Community Manipulation Policy Differences"> <section anchor="diffs" title="Community Manipulation Policy Differences">
<t>Vendor implementations differ in the treatment of certain <t>Vendor implementations differ in the treatment of certain
Well-Known communities when modified using the "set community" Well-Known communities when modified using the syntax to "set" the
directive. Some replace all communities including the Well-Known community. Some replace all communities including the Well-Known
ones with the new set, while others replace all non-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 Communities but do not modify any Well-Known Communities that are
present.</t> present.</t>
@ -152,7 +152,7 @@
<section anchor="impls" title="Documentation of Vendor Implementations"> <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> 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
@ -171,10 +171,28 @@
<postamble>Communities not removed by Cisco IOS/XR</postamble> <postamble>Communities not removed by Cisco IOS/XR</postamble>
</texttable> </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 (with a tweezers) by explicit policy; for example, "delete time (with a tweezers) by explicit policy; for example, "delete
community accept-own". Operators are advised to consult IOS-XR community accept-own". Operators are advised to consult IOS-XR
documentation and/or Cisco Systems support for full details.</t> 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>
@ -196,8 +214,8 @@
inclusion in this document, especially if their behavior differs inclusion in this document, especially if their behavior differs
from the examples described.</t> from the examples described.</t>
<t>Vendors MUST NOT create additional communities that the "set <t>Vendors MUST NOT create additional communities that the command
community" directive would not modify.</t> to "set" the community would not modify.</t>
</section> </section>
@ -223,6 +241,14 @@
<references title="Normative References"> <references title="Normative References">
<?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1997"?> <?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> </references>
</back> </back>