Constrain Attribute announcement within BGP
draft-keyupate-idr-bgp-attribute-announcement-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Keyur Patel  , Jim Uttaro  , Bruno Decraene  , Wim Henderickx 
Last updated 2015-10-18
Stream (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           K. Patel
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                               J. Uttaro
Expires: April 20, 2016                                              ATT
                                                             B. Decraene
                                                                  Orange
                                                           W. Henderickx
                                                          Alcatel Lucent
                                                        October 18, 2015

              Constrain Attribute announcement within BGP
          draft-keyupate-idr-bgp-attribute-announcement-00.txt

Abstract

   [RFC4271] defines four different categories of BGP Path attributes.
   The different Path attribute categories can be identified by the
   attribute flag values.  These flags help identify if an attribute is
   optional or well-known, Transitive or non-Transitive, Partial, or of
   an Extended length type.  BGP attribute announcement depends on
   whether an attribute is a well-known or optional, and whether an
   attribute is a transitive or non-transitive.  BGP implementations
   MUST recognize all well-known attributes.  The well-known attributes
   are always Transitive.  It is not required for BGP implementations to
   recognise all the Optional attributes.  The Optional attributes could
   be Transitive or Non-Transitive.  BGP implementations MUST store and
   forward any Unknown Optional Transitive attributes and ignore and
   drop any Unknown Optional Non-Transitive attributes.

   Currently, there is no way to confine the scope of Path attributes
   within a given Autonomous System (AS) or a given BGP member-AS in
   Confederation.  This draft defines two new attribute categories that
   help confine the scope of Optional attributes within a given AS or a
   given BGP member-AS in Confederation

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

Patel, et al.            Expires April 20, 2016                 [Page 1]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

   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 April 20, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Path Attribute Flags  . . . . . . . . . . . . . . . . . . . .   4
   3.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     5.1.  Acknowledgements  . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Information References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

Patel, et al.            Expires April 20, 2016                 [Page 2]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

1.  Introduction

   [RFC4271] defines four different categories of BGP Path attributes.
   The different Path attribute categories can be identified by the
   attribute flag values.  These flags help identify if an attribute is
   optional or well-known, Transitive or non-Transitive, Partial, or of
   an Extended length type.  BGP attribute announcement depends on
   whether an attribute is a well-known or optional, and whether an
   attribute is a transitive or non-transitive.  BGP implementations
   MUST recognize all well-known attributes.  The well-known attributes
   are always Transitive.  It is not required for BGP implementations to
   recognise all the Optional attributes.  The Optional attributes could
   be Transitive or Non-Transitive.  BGP implementations MUST store and
   forward any Unknown Optional Transitive attributes and ignore and
   drop any Unknown Optional Non-Transitive attributes.

   Optional Transitive attributes help foster partial deployments of
   newer BGP features.  Alternatively, Optional Non-Transitive
   attributes are drop by BGP speakers that do not recognise the
   attribute.  The optional attributes in their current definition do
   not provide any automated attribute level filtering to control the
   scope of announcements within a given AS or a BGP member-AS in
   Confederation.  Scoped announcements of attributes may be needed in
   certain scenarios.  Announcing attributes beyond their intended scope
   MAY result in breakage of functionalities or leaking of any undesired
   information.

   This draft defines new attribute categories that help confine the
   scope of Path attributes; in particular Optional attributes within a
   given Autonomous System or a given BGP member-AS in confederation or
   a given Administrative domain.  Note that "BGP Member-AS in
   Confederation" and "Member-AS" are used entirely interchangeably
   thoughout this document.  The newly defined attribute scoping is
   specifically for newer attributes that explicitly state their use of
   such scoping bits.  These newly defined attributes would be either an
   Optional transitive attributes (recognized and unrecognized) or any
   recognized optional non-transtitive attributes.  For any well-known
   attributes or unrecognized optional non-transtive attributes, the
   standard rules mentioned in [RFC4271]  applies.

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

Patel, et al.            Expires April 20, 2016                 [Page 3]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

2.  Path Attribute Flags

   [RFC4271] defines four type of BGP Path attributes using the
   attribute Flags field.  This draft introduces three more flags fields
   as follows:

    Path Attribute flags:

                0 1 2 3 4 5 6 7
               +-+-+-+-+-+-+-+-+
               |O|T|P|E|A|C| R |   (R = MUST Be Zero)
               +-+-+-+-+-+-+-+-+

               O    Optional or a Well-known as defined in [RFC4271]

               T    Transitive or Non-Transtive as defined in [RFC4271]

               P    Partial as defined in [RFC4271]

               E    Extended Length type as defined in [RFC4271]

               A    AS Wide Scope

               C    Member-AS in Confederation Scope

               M    Multi-AS Scope

   The fifth most significant bit ("A") is defined as the AS Wide Scope
   bit, which is used to indicate that an optional attribute cannot be
   announced outside a given AS boundary.  When set, the given optional
   attribute MUST be filtered by the sending BGP speaker at an AS
   boundary.  If the "A" bit is set then the "O" bit MUST be set.
   Otherwise a BGP speaker MUST consider an attribute as an error and
   malformed.

   The Sixth most significant bit ("C") is defined as the Member-AS
   Scope bit, which is used to indicate that an optional attribute
   cannot be announced outside a given Member-AS boundary.  When set,
   the given optional attribute MUST be filtered by the sending BGP
   speaker at a Member-AS boundary.  If the "C" bit is set then the "O"
   bit MUST be set.  Otherwise a BGP speaker MUST consider an attribute
   as an error and malformed.  "C" bit SHOULD only be set when an
   Autonomous System is configured as a BGP Confederation.  A BGP
   speaker MUST not transmit an attribute with "C" bit set to peers that
   are not members of the local confederation.  Otherwise a BGP speaker
   MUST consider an attribute as an error and malformed.

Patel, et al.            Expires April 20, 2016                 [Page 4]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

   Both the fifth and the sixth most significant bit together is defined
   as the Multiple AS Scope within a Single Administration.  When both
   the fifth and the sixth bits are set, optional attribute can be
   traversed across multiple AS and filtered by the sending BGP speaker
   at the Administration boundary.

   The handling of malformed attributes SHOULD follow the procedures
   mentioned in [RFC7606].  For any malformed attribute that is handled
   by the "attribute discard" instead of the "treat-as-withdraw"
   approach, it is critical to consider the potential impact.  In
   particular, if the attribute has an impact on the route selection or
   installation process, then the presumption is that "attribute
   discard" is unsafe and "treat-as-withdraw" procedure SHOULD be
   considered.  Otherwise, "attribute discard" procedure SHOULD be used.

3.  Operation

   When originating an optional Path attribute, a BGP speaker SHOULD use
   and set AS Wide Scope bit if it wants to restrict the announcement
   within a AS.  Similarly, when originating an optional Path attribute,
   a BGP speaker SHOULD use and set Member-AS Scope bit if it wants to
   restrict the announcement with a Member-AS.  When originating an
   optional Path attribute, a BGP speaker SHOULD use and set both
   Member-AS Scope bit and AS Wide Scope bit if it wants to restrict the
   announcement within a single administration composed of multiple
   ASes.

   When a BGP speaker receives or originates a route that includes an
   optional Path attribute with a AS Wide Scope bit set and a Member-AS
   Scope bit cleared, it MUST remove that Path attribute when announcing
   the route to any of its EBGP speakers.  To deal with partial
   deployments it is suggested that a BGP speaker SHOULD quietly ignore
   and not pass along to other BGP peers any Path attribute received
   from its EBGP peers with a AS Wide Scope bit set and a Member-AS
   Scope bit cleared unless configured explicitly using a policy.

   When a BGP speaker receives or originates a route that includes an
   optional Path attribute with a Member-AS Scope bit set and a AS Wide
   Scope bit cleared, it MUST remove that Path attribute when announcing
   the route to any of its BGP speakers outside its Member-AS.  To deal
   with partial deployments it is suggested that a BGP speaker SHOULD
   quietly ignore and not pass along to other BGP peers any Path
   attribute received from its BGP peers with a Member-AS Scope bit set
   and a AS Wide Scope bit cleared unless configured explicitly as a
   policy.

   When a BGP speaker receives or originates a route with an optional
   path attribute that has both, the AS Wide Scope bit set and the

Patel, et al.            Expires April 20, 2016                 [Page 5]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

   Member-AS Scope bit set, it MUST announce it to all its EBGP peers
   within its administrative domain.  Such an attribute MUST be filtered
   when the attribute is announced outside its admistrative domain.  The
   BGP peering boundaries for an admistrative domain is a matter of a
   policy and is set by the operators.

   Any implementation that supports the extensions defined in this draft
   MUST support the Enhanced Error handling defined in [RFC7606].
   Enhanced Error handling allows any error condition that MAY occur
   during the parsing and processing of new attribute flags to be
   treated according to the procedures of [RFC7606].  Furthermore, it is
   assumed that the BGP network is enabled with Enhanced Error Handling
   feature.  This allows BGP speakers not implementing the draft
   extensions to apply the procedures of [RFC7606].

4.  IANA Considerations

   This draft defines two new Path attribute flags.  We request IANA to
   create a new registry for BGP Path Attribute Flags under BGP Path
   attributes as follows:

   Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP Path
   Attributes Flags" Reference: draft-keyupate-idr-bgp-attribute-
   flags-00 Registration Procedures as follows:

   Bit Value (MSB) Type                       Reference
         1         Optional/Mandatory         RFC4271
         2         Transitive/NonTransitive   RFC4271
         3         Partial                    RFC4271
         4         Extended Length Type       RFC4271
         5         AS Wide Scope              Current Draft
         6         Member-AS in Confederation Current Draft

5.  Security Considerations

   This extension to BGP does not change the underlying security issues
   inherent in the existing [RFC4724] and [RFC4271].

5.1.  Acknowledgements

   The authors would like to thank John Scudder, Jakob Heitz, Shyam
   Seturam, Juan Alcaide and Acee Lindem for the review and comments.

6.  References

Patel, et al.            Expires April 20, 2016                 [Page 6]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <http://www.rfc-editor.org/info/rfc7606>.

6.2.  Information References

   [RFC3392]  Chandra, R. and J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 3392, DOI 10.17487/RFC3392, November
              2002, <http://www.rfc-editor.org/info/rfc3392>.

   [RFC4486]  Chen, E. and V. Gillet, "Subcodes for BGP Cease
              Notification Message", RFC 4486, DOI 10.17487/RFC4486,
              April 2006, <http://www.rfc-editor.org/info/rfc4486>.

   [RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
              Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
              DOI 10.17487/RFC4724, January 2007,
              <http://www.rfc-editor.org/info/rfc4724>.

Authors' Addresses

   Keyur Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: keyupate@cisco.com

Patel, et al.            Expires April 20, 2016                 [Page 7]
Internet-Draft Constrain Attribute announcement within BGP  October 2015

   James Uttaro
   ATT
   200 S. Laurel Ave
   Middletown, NJ  07748
   USA

   Email: uttaro@att.com

   Bruno Decraene
   Orange

   Email: bruno.decraene@orange.com

   Wim Henderickx
   Alcatel Lucent
   Copernicuslaan 50
   Antwerp  2018
   Belgium

   Email: wim.henderickx@alcatel-lucent.com

Patel, et al.            Expires April 20, 2016                 [Page 8]