more nits
This commit is contained in:
parent
9b8094e8ec
commit
234e820abd
1 changed files with 40 additions and 30 deletions
|
|
@ -77,14 +77,14 @@
|
|||
|
||||
<abstract>
|
||||
|
||||
<t>Well-Known BGP Communities are manipulated inconsistently by
|
||||
current implementations. This results in difficulties for
|
||||
<t>Well-Known BGP Communities are manipulated differently across
|
||||
various current implementations. This results in difficulties for
|
||||
operators. Network operators are encouraged to deploy consistent
|
||||
community handling across their networks, taking the inconsistent
|
||||
behaviors from the various BGP implementations they operate into
|
||||
consideration. This document recommends specific action items to
|
||||
limit future inconsistency, namely BGP implementors are expected to
|
||||
not create any further inconsistencies from this point forward.</t>
|
||||
consideration. This document recommends specific actions to limit
|
||||
future inconsistency, namely BGP implementors should not create
|
||||
further inconsistencies from this point forward.</t>
|
||||
|
||||
</abstract>
|
||||
|
||||
|
|
@ -120,8 +120,9 @@
|
|||
to prevent the introduction of additional divergence in
|
||||
implementations.</t>
|
||||
|
||||
<t>This document recommends specific action items to limit future
|
||||
inconsistency.</t>
|
||||
<t>This document recommends specific actions to limit future
|
||||
inconsistency, namely BGP implementors MUST NOT create further
|
||||
inconsistencies from this point forward.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -134,7 +135,7 @@
|
|||
policy."</t>
|
||||
|
||||
<t>One basic operational need is to add or remove one or more
|
||||
communities to the received set. The focus of this document is
|
||||
communities to the set. The focus of this document is
|
||||
another common operational need, to replace all communities with a
|
||||
new set. To simplify this second case, most BGP policy
|
||||
implementations provide syntax to "set" community that operators use
|
||||
|
|
@ -144,7 +145,7 @@
|
|||
<t>Some operators 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
|
||||
attempt to replace all 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"
|
||||
|
|
@ -173,11 +174,11 @@
|
|||
<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 OS, "community set" removes all received
|
||||
<t>In Juniper Networks' Junos OS, "community set" removes all
|
||||
communities, Well-Known or otherwise.</t>
|
||||
|
||||
<t>In Cisco Systems' IOS XR, "set community" removes all received
|
||||
communities except for the following:</t>
|
||||
<t>In Cisco Systems' IOS XR, "set community" removes all communities
|
||||
except for the following:</t>
|
||||
|
||||
<texttable anchor="cisco">
|
||||
<preamble></preamble>
|
||||
|
|
@ -192,16 +193,17 @@
|
|||
<postamble>Communities not removed by Cisco IOS XR</postamble>
|
||||
</texttable>
|
||||
|
||||
<t>IOS XR does allow Well-Known communities to be removed by
|
||||
explicitly enumerating each one, not in the aggregate; for example,
|
||||
"delete community accept-own". Operators are advised to consult IOS
|
||||
XR documentation and/or Cisco Systems support for full details.</t>
|
||||
<t>IOS XR does allow Well-Known communities to be removed only by
|
||||
explicitly enumerating one at a time, not in the aggregate; for
|
||||
example, "delete community accept-own". Operators are advised to
|
||||
consult IOS XR documentation and/or Cisco Systems support for full
|
||||
details.</t>
|
||||
|
||||
<t>On Extreme networks' Brocade NetIron: "set community X" removes
|
||||
all communities and sets X.</t>
|
||||
|
||||
<t>In Huawei's VRP product, "community set" removes all received
|
||||
communities, well-Known or otherwise.</t>
|
||||
<t>In Huawei's VRP product, "community set" removes all communities,
|
||||
Well-Known or otherwise.</t>
|
||||
|
||||
<t>In OpenBSD's OpenBGPD, "set community" does not remove any
|
||||
communities, Well-Known or otherwise.</t>
|
||||
|
|
@ -214,14 +216,14 @@
|
|||
<section anchor="ianalist" title="Note on an Inconsistency">
|
||||
|
||||
<t>The IANA publishes a list of Well-Known Communities <xref
|
||||
target="IANA-WKS"/>.</t>
|
||||
target="IANA-WKC"/>.</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
|
||||
<t>IOS XR's set of Well-Known communities that "set community"
|
||||
will not overwrite diverges from the 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
|
||||
|
|
@ -235,12 +237,18 @@
|
|||
|
||||
<t>Care should be taken when establishing new <xref
|
||||
target="RFC1997"/>-like attributes (large communities, wide
|
||||
communities, etc) to avoid repeating this mistake.</t>
|
||||
communities, etc.), RFCs MUST make clear how the new community
|
||||
attribute is to to be handled, avoiding repeating
|
||||
inconsistencies.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="actions" title="Action Items">
|
||||
|
||||
<t>Network operators are encouraged to limit their use of the "set"
|
||||
directive (within reason), to improve consistency across
|
||||
platforms.</t>
|
||||
|
||||
<t>Unfortunately, it would be operationally disruptive for vendors
|
||||
to change their current implementations.</t>
|
||||
|
||||
|
|
@ -278,7 +286,9 @@
|
|||
|
||||
<section anchor="iana" title="IANA Considerations">
|
||||
|
||||
<t>This document has no IANA Considerations.</t>
|
||||
<t>This document has no IANA Considerations; though the IANA may wish
|
||||
to refer to this document, if/when published, in <xref
|
||||
target="IANA-WKC"/>.</t>
|
||||
|
||||
<!--
|
||||
<t>Note to RFC Editor: this section may be replaced on publication
|
||||
|
|
@ -301,10 +311,10 @@
|
|||
<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">
|
||||
<reference anchor="IANA-WKC" target="https://www.iana.org/assignments/bgp-well-known-communities">
|
||||
<front>
|
||||
<title>IANA Well-Known Communities</title>
|
||||
<author/>
|
||||
<title>Border Gateway Protocol (BGP) Well-Known Communities</title>
|
||||
<author><organization>IANA</organization></author>
|
||||
<date/>
|
||||
</front>
|
||||
</reference>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue