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

manip section hacked per jay email

Browse source
This commit is contained in:
Randy Bush 2018-06-21 16:11:43 -07:00
parent fb4e1a5921
commit 19785e5d1a
1 changed files with 26 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?> <?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> <?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ymbk-grow-wkc-behavior-02" ipr="trust200902"> <rfc category="std" docName="draft-ymbk-grow-wkc-behavior-03" ipr="trust200902">
<front> <front>
@ -117,23 +117,32 @@
</section> </section>
<section anchor="manip" title="Manipulation of Communities by Policy"> <section anchor="manip" title="Manipulation of Communities by Policy">
<t><xref target="RFC1997"/> says:</t> <t><xref target="RFC1997"/> says:</t>
<t>"A BGP speaker receiving a route with the COMMUNITIES path <t>"A BGP speaker receiving a route with the COMMUNITIES path
attribute may modify this attribute according to the local attribute may modify this attribute according to the local
policy."</t> policy."</t>
<t>One common operational need is to add or remove one or more <t>A basic operational need is to add or remove one or more
communities to the current set. Another common need is to replace communities to the received 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. To simplify the second
BGP policy implementations we know of provide syntax to "set" a case, most BGP policy implementations provide syntax to "set"
community that operators use to mean "remove any/all community that operators use to mean "remove any/all communities
communities present on the update received from the neighbor, and present on the update received from the neighbor, and apply this set
apply this set of communities instead."</t> of communities instead."</t>
</section> <t>Some 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
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>
</section>
<section anchor="diffs" title="Community Manipulation Policy Differences"> <section anchor="diffs" title="Community Manipulation Policy Differences">
@ -182,8 +191,8 @@
<t>In Huawei's VRP product, "community set" removes all received <t>In Huawei's VRP product, "community set" removes all received
communities, well-Known or otherwise.</t> communities, well-Known or otherwise.</t>
<t>In OpenBSD's OpenBGPD, "community set" removes no communities, <t>In OpenBSD's OpenBGPD, "set community" does not remove any
well-Known or otherwise.</t> communities, well-Known or otherwise.</t>
<section anchor="ianalist" title="Note on an Inconsistency"> <section anchor="ianalist" title="Note on an Inconsistency">