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


.  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].


.  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).


.  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.


.  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.


.  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]