idnits 2.17.1 draft-decraene-idr-rfc4360-clarification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC4360]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bruno Decraene 3 Internet-Draft France Telecom 4 Intended status: Standards Track Laurent Vanbever 5 Expires: April 22, 2010 Universite catholique de Louvain 6 Pierre Francois 7 Universite catholique de Louvain 8 October 19, 2009 10 RFC 4360 Clarification Request 11 draft-decraene-idr-rfc4360-clarification-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 22, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This draft describes a request for clarification of the Operations 50 Section of [RFC4360], regarding the handling of non transitive 51 extended communities. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Observed behaviors . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Suggested clarifications . . . . . . . . . . . . . . . . . . . 4 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 This draft describes a request for clarification of the Operations 65 Section of [RFC4360], regarding the handling of non-transitive 66 extended communities. 68 While interpreting the Section 6 of [RFC4360], an implementation may 69 handle non-transitive extended communities over eBGP sessions in a 70 way preventing neighboring ASes to practically use non-transitive 71 extended communities between each other. Such implementations 72 restrict the benefits of non-transitive communities to internal uses 73 only, which looks unfortunate. 75 Section 2 describes the request for clarification and Section 4 76 suggests some changes to RFC 4360 that would help in precising 77 desired handling of non-transitive extended communities. Section 3 78 describes what behavior we observed by running tests on various 79 implementations. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 2. Request 87 As of RFC 4360, "If a route has a non-transitive extended community, 88 then before advertising the route across the Autonomous System 89 boundary the community SHOULD be removed from the route." 91 This statement is unclear regarding two aspects of the handling of 92 such non-transitive communities over eBGP sessions. 94 First, it is unclear whether a BGP speaker setting / adding a non- 95 transitive extended community on the outbound policy of an eBGP 96 session is compliant with the RFC 4360 (Clarification A). 98 Second, it is unclear whether a BGP speaker supporting RFC 4360 is 99 allowed to enforce the removal of a non-transitive community in a 100 path received over an eBGP session (Clarification B). 102 3. Observed behaviors 104 Different behaviors can be observed on recent implementations from 105 different vendors. 107 Some implementations remove any non-transitive extended communities 108 from paths received over eBGP sessions, hence disallowing 109 applications of non-transitive extended communities over eBGP 110 sessions. 112 Other implementations ignore non-transitivity and propagate non- 113 transitive communities over eBGP sessions, hence not applying the 114 "SHOULD be removed" in Section 6 of [RFC4360]. 116 While all these behaviors are compliant with RFC 4360, they limit the 117 benefits of non-transitive communities to internal uses. 119 4. Suggested clarifications 121 The suggested clarification for (Clarification A) is to let RFC 4360 122 specify that all routes received carrying an extended communities 123 attribute containing a non-transitive community SHOULD have 124 this(these) non-transitive community(ies) removed before advertising 125 the route to another Autonomous System (i.e. on an eBGP session). 126 Note that this behavior and wording is in-lined with the definition 127 of the NO_EXPORT well known community in [RFC1997]. It allows the 128 advertisement of a non-transitive extended community over an eBGP 129 session if this community is added on the outbound policy of an eBGP 130 session. 132 The suggested clarification for (Clarification B) is to let RFC 4360 133 specify that a BGP speaker supporting RFC 4360 SHOULD NOT silently 134 enforce the removal of a non-transitive attribute received over an 135 eBGP session, but SHOULD allow this community to be captured by a 136 configured inbound filter associated with eBGP sessions. This 137 behaviour MAY be made configurable but the default SHOULD be to 138 implement the suggested clarifications defined above in this section. 140 5. References 142 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 143 Communities Attribute", RFC 4360, February 2006. 145 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 146 Communities Attribute", RFC 1997, August 1996. 148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 149 Requirement Levels", BCP 14, RFC 2119, March 1997. 151 Authors' Addresses 153 Bruno Decraene 154 France Telecom 155 38-40 rue du General Leclerc 156 92794 Issi Moulineaux cedex 9 157 FR 159 Email: bruno.decraene@orange-ftgroup.com 161 Laurent Vanbever 162 Universite catholique de Louvain 163 Place Ste Barbe, 2 164 Louvain-la-Neuve 1348 165 BE 167 Email: laurent.vanbever@uclouvain.be 168 URI: http://inl.info.ucl.ac.be/lvanbeve 170 Pierre Francois 171 Universite catholique de Louvain 172 Place Ste Barbe, 2 173 Louvain-la-Neuve 1348 174 BE 176 Email: pierre.francois@uclouvain.be 177 URI: http://inl.info.ucl.ac.be/pfr