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

-01 shipped

Browse source
This commit is contained in:
Randy Bush 2019-01-22 16:29:33 -08:00
parent 6878fcdb4f
commit e839e5b644
1 changed files with 16 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

25
draft-ietf-grow-wkc-behavior.xml
View file

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ietf-grow-wkc-behavior-01" ipr="trust200902">
<rfc category="std" docName="draft-ietf-grow-wkc-behavior-02" ipr="trust200902">
<front>
@ -165,6 +165,9 @@
<section anchor="impls" title="Documentation of Vendor Implementations">
<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
communities, Well-Known or otherwise.</t>
@ -232,13 +235,12 @@
<t>Unfortunately, it would be operationally disruptive for vendors
to change their current implementations.</t>
<t>Vendors SHOULD share the behavior of their implementations for
inclusion in this document, especially if their behavior differs
from the examples described.</t>
<t>Vendors SHOULD clearly document the behavior of "set" directive
in their implementations.</t>
<t>Vendors MUST ensure that any well-known communities specified
after this document's publication are removed by the "community set"
action.</t>
<t>Vendors MUST ensure that any Well-Known Communities specified
after this document's publication are removed by their "set"
directive.</t>
<t>Given the implementation inconsistencies described in this
document, network operators are urged never to rely on any implicit
@ -246,6 +248,11 @@
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>
<t>Network operators are encouraged to limit their use of the "set"
directive (within reason), to improve the readability of their
configurations and hopefully to achieve behavioral consistency
across platforms.</t>
</section>
@ -266,8 +273,8 @@
<section anchor="acks" title="Acknowledgements">
<t>The authors thank Martijn Schmidt for his contribution, Qin Wu
for the Huawei data point.</t>
<t>The authors thank Martijn Schmidt, Qin Wu for the Huawei data
point, Job Snijders, David Farmer,John Heasley, and Jakob Heitz.</t>
</section>
</middle>