From af4ccc132c2f9ac3b7e52247667b962335ed5681 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Sun, 19 Aug 2018 10:34:29 -0700 Subject: [PATCH] touchups --- draft-ietf-grow-wkc-behavior.xml | 281 +++++++++++++++++++++++++++++++ 1 file changed, 281 insertions(+) create mode 100644 draft-ietf-grow-wkc-behavior.xml diff --git a/draft-ietf-grow-wkc-behavior.xml b/draft-ietf-grow-wkc-behavior.xml new file mode 100644 index 0000000..51fd4e1 --- /dev/null +++ b/draft-ietf-grow-wkc-behavior.xml @@ -0,0 +1,281 @@ + + + + + + + + + + + + + + + + + + Well-Known Community Policy Behavior + + + AT&T +
+ + 200 Laurel Avenue South + Middletown + NJ + 07748 + United States of America + + jayb@att.com +
+ + + + Internet Initiative Japan +
+ + 5147 Crystal Springs + Bainbridge Island + WA + 98110 + United States of America + + randy@psg.com +
+ + + + Juniper Networks +
+ + 2251 Corporate Park Drive + Herndon + VA + 20171 + US + + rbonica@juniper.net +
+ + + + Cisco Systems +
+ + 170 W. Tasman Drive + San Jose + CA + 95134 + United States of America + + serpil@cisco.com +
+ + + + + + + Well-Known BGP Communities are manipulated inconsistently by + current implementations. This results in difficulties for + operators. It is recommended that removal policies be applied + consistently to Well-Known Communities. + + + + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" + are to be interpreted as described in RFC + 2119 only when they appear in all upper case. They may + also appear in lower or mixed case as English words, without + normative meaning. + + + + + + + +
+ + The BGP Communities Attribute was specified in which introduced the concept of Well-Known + Communities. In hindsight, it did not prescribe as fully as it + should have how Well-Known Communities may be manipulated by + policies applied by operators. Currently, implementations differ in + this regard, and these differences can result in inconsistent + behaviors that operators find difficult to identify and resolve. + + This document describes the current behavioral differences in + order to assist operators in generating consistent + community-manipulation policies in a multi-vendor environment, and + to prevent the introduction of additional divergence in + implementations. + +
+ +
+ + says: + + "A BGP speaker receiving a route with the COMMUNITIES path + attribute may modify this attribute according to the local + policy." + + A basic operational need is to add or remove one or more + communities to the received set. Another common need is to replace + all received communities with a new set. To simplify the second + case, most BGP policy implementations provide syntax to "set" + community that operators use to mean "remove any/all communities + present on the update received from the neighbor, and apply this set + of communities instead." + + 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 + 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. + +
+ +
+ + Vendor implementations differ in the treatment of certain + Well-Known communities when modified using the syntax to "set" the + community. Some replace all communities including the Well-Known + ones with the new set, while others replace all non-Well-Known + Communities but do not modify any Well-Known Communities that are + present. + + These differences result in what would appear to be identical + policy configurations having very different results on different + platforms. + +
+ +
+ + In Juniper Networks' JunOS, "community set" removes all received + communities, Well-Known or otherwise. + + In Cisco Systems' IOS-XR, "set community" removes all received + communities except for the following: + + + + Numeric + Common Name + 0:0 internet + 65535:0 graceful-shutdown + 65535:1 accept-own rfc7611 + 65535:65281 NO_EXPORT + 65535:65282 NO_ADVERTISE + 65535:65283 NO_EXPORT_SUBCONFED (or local-AS) + Communities not removed by Cisco IOS/XR + + + IOS-XR does allow Well-Known communities to be removed one at a + time by explicit policy; for example, "delete community accept-own". + Operators are advised to consult IOS-XR documentation and/or Cisco + Systems support for full details. + + On Brocade NetIron: "set community X" removes all communities and + sets X. + + In Huawei's VRP product, "community set" removes all received + communities, well-Known or otherwise. + + In OpenBSD's OpenBGPD, "set community" does not remove any + communities, well-Known or otherwise. + +
+ + The IANA publishes a list of Well-Known Communities . + + 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 + [0x00000000-0x0000FFFF]. + + This merely notes an inconsistency. It is not a plea to + 'protect' the entire IANA list from "set community." + +
+ +
+ +
+ + Care should be taken when establishing new -like attributes (large communities, wide + communities, etc) to avoid repeating this mistake. + +
+ +
+ + Unfortunately, it would be operationally disruptive for vendors + to change their current implementations. + + Vendors SHOULD share the behavior of their implementations for + inclusion in this document, especially if their behavior differs + from the examples described. + + For new well-known communities specified (after this draft), + vendors MUST treat "community set" command to mean “remove all + other communities, Well-Known or otherwise." + +
+ +
+ + Surprising defaults and/or undocumented behaviors are not good + for security. This document attempts to remedy that. + +
+ +
+ + This document has no IANA Considerations other than to be aware + that any future Well-Known Communities will be subject to the policy + treatment described here. + +
+ +
+ + The authors thank Martijn Schmidt for his contribution, Qin Wu + for the Huawei data point. + +
+ + + + + + + + + + IANA Well-Known Comunities + + + + + + + + + +