commit 6371983bc29eeaf7fa17d0fdbd371e95dc636f86 Author: Randy Bush Date: Sat Feb 10 07:29:44 2018 +0900 posessives diff --git a/draft-ymbk-grow-wkc-behavior.xml b/draft-ymbk-grow-wkc-behavior.xml new file mode 100644 index 0000000..d1685f8 --- /dev/null +++ b/draft-ymbk-grow-wkc-behavior.xml @@ -0,0 +1,230 @@ + + + + + + + + + + + + + + + + + + Well-Known Community Policy Behavior + + + AT&T +
+ + 200 Laurel Avenue South + Middletown + NJ + 07748 + United States of America + + jayb@att.net +
+ + + + Internet Initiative Japan +
+ + 5147 Crystal Springs + Bainbridge Island + WA + 98110 + United States of America + + randy@psg.com +
+ + + + Juniper Networks, Inc. +
+ + 1133 Innovation Way + Sunnyvale + CA + 94089 + US + + jgs@juniper.net +
+ + + + Cisco Systems +
+ + 170 W. Tasman Drive + San Jose + CA + 95134 + United States of America + + dward@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." + + One common operational need is to add or remove one or more + communities to the current set. Another common need is to replace + all received communities with a new set as defined by policy. All + BGP policy implementations we know of provide a "set community" + directive that operators use to mean "remove any/all communities + present on the update received from the neighbor, and apply this + set of communities instead." + +
+ +
+ + Vendor implementations differ in the treatment of certain + Well-Known communities when modified using the "set community" + directive. 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's JunOS, "set community" removes all received + communities, Well-Known or otherwise. + + In Cisco Systems's 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 (with a tweezers) 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. + +
+ +
+ + 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. + + Vendors MUST NOT create additional communities that the "set + community" directive would not modify. + +
+ +
+ + Surprising defaults and/or undocumented behaviors are not good + for security. This document attepts 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. + +
+ + + + + + + + + + + + +