[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-decraene-idr-reserved-extended-communities) 00 01 02 03 04 05 06 07 08 09

Network Working Group                                        B. Decraene
Internet-Draft                                   France Telecom - Orange
Intended status: Standards Track                             P. Francois
Expires: August 11, 2011                                             UCL
                                                       February 07, 2011


                   Reserved BGP extended communities
            draft-ietf-idr-reserved-extended-communities-00

Abstract

   This document assigns two BGP extended community types, one
   transitive and one non-transitive.  It also defines two IANA
   registries in order to allow the allocation of reserved transitive
   and non-transitive extended communities.  These are similar to the
   existing reserved (formerly Well-known) BGP communities defined in
   RFC 1997 but provides an easier control of inter-AS community
   advertisement as a community could be chosen as transitive or non-
   transitive across ASes.

Requirements Language

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 11, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Decraene & Francois      Expires August 11, 2011                [Page 1]


Internet-Draft        Reserved extended communities        February 2011


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


1.  Introduction

   [RFC1997] defines the BGP community attribute and some BGP Well known
   communities whose meaning SHALL be understood by all compliant
   implementations.  New reserved communities can be registered in the
   IANA "BGP Well-known Communities" registry but it can't be assumed
   anymore that they will be known by all BGP implementations.
   Implementations or BGP policies which recognize them will behave as
   specified.  Implementation which do not recognize those new reserved
   communities will propagate them from BGP neighbor to BGP neighbor and
   from AS to AS with an unlimited scope.

   There is currently no agreed way to reserve a non transitive well
   known community:

   o  [RFC1997] defines BGP Well-known communities with no structure to
      set their transitiveness across ASes.  Without structure, non
      transitive communities can only be filtered by explicitly
      enumerating all community values that will be denied or allowed to
      BGP speakers in neighboring ASes.  This is not satisfactory as
      this would require upgrading all border routers to understand this
      community before its first usage.

   o  [RFC4360] defines the BGP extended community attribute with a
      structure including a type and a transitive bit "T".  The
      transitive bit, when set, allows to restrict the scope of the
      community within an AS.  But their is no IANA registry to allocate
      a (single) well known extended community.  RFC 4360 [RFC4360]
      defines IANA registries to allocate BGP Extended Communities
      types.  Each type is able to encode 2^48 or 2^56 values depending
      on the type being extended or regular.  Therefore, one needing to
      reserve a single non-transitive extended community would need to
      reserve an extended subtype which represents 2^48 communities,
      while a single value is used.  This would both waste the resources
      and disable the ability to define global policies on reserved
      communities, such as to filter them out.




Decraene & Francois      Expires August 11, 2011                [Page 2]


Internet-Draft        Reserved extended communities        February 2011


   To address this limitation, this document assigns two BGP extended
   community types, one transitive and one non-transitive.  It also
   defines two IANA registries in order to allow the allocation of
   reserved transitive and non-transitive extended communities.  These
   are similar to the existing Well-known BGP communities defined in RFC
   1997 but provides a control on inter-AS community advertisement as a
   community could be chosen as transitive or non-transitive across
   ASes.


2.  IANA Considerations

   IANA is requested to assign, from the registry "BGP Extended
   Communities Type - extended, transitive type", a type value TBD for
   "BGP Reserved transitive extended communities":

    Registry Name: BGP Extended Communities Type - extended, transitive

       Name                                           Type Value
       ----                                           ----------
       BGP Reserved transitive extended communities   TBD (e.g. 0x9000)



   IANA is requested to assign, from the registry "BGP Extended
   Communities Type - extended, non-transitive", a type value TBD for
   "BGP Reserved non-transitive extended communities":

 Registry Name: BGP Extended Communities Type - extended, non-transitive

    Name                                               Type Value
    ----                                               ----------
    BGP Reserved non-transitive extended communities   TBD (e.g. 0xd000)


   Note to the IANA: suggested value for the two reserved BGP Extended
   Communities extended type are 0x9000 and 0xd000.  Otherwise, both
   values should be identical, except for their T - Transitive bit (bit
   1 as defined in [RFC4360]).



   The IANA is requested to create and maintain a registry entitled "BGP
   Reserved transitive extended communities":







Decraene & Francois      Expires August 11, 2011                [Page 3]


Internet-Draft        Reserved extended communities        February 2011


 Registry Name: BGP Reserved transitive extended communities

    Range                         Registration Procedures
    ---------------------------   -------------------------
    0x000000000000-FFFFFFFEFFFF   Reserved
    0xFFFFFFFF0000-00FFFFFF8000   First Come First Served
    0x00FFFFFF8001-FFFFFFFFFFFF   Standards Action/Early IANA Allocation



   The IANA is requested to create and maintain a registry entitled "BGP
   Reserved non-transitive extended communities":


 Registry Name: BGP Reserved non-transitive extended communities

    Range                         Registration Procedures
    ---------------------------   -------------------------
    0x000000000000-FFFFFFFEFFFF   Reserved
    0xFFFFFFFF0000-00FFFFFF8000   First Come First Served
    0x00FFFFFF8001-FFFFFFFFFFFF   Standards Action/Early IANA Allocation


   An application may need both a transitive and non-transitive reserved
   community.  It may be beneficial to have the same value for both
   communities.  (Note that both extended community will still be
   different as they will differ from their T bit).  The IANA SHOULD try
   to accommodate such request to have both a transitive and non-
   transitive reserved community with the same value for both.


3.  Security Considerations

   This document defines IANA actions.  In itself, it has no impact on
   the security of the BGP protocol.


4.  Normative References

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

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.




Decraene & Francois      Expires August 11, 2011                [Page 4]


Internet-Draft        Reserved extended communities        February 2011


   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.


Authors' Addresses

   Bruno Decraene
   France Telecom - Orange
   38-40 rue du General Leclerc
   Issy Moulineaux cedex 9  92794
   France

   Email: bruno.decraene@orange-ftgroup.com


   Pierre Francois
   UCL
   Place Ste Barbe, 2
   Louvain-la-Neuve  1348
   BE

   Email: francois@info.ucl.ac.be




























Decraene & Francois      Expires August 11, 2011                [Page 5]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/