Use Cases for an Interface to BGP Protocol
draft-keyupate-irs-bgp-usecases-00

Network Working Group                                           K. Patel
Internet-Draft                                             Cisco Systems
Intended status: Informational                                H. Gredler
Expires: April 17, 2013                                 Juniper Networks
                                                             R. Fernando
                                                           Cisco Systems
                                                               S. Amante
                                            Level 3 Communications, Inc.
                                                        October 14, 2012

               Use Cases for an Interface to BGP Protocol
                 draft-keyupate-irs-bgp-usecases-00.txt

Abstract

   A network routing protocol like BGP is typically configured and
   results of its operation are analyzed through some form of Command
   Line Interface (CLI) or NETCONF.  These interactions to control BGP
   and diagnose its operation encompass: configuration of protocol
   parameters, display of protocol data, setting of certain protocol
   states and debugging of the protocol.

   Interface to the Routing System's (IRS) Programatic interfaces, as
   defined in [I-D.ward-irs-framework], provides an alternate way to
   control the configuration and diagnose the operation of the BGP
   protocol.  IRS may be used for the configuration, manipulation,
   polling or analyzing protocol data.  This document describes a set of
   use cases for which IRS can be used for BGP protocol.  It is indended
   to provide a base for the solution draft descibring a set of
   Interfaces to the BGP protocol.

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 April 17, 2013.

Patel, et al.            Expires April 17, 2013                 [Page 1]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

Copyright Notice

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

Patel, et al.            Expires April 17, 2013                 [Page 2]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  BGP Configuration  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  BGP Protocol Configuration . . . . . . . . . . . . . . . .  5
     2.2.  BGP Policy Configuration . . . . . . . . . . . . . . . . .  6
   3.  BGP Protocol Operation . . . . . . . . . . . . . . . . . . . .  8
     3.1.  BGP Error Handling for Internal BGP Sessions . . . . . . .  8
     3.2.  Tracing Dropped BGP Routes . . . . . . . . . . . . . . . .  8
   4.  BGP Route Manipulation . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Customized Best Path Selection Criteria  . . . . . . . . .  9
     4.2.  Flowspec Routes  . . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Route Filter Routes  . . . . . . . . . . . . . . . . . . .  9
     4.4.  Optimised Exit Control . . . . . . . . . . . . . . . . . .  9
     4.5.  Offline Validation of Routes . . . . . . . . . . . . . . . 10
   5.  Registration . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Polling of Routing Events  . . . . . . . . . . . . . . . . 10
     5.2.  Polling of Protocol Statistics . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Patel, et al.            Expires April 17, 2013                 [Page 3]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

1.  Introduction

   Typically, a network routing protocol like BGP is configured and
   results of its operation are analyzed through some form of Command
   Line Interface (CLI) or NETCONF.  These interactions to control BGP
   and diagnose its operation encompass: configuration of protocol
   parameters, display of protocol data, setting of certain protocol
   states and debugging of the protocol.

   The IRS Framework document [I-D.ward-irs-framework] describes a
   mechanism to control network protocols like BGP using a set of
   programmatic interfaces.  These programmatic interfaces allow one to
   control the BGP protocol by analyzing its operational state and
   routing protocol data, plus manipulating BGP's configuration to
   achieve various goals.  The IRS is not intended to replace any
   existing configuration mechanisms, (i.e.: Command Line Interface or
   NETCONF).  Instead, IRS is intended to augment those existing
   mechanisms by defining a standardized set of programmatic interfaces
   to enable easier configuration, interrogation and analysis of the BGP
   protocol.

   This document describes a set of use cases for which IRS's
   programmatic interfaces can be used to control and analyze the
   operation of BGP.  The use cases described in this document cover the
   following aspects of BGP: protocol parameter configuration,
   configuration of routing policies, protocol route manipulation and
   tracking of protocol events.  The goal is to inform the community's
   understanding of where the IRS BGP extensions fit within the overall
   IRS architecture.  It is indended to provide a basis for the
   solutions draft descibring the set of Interfaces to the BGP protocol.

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

2.  BGP Configuration

   The configuration of BGP is arduous to establish and maintain,
   particularly on networks whose services have a requirement for
   complex routing policies.  This need is magnified by the need to
   routinely perform changes to large numbers of BGP routers to, for
   example: add or remove customer's BGP sessions, announce or withdraw
   (customer) IP prefixes in BGP, modify BGP policies to effect changes
   in Traffic Engineering, audit BGP routers to ensure they have
   consistent and appropriate BGP policies, etc.

Patel, et al.            Expires April 17, 2013                 [Page 4]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

   There are three categories of BGP configuration:

   1.  Local BGP routing protocol configuration: local Autonomous System
       Number (ASN), BGP path selection properties of the router,
       injection of (aggregate) routes into BGP, etc.

   2.  Local BGP policies: policies designed to filter and then
       manipulate BGP attributes associated with BGP routes learned
       through BGP sessions.  These policies typically live in the
       global configuration of a BGP router, but are applied on a per-
       BGP neighbor basis (or, group of BGP neighbors); and,

   3.  BGP neighbor sessions: remote ASN, remote IP address, address
       families, BGP policies to applied to routes, max-prefix limits,
       etc.

   The sum total of BGP configuration on a BGP router is typically the
   largest quantify of configuration on Service Provider's BGP routers,
   by a fairly large margin.  When that is combined with the large set
   of routine configuration changes, mentioned above, it should be
   fairly clear that systematic reading, configuration and control of
   BGP routers through a mechanism like IRS would greatly benefit all
   operators of BGP routers.

   While it may not be possible to provide programmatic APIs for
   esoteric vendor-specific policy configuration, it is possible to
   provide such API's for BGP protocol specific configuration and the
   more commonly used BGP routing policies.

2.1.  BGP Protocol Configuration

   Ability to enable and disable new address families within a BGP
   protocol for a network of BGP speaking routers is a challenge.  The
   challenge is mainly in keeping track of BGP speaker's feature
   capabilities and then configuration of new address families on a
   multiple BGP speakers within a given network.  With the necessary
   information, IRS controllers allow a network operator to push
   configuration information for enabling and disabling of new address
   families on a partial or entire set of BGP speakers within a given
   network.  This would assist in building BGP overlay networks as
   needed.

   For VPN address families, the main challenge lies in the complex VPN
   configuration required to setup the control plane for Customer VPNs.
   The configuration involves creating a Virtual Routing and Forwarding
   instance (VRF), a Route Distinguisher (RD) that ensures each customer
   prefixes remains unique across VPNs, and Route Targets (RT) that help
   ensure that the Customer prefixes are segregated appropriately so

Patel, et al.            Expires April 17, 2013                 [Page 5]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

   that they do not cross the VPN boundries.  IRS would allow a network
   operator to push such configuration from a central location where a
   global VPN provisioning information could be stored.  This helps
   avoid manual configuration of a VPN on multiple routers.  Instead the
   configuration is controlled and pushed though a central IRS
   controller using a programmatic set of APIs on targetted set of BGP
   speakers.

   Use of IRS controllers to announce protocol configuration information
   would simplify and automate configuration of BGP protocol in IBGP
   deployments where the protocol based policies are seldom used.  To
   facilitate such a centralized configuration model, BGP speakers could
   be extended to use programmatic APIs to announce their feature
   capabilities as part of protocol initialization to the centralize IRS
   controllers.  This would assist IRS controllers to auto-discover BGP
   protocol capabilities of various BGP speakers in a given network.
   IRS controllers inturn would use the information towards enabling/
   disabling of BGP specific features on BGP speakers.

2.2.  BGP Policy Configuration

   Filtering of BGP routes is strongly recommended to control the
   announcements of BGP prefixes across the internet.  Most providers
   make extensive use of BGP prefix filtering policies at the edge of
   their networks.  The reasons for filtering BGP prefixes are:

   o  Avoid Unwanted Route Announcements.  Filter prefixes that MUST not
      be routed [RFC5735], [RFC5156].  Filter prefixes that are not
      allocated by Internet Routing Registries.

   o  Facilitate Route Summarization.  Filter prefixes beyond certain
      agreed prefix mask length between providers.  Route Summarization
      helps control BGP RIB and FIB table size.

   o  Defensive Security.  Filter prefixes from Stub customer ASes that
      are not owned by the customers.  Filter customer prefixes
      announced by other providers.  This helps avoid prefix hijacking.

   A set of standards-based schemas to enable configuration of Local BGP
   policies and BGP neighbor sessions was realized through the Routing
   Policy Specification Language (RSPL) [RFC2622].  The RPSL defined a
   standards-based schemas, or 'objects' as it called them, that
   defined:

   o  binding of IP prefixes to (one or more) Origin AS, (route
      objects);

Patel, et al.            Expires April 17, 2013                 [Page 6]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

   o  collections of routes (route-set objects);

   o  collections of Autonomous Systems (as-set objects); and,

   o  routing policy of an Autonomous System to/from its adjacent
      neighbor AS'es, (aut-num objects)

   Each ASN is responsible for creation, modification and deletion of
   its RPSL objects in an Internet Routing Registry (IRR).  IRR's are
   typically operated by Regional Internet Registries (RIR's) and a few
   dozen larger ISP's and independent organizations.  The IRR's provide
   a well-known location for all organizations attached to the Internet
   to retrieve or update RPSL objects.

   While still widely and actively used by Internet Service Providers,
   the prevailing belief is that the data contained in the IRR's is
   inaccurate, primarily due to a lack of deployed authorization method
   with respect to the creation of modification of RPSL objects.  It
   should be noted that this criticism is not directed at the previously
   defined RPSL schemas, but rather at the data contained in RPSL
   schemas by end-users of the IRR system.  Please refer to the IRR &
   Routing Policy Configuration Considerations
   [I-D.mcpherson-irr-routing-policy-considerations] document for a more
   thorough discussion of the history and present state of the IRR's.

   Currently, RPSL schemas are exchanged between non-routing systems
   (servers) used within the IRR system.  In addition, open-source and
   proprietary applications create or modify RPSL schemas, as necessary,
   to signal the announcement (or, withdrawl) of an IP prefix from an
   ASN or the creation (or, teardown) of a neighbor relationship between
   two adjacent ASN's.  Most importantly, these RPSL schemas are
   consumed by similar applications to automatically build routing
   polcies, (i.e.: lists of IP prefixes, corresponding Origin ASN's
   and/or AS_PATH's), that then get translated to device-specific syntax
   (i.e.: CLI) before being pushed into individual BGP routers to effect
   routing policy on the network.  It is common for Internet Service
   Providers to perform updates to these routing policies across their
   entire network on a daily basis.

   With IRS it would be desirable to change the last step in the above
   process so that BGP policies derived from RPSL schemas, and other
   information sources, are translated into standards-based schemas that
   are then pushed, or pulled, into individual BGP routers.  More
   generally, IRS controllers could use API's to gather information
   required to build various types of BGP routing policies plus the
   corresponding set of Autonomous System Border Routers (ASBR's) where
   such policies need to be applied in the network and, finally, making
   those changes to individual network elements so those BGP policies

Patel, et al.            Expires April 17, 2013                 [Page 7]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

   take effect in the network.  In doing so, a network operator now has
   a centralized way of building and making these policies take effect
   across the network in a coordinated manner.

3.  BGP Protocol Operation

   It is increasingly common for services facilitated via BGP to be
   subject to severe, widespread disruptions (outages), primarily due to
   the destructive teardown of BGP sessions as a result of receiving
   malformed BGP attributes.  The document Operational Requirements for
   Enhanced Error Handling Behaviour in BGP-4
   [I-D.ietf-grow-ops-reqs-for-bgp-error-handling] outlines requirements
   to try to minimize the scope of the impact attributed to such errors.
   Unfortunately, more fine-grained BGP error handling solutions, which
   would result in little to no impact on the operation of BGP protocol,
   remain elusive.

3.1.  BGP Error Handling for Internal BGP Sessions

   It is possible that IRS could enable enhanced error handling
   techniques for Internal BGP sessions.  At a minimum, IRS-capable BGP
   routers could signal an event such as "Malformed Attribute Received"
   toward an IRS controller(s).  IRS controller(s) may already have a
   real-time view of BGP routes, and corresponding BGP attributes, or
   may dynamically interrogate BGP routers in the network to identify
   the present propagation scope of the BGP route(s) that are affected.
   Finally, the IRS controller(s) could then signal back to BGP routers
   to apply a filter that would block propagation of the BGP attribtue
   or BGP route, as necessary, in order to temporarily aid in
   consistency of BGP routing information across the entire network
   until a permanent fix can be developed and deployed within BGP
   routers.

   IRS would enable the global visibility and global control over the
   operational state of BGP, within a given Autonomous System, that are
   necessary to faciliate the learning of, rapid response to and more
   fine-grained isolation/scoping of BGP protocol events that currently
   cause a destructive tear-down of BGP sessions that lead to widespread
   disruptions of services.

3.2.  Tracing Dropped BGP Routes

   It is extremely useful to operators to be able to rapidly identify
   instances where a BGP route is not being propagated within an
   Autonomous System.  At a minimum, this could result in sub-optimal
   performance when attempting to reach such destinations.

Patel, et al.            Expires April 17, 2013                 [Page 8]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

   There are two instances when this scenario will occur.  First, when a
   Service Provider is using "Soft Reconfiguration Inbound", it allows
   their ASBR routers to receive a copy of a BGP route, but show that
   route was not permitted into the Adj-RIB-In most likely as a result
   of the inbound BGP policy not permitting that IP prefix.  Thus, this
   BGP route is not even eligible for BGP Path Selection.  The second
   instance is where the BGP route is permitted by the inbound BGP
   policy into the Adj-RIB-In, but due to BGP Path Selection (i.e.:
   lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the
   best path and, subsequently, this particular BGP route is not
   forwarded on to other internal BGP speakers in the AS.  In both
   instances, the BGP route is only visible within the ASBR on which
   that BGP route was first learned.  Needless to say, in large Service
   Provider networks with a numerous interconnects to a single customer
   it can be very time-consuming to discover where such a BGP route is
   learned before ultimately determining why the route was blocked or
   not preferred.

   With IRS, it would be possible for an IRS controller to rapidly
   gather information from across a large set of BGP routers in the
   network to determine at what ASBR's the BGP route is being learned.
   Next, the IRS controller could interrogate those routers BGP policies
   to determine the root cause of why the route was either not learned
   or not preferred in BGP.  Finally, if necessary, the IRS
   controller(s) could amend BGP policies and push them out to BGP
   routers to permit the BGP route or make it a preferred route
   according to the BGP path selection algorithm.

4.  BGP Route Manipulation

4.1.  Customized Best Path Selection Criteria

4.2.  Flowspec Routes

   Installation of flow spec filters on RR and let RRs flood it within
   the network

4.3.  Route Filter Routes

   Installation of RT filters on RR ??

4.4.  Optimised Exit Control

   This is really a bgp feature.  One could tweak BGP parameters to
   ensure optimized bgp paths/exit points are chosen

Patel, et al.            Expires April 17, 2013                 [Page 9]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

4.5.  Offline Validation of Routes

5.  Registration

5.1.  Polling of Routing Events

5.2.  Polling of Protocol Statistics

6.  Security Considerations

7.  Acknowledgements

   TBD.

8.  References

8.1.  Normative References

   [I-D.ward-irs-framework]
              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Framework", draft-ward-irs-framework-00
              (work in progress), July 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3392]  Chandra, R. and J. Scudder, "Capabilities Advertisement
              with BGP-4", RFC 3392, November 2002.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

8.2.  Informative References

   [I-D.ietf-grow-ops-reqs-for-bgp-error-handling]
              Shakir, R., "Operational Requirements for Enhanced Error
              Handling Behaviour in BGP-4",

Patel, et al.            Expires April 17, 2013                [Page 10]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

              draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 (work
              in progress), July 2012.

   [I-D.mcpherson-irr-routing-policy-considerations]
              McPherson, D., Amante, S., Osterweil, E., and L. Blunk,
              "IRR & Routing Policy Configuration Considerations",
              draft-mcpherson-irr-routing-policy-considerations-01 (work
              in progress), September 2012.

   [RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
              Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
              "Routing Policy Specification Language (RPSL)", RFC 2622,
              June 1999.

   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
              "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [RFC5156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
              April 2008.

   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
              BCP 153, RFC 5735, January 2010.

Authors' Addresses

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

   Email: keyupate@cisco.com

   Hannes Gredler
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA  94089
   USA

   Email: hannes@juniper.net

Patel, et al.            Expires April 17, 2013                [Page 11]
Internet-Draft      Use Cases for an Interface to BGP       October 2012

   Rex Fernando
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: rex@cisco.com

   Shane Amante
   Level 3 Communications, Inc.
   1025 Eldorado Blvd
   Broomfield, CO  80021
   USA

   Email: shane@level3.net

Patel, et al.            Expires April 17, 2013                [Page 12]