draft-ietf-grow-wkc-behavior-00.txt | draft-ietf-grow-wkc-behavior-01.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: January 19, 2019 Internet Initiative Japan | Expires: July 11, 2019 Internet Initiative Japan | |||
R. Bonica | R. Bonica | |||
Juniper Networks | Juniper Networks | |||
S. Bayraktar | S. Bayraktar | |||
Cisco Systems | Cisco Systems | |||
July 18, 2018 | January 7, 2019 | |||
Well-Known Community Policy Behavior | Well-Known Community Policy Behavior | |||
draft-ietf-grow-wkc-behavior-00 | draft-ietf-grow-wkc-behavior-01 | |||
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. It is | implementations. This results in difficulties for operators. | |||
recommended that removal policies be applied consistently to Well- | Network operators are encouraged to deploy consistent community | |||
Known Communities. | handling across their networks, taking the inconsistent behaviors | |||
from the various bgp implementations they operate into consideration. | ||||
Also, bgp implementors are expected to not create any further | ||||
inconsistencies from this point forward. | ||||
Requirements Language | Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to | |||
be interpreted as described in RFC 2119 [RFC2119] only when they | be interpreted as described in RFC 2119 [RFC2119] only when they | |||
appear in all upper case. They may also appear in lower or mixed | appear in all upper case. They may also appear in lower or mixed | |||
case as English words, without normative meaning. | case as English words, without normative meaning. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 46 ¶ | 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 January 19, 2019. | This Internet-Draft will expire on July 11, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 39 ¶ | skipping to change at page 2, line 39 ¶ | |||
6. Action Items . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. Action Items . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | |||
10. Normative References . . . . . . . . . . . . . . . . . . . . 5 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 5 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1. Introduction | 1. Introduction | |||
The BGP Communities Attribute was specified in [RFC1997] which | The BGP Communities Attribute was specified in [RFC1997] which | |||
introduced the concept of Well-Known Communities. In hindsight, it | introduced the concept of Well-Known Communities. In hindsight, | |||
did not prescribe as fully as it should have how Well-Known | [RFC1997] did not prescribe as fully as it should have how Well-Known | |||
Communities may be manipulated by policies applied by operators. | Communities may be manipulated by policies applied by operators. | |||
Currently, implementations differ in this regard, and these | Currently, implementations differ in this regard, and these | |||
differences can result in inconsistent behaviors that operators find | differences can result in inconsistent behaviors that operators find | |||
difficult to identify and resolve. | difficult to identify and resolve. | |||
This document describes the current behavioral differences in order | This document describes the current behavioral differences in order | |||
to assist operators in generating consistent community-manipulation | to assist operators in generating consistent community-manipulation | |||
policies in a multi-vendor environment, and to prevent the | policies in a multi-vendor environment, and to prevent the | |||
introduction of additional divergence in implementations. | introduction of additional divergence in implementations. | |||
skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 32 ¶ | |||
Operators are advised to consult IOS-XR documentation and/or Cisco | Operators are advised to consult IOS-XR documentation and/or Cisco | |||
Systems support for full details. | Systems support for full details. | |||
On Brocade NetIron: "set community X" removes all communities and | On Brocade NetIron: "set community X" removes all communities and | |||
sets X. | sets X. | |||
In Huawei's VRP product, "community set" removes all received | In Huawei's VRP product, "community set" removes all received | |||
communities, well-Known or otherwise. | communities, well-Known or otherwise. | |||
In OpenBSD's OpenBGPD, "set community" does not remove any | In OpenBSD's OpenBGPD, "set community" does not remove any | |||
communities, well-Known or otherwise. | communities, Well-Known or otherwise. | |||
4.1. Note on an Inconsistency | 4.1. Note on an Inconsistency | |||
The IANA publishes a list of Well-Known Communities [IANA-WKS]. | The IANA publishes a list of Well-Known Communities [IANA-WKS]. | |||
IOS-XR's set of well-known communities that "set community" will not | IOS-XR's set of well-known communities that "set community" will not | |||
overwrite diverges from IANA's list. Quite a few well-known | overwrite diverges from IANA's list. Quite a few well-known | |||
communities from IANA's list do not receive special treatment in IOS- | 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 | 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 | list (internet == 0:0) is not really on IANA's list -- it's taken | |||
skipping to change at page 5, line 14 ¶ | skipping to change at page 5, line 14 ¶ | |||
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 share the behavior of their implementations for | |||
inclusion in this document, especially if their behavior differs from | inclusion in this document, especially if their behavior differs from | |||
the examples described. | the examples described. | |||
For new well-known communities specified (after this draft), vendors | Vendors MUST ensure that any well-known communities specified after | |||
MUST treat "community set" command to mean "remove all other | this document's publication are removed by the "community set" | |||
communities, Well-Known or otherwise." | action. | |||
Given the implementation inconsistencies described in this document, | ||||
network operators are urged never to rely on any implicit | ||||
understanding of a neighbor ASN's bgp community handling. I.e., | ||||
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. | ||||
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 | |||
End of changes. 9 change blocks. | ||||
14 lines changed or deleted | 24 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/ |