Network Working Group Bruno Decraene Internet-Draft France Telecom Intended status: Standards Track Laurent Vanbever Expires: April 22, 2010 Universite catholique de Louvain Pierre Francois Universite catholique de Louvain October 19, 2009 RFC 4360 Clarification Request draft-decraene-idr-rfc4360-clarification-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Bruno Decraene, et al. Expires April 22, 2010 [Page 1] Internet-Draft RFC 4360 Clarification Request October 2009 Abstract This draft describes a request for clarification of the Operations Section of [RFC4360], regarding the handling of non transitive extended communities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Observed behaviors . . . . . . . . . . . . . . . . . . . . . . 3 4. Suggested clarifications . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 Bruno Decraene, et al. Expires April 22, 2010 [Page 2] Internet-Draft RFC 4360 Clarification Request October 2009 1. Introduction This draft describes a request for clarification of the Operations Section of [RFC4360], regarding the handling of non-transitive extended communities. While interpreting the Section 6 of [RFC4360], an implementation may handle non-transitive extended communities over eBGP sessions in a way preventing neighboring ASes to practically use non-transitive extended communities between each other. Such implementations restrict the benefits of non-transitive communities to internal uses only, which looks unfortunate. Section 2 describes the request for clarification and Section 4 suggests some changes to RFC 4360 that would help in precising desired handling of non-transitive extended communities. Section 3 describes what behavior we observed by running tests on various implementations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Request As of RFC 4360, "If a route has a non-transitive extended community, then before advertising the route across the Autonomous System boundary the community SHOULD be removed from the route." This statement is unclear regarding two aspects of the handling of such non-transitive communities over eBGP sessions. First, it is unclear whether a BGP speaker setting / adding a non- transitive extended community on the outbound policy of an eBGP session is compliant with the RFC 4360 (Clarification A). Second, it is unclear whether a BGP speaker supporting RFC 4360 is allowed to enforce the removal of a non-transitive community in a path received over an eBGP session (Clarification B). 3. Observed behaviors Different behaviors can be observed on recent implementations from different vendors. Some implementations remove any non-transitive extended communities Bruno Decraene, et al. Expires April 22, 2010 [Page 3] Internet-Draft RFC 4360 Clarification Request October 2009 from paths received over eBGP sessions, hence disallowing applications of non-transitive extended communities over eBGP sessions. Other implementations ignore non-transitivity and propagate non- transitive communities over eBGP sessions, hence not applying the "SHOULD be removed" in Section 6 of [RFC4360]. While all these behaviors are compliant with RFC 4360, they limit the benefits of non-transitive communities to internal uses. 4. Suggested clarifications The suggested clarification for (Clarification A) is to let RFC 4360 specify that all routes received carrying an extended communities attribute containing a non-transitive community SHOULD have this(these) non-transitive community(ies) removed before advertising the route to another Autonomous System (i.e. on an eBGP session). Note that this behavior and wording is in-lined with the definition of the NO_EXPORT well known community in [RFC1997]. It allows the advertisement of a non-transitive extended community over an eBGP session if this community is added on the outbound policy of an eBGP session. The suggested clarification for (Clarification B) is to let RFC 4360 specify that a BGP speaker supporting RFC 4360 SHOULD NOT silently enforce the removal of a non-transitive attribute received over an eBGP session, but SHOULD allow this community to be captured by a configured inbound filter associated with eBGP sessions. This behaviour MAY be made configurable but the default SHOULD be to implement the suggested clarifications defined above in this section. 5. References [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bruno Decraene, et al. Expires April 22, 2010 [Page 4] Internet-Draft RFC 4360 Clarification Request October 2009 Authors' Addresses Bruno Decraene France Telecom 38-40 rue du General Leclerc 92794 Issi Moulineaux cedex 9 FR Email: bruno.decraene@orange-ftgroup.com Laurent Vanbever Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE Email: laurent.vanbever@uclouvain.be URI: http://inl.info.ucl.ac.be/lvanbeve Pierre Francois Universite catholique de Louvain Place Ste Barbe, 2 Louvain-la-Neuve 1348 BE Email: pierre.francois@uclouvain.be URI: http://inl.info.ucl.ac.be/pfr Bruno Decraene, et al. Expires April 22, 2010 [Page 5]