draft-ietf-grow-wkc-behavior-01.txt | draft-ietf-grow-wkc-behavior-02.txt | |||
---|---|---|---|---|
Network Working Group J. Borkenhagen | Network Working Group J. Borkenhagen | |||
Internet-Draft AT&T | Internet-Draft AT&T | |||
Intended status: Standards Track R. Bush | Intended status: Standards Track R. Bush | |||
Expires: July 11, 2019 Internet Initiative Japan | Expires: July 26, 2019 Internet Initiative Japan | |||
R. Bonica | R. Bonica | |||
Juniper Networks | Juniper Networks | |||
S. Bayraktar | S. Bayraktar | |||
Cisco Systems | Cisco Systems | |||
January 7, 2019 | January 22, 2019 | |||
Well-Known Community Policy Behavior | Well-Known Community Policy Behavior | |||
draft-ietf-grow-wkc-behavior-01 | draft-ietf-grow-wkc-behavior-02 | |||
Abstract | Abstract | |||
Well-Known BGP Communities are manipulated inconsistently by current | Well-Known BGP Communities are manipulated inconsistently by current | |||
implementations. This results in difficulties for operators. | implementations. This results in difficulties for operators. | |||
Network operators are encouraged to deploy consistent community | Network operators are encouraged to deploy consistent community | |||
handling across their networks, taking the inconsistent behaviors | handling across their networks, taking the inconsistent behaviors | |||
from the various bgp implementations they operate into consideration. | from the various bgp implementations they operate into consideration. | |||
Also, bgp implementors are expected to not create any further | Also, bgp implementors are expected to not create any further | |||
inconsistencies from this point forward. | inconsistencies from this point forward. | |||
skipping to change at page 1, line 49 ¶ | skipping to change at page 1, line 49 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 11, 2019. | This Internet-Draft will expire on July 26, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 42 ¶ | skipping to change at page 3, line 42 ¶ | |||
communities when modified using the syntax to "set" the community. | communities when modified using the syntax to "set" the community. | |||
Some replace all communities including the Well-Known ones with the | Some replace all communities including the Well-Known ones with the | |||
new set, while others replace all non-Well-Known Communities but do | new set, while others replace all non-Well-Known Communities but do | |||
not modify any Well-Known Communities that are present. | not modify any Well-Known Communities that are present. | |||
These differences result in what would appear to be identical policy | These differences result in what would appear to be identical policy | |||
configurations having very different results on different platforms. | configurations having very different results on different platforms. | |||
4. Documentation of Vendor Implementations | 4. Documentation of Vendor Implementations | |||
In this section we document the syntax and observed behavior of the | ||||
"set" directive in several popular bgp implementations. | ||||
In Juniper Networks' JunOS, "community set" removes all received | In Juniper Networks' JunOS, "community set" removes all received | |||
communities, Well-Known or otherwise. | communities, Well-Known or otherwise. | |||
In Cisco Systems' IOS-XR, "set community" removes all received | In Cisco Systems' IOS-XR, "set community" removes all received | |||
communities except for the following: | communities except for the following: | |||
+-------------+-----------------------------------+ | +-------------+-----------------------------------+ | |||
| Numeric | Common Name | | | Numeric | Common Name | | |||
+-------------+-----------------------------------+ | +-------------+-----------------------------------+ | |||
| 0:0 | internet | | | 0:0 | internet | | |||
skipping to change at page 5, line 10 ¶ | skipping to change at page 5, line 10 ¶ | |||
Care should be taken when establishing new [RFC1997]-like attributes | Care should be taken when establishing new [RFC1997]-like attributes | |||
(large communities, wide communities, etc) to avoid repeating this | (large communities, wide communities, etc) to avoid repeating this | |||
mistake. | mistake. | |||
6. Action Items | 6. Action Items | |||
Unfortunately, it would be operationally disruptive for vendors to | Unfortunately, it would be operationally disruptive for vendors to | |||
change their current implementations. | change their current implementations. | |||
Vendors SHOULD share the behavior of their implementations for | Vendors SHOULD clearly document the behavior of "set" directive in | |||
inclusion in this document, especially if their behavior differs from | their implementations. | |||
the examples described. | ||||
Vendors MUST ensure that any well-known communities specified after | Vendors MUST ensure that any Well-Known Communities specified after | |||
this document's publication are removed by the "community set" | this document's publication are removed by their "set" directive. | |||
action. | ||||
Given the implementation inconsistencies described in this document, | Given the implementation inconsistencies described in this document, | |||
network operators are urged never to rely on any implicit | network operators are urged never to rely on any implicit | |||
understanding of a neighbor ASN's bgp community handling. I.e., | understanding of a neighbor ASN's bgp community handling. I.e., | |||
before announcing prefixes with NO_EXPORT or any other community to a | before announcing prefixes with NO_EXPORT or any other community to a | |||
neighbor ASN, the operator should confirm with that neighbor how the | neighbor ASN, the operator should confirm with that neighbor how the | |||
community will be treated. | community will be treated. | |||
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. | ||||
7. Security Considerations | 7. Security Considerations | |||
Surprising defaults and/or undocumented behaviors are not good for | Surprising defaults and/or undocumented behaviors are not good for | |||
security. This document attempts to remedy that. | security. This document attempts to remedy that. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This document has no IANA Considerations other than to be aware that | This document has no IANA Considerations other than to be aware that | |||
any future Well-Known Communities will be subject to the policy | any future Well-Known Communities will be subject to the policy | |||
treatment described here. | treatment described here. | |||
9. Acknowledgements | 9. Acknowledgements | |||
The authors thank Martijn Schmidt for his contribution, Qin Wu for | The authors thank Martijn Schmidt, Qin Wu for the Huawei data point, | |||
the Huawei data point. | Job Snijders, David Farmer,John Heasley, and Jakob Heitz. | |||
10. Normative References | 10. Normative References | |||
[IANA-WKS] | [IANA-WKS] | |||
"IANA Well-Known Comunities", | "IANA Well-Known Comunities", | |||
<https://www.iana.org/assignments/bgp-well-known- | <https://www.iana.org/assignments/bgp-well-known- | |||
communities/bgp-well-known-communities.xhtml>. | communities/bgp-well-known-communities.xhtml>. | |||
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities | [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities | |||
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, | Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, | |||
End of changes. 9 change blocks. | ||||
12 lines changed or deleted | 18 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |