<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-rtgwg-scalable-bgp-01.txt"
     ipr="trust200902">
  <front>
    <title abbrev="Scalable De-Aggregation for BGP">Scalable De-Aggregation
    for Overlays Using the Border Gateway Protocol (BGP)</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>Boeing Research &amp; Technology</organization>

      <address>
        <postal>
          <street>P.O. Box 3707</street>

          <city>Seattle</city>

          <region>WA</region>

          <code>98124</code>

          <country>USA</country>
        </postal>

        <email>fltemplin@acm.org</email>
      </address>
    </author>

    <author fullname="Greg Saccone" initials="G." surname="Saccone">
      <organization>Boeing Research &amp; Technology</organization>

      <address>
        <postal>
          <street>P.O. Box 3707</street>

          <city>Seattle</city>

          <region>WA</region>

          <code>98124</code>

          <country>USA</country>
        </postal>

        <email>gregory.t.saccone@boeing.com</email>
      </address>
    </author>

    <author fullname="Gaurav Dawra" initials="G." surname="Dawra">
      <organization>LinkedIn</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <email>gdawra.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Acee Lindem" initials="A." surname="Lindem">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <email>acee@cisco.com</email>
      </address>
    </author>

    <author fullname="Victor Moreno" initials="V." surname="Moreno">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <email>vimoreno@cisco.com</email>
      </address>
    </author>

    <date day="29" month="January" year="2019"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>The Border Gateway Protocol (BGP) has well-known limitations in terms
      of the numbers of routes that can be carried and stability of the
      routing system. This is especially true when mobile nodes frequently
      change their network attachment points, which in the past has resulted
      in excessive announcements and withdrawals of de-aggregated prefixes.
      This document discusses a means of accommodating scalable de-aggregation
      of IPv6 prefixes for overlay networks using BGP.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The Border Gateway Protocol (BGP) <xref target="RFC4271"/> has
      well-known limitations in terms of the numbers of routes that can be
      carried and the stability of the routing system. This is especially true
      for routing systems that include mobile nodes that frequently change
      their network attachment points, which in the past have resulted in
      excessive announcements and withdrawals of de-aggregated prefixes. This
      document discusses a means of accommodating scalable de-aggregation of
      IPv6 prefixes <xref target="RFC8200"/> for overlay networks using
      BGP.</t>
    </section>

    <section anchor="analysis" title="Overview and Analysis">
      <t>As discussed in <xref target="I-D.ietf-rtgwg-atn-bgp"/> and <xref
      target="I-D.templin-intarea-6706bis"/>, the method for accommodating
      de-aggregation is to institute an overlay network instance of BGP that
      is separate and independent from the global Internet BGP routing system.
      The overlay is presented to the global Internet as a small number of
      aggregated IPv6 prefixes (also known as Mobility Service Prefixes
      (MSPs)) that never change. In this way, the Internet BGP routing system
      sees only stable aggregated MSPs (e.g., 2001:db8::/32) and is completely
      unaware of any de-aggregation or mobility-related churn that may be
      occurring within the overlay.</t>

      <t>The overlay is operated by an Overlay Service Provider (OSP), and
      consists of a core Autonomous System (AS) with core AS Border Routers
      (c-ASBRs) that connect to stub ASes with stub ASBRs (s-ASBRs) in a
      hub-and-spokes fashion. Mobile nodes associate with nearby (i.e.,
      regional) stub ASes for extended timeframes, and change to new stub ASes
      only after movements of significant topological or geographical
      distance. Mobility-related changes between stub ASes are therefore
      normally infrequent.</t>

      <t>The s-ASBRs use eBGP to announce de-aggregated Mobile Network
      Prefixes (MNPs) of mobile nodes (e.g., 2001:db8:1:2::/64, etc.) to their
      neighboring c-ASBRs, but do not announce fine-grained mobility events
      such as a mobile node moving to a new network attachment point. Instead,
      mobile nodes coordinate with stub ASes using mobility protocols such as
      MIPv6, LISP, AERO, etc. and stub ASes accommodate these localized
      mobility events without disturbing the c-ASBRs.</t>

      <t>The c-ASBRs originate "default" to their neighboring s-ASBRs but do
      not announce any MNP routes. In this way, MNP announcements and
      withdrawals are unidirectional from s-ASBRs to c-ASBRs only, thereby
      suppressing BGP updates on the reverse path. The c-ASBRs in turn use
      iBGP to maintain a consistent view of the full topology. BGP Route
      Reflectors (RRs) <xref target="RFC4456"/> can also be used to support
      increased c-ASBR scaling.</t>

      <t>Each c-ASBR should be able to carry at least as many routes as a
      typical core router in the global public Internet BGP routing system.
      Since the number of active routes in the Internet is rapidly approaching
      1 million (1M), viable c-ASBRs must be capable of carrying at least 1M
      MNP routes (this has been proven even for BGP running on lightweight
      virtual machines). The method for increasing scaling therefore is to
      divide the MSP into longer sub-MSPs, and to assign a different set of
      c-ASBRs for each sub-MSP.</t>

      <t>For example, the MSP 2001:db8::/32 could be sub-divided into sub-MSPs
      such as 2001:db8:0010::/44, 2001:db8:0020::/44, 2001:db8:0030::/44, etc.
      with each sub-MSP assigned to a different set of c-ASBRs. Each s-ASBR
      peers with at least one member of each c-ASBR set and uses route filters
      such that BGP updates are only sent to the c-ASBR(s) that aggregate the
      specific sub-MSP. Then, assuming 1 thousand (1K) or more sub-MSPs (each
      with its own set of c-ASBRs) the entire BGP overlay routing system
      should be able to service 1 billion (1B) MNPs or more.</t>
    </section>

    <section anchor="limit" title="Opportunities and Limitations">
      <t>Since a lightweight virtual machine (e.g., a linux image running
      quagga in the cloud) can service up to 1M MNPs using BGP, it is likely
      that dedicated high-performance IPv6 router hardware could support even
      more. With such dedicated high-performance hardware, the number of MNPs
      could be increased further.</t>

      <t>The deployed numbers of s-ASBRs even for very large overlays should
      not exceed a c-ASBR's capacity for BGP peering sessions. For example,
      c-ASBRs should be capable of servicing1K or more BGP peering sessions,
      with the upper bound limited by keepalive and update control messaging
      overhead. Conversely, s-ASBRs should be capable of supporting even more
      sessions since they only receive keepalives and only send updates for
      mobile nodes within their local stub ASes.</t>

      <t>Mobile nodes should refrain from moving rapidly between stub ASes for
      no good reason, since the objective is only to reduce routing stretch
      due to movement of significant distances. OSPs could employ
      disincentives such as surcharge penalties for gratuitous mobility, but
      intentional abuse would also yield little reward since only the bad
      actor (i.e., and not others) would be subject to MNP instability.</t>

      <t>Packets sent between mobile nodes that associate with different stub
      ASes would initially need to be forwarded through the core AS, which
      presents a forwarding bottleneck. For this reason, a route optimization
      function is needed to reduce congestion in the core. Since c-ASBRs
      should be commercial off-the-shelf (COTS) dedicated high-performance
      IPv6 routers, however, they should not be required to participate
      directly in any out-of-band route optimization signaling. Instead, route
      optimization should be coordinated by stub AS network elements and/or
      the mobile nodes themselves.</t>
    </section>

    <section anchor="use" title="Use Cases">
      <t>Use cases include Unmanned Air Systems (UAS) in controlled and
      uncontrolled airspaces, Intelligent Transportation Systems (ITS) in
      urban air/ground mobility environments, aviation networks, enterprise
      mobile device users, and cellular network users. Any other use cases in
      which an OSP services large numbers of mobile nodes are also in
      scope.</t>
    </section>

    <section anchor="imp" title="Implementation Status">
      <t>The arrangement of stub and core ASes described in this document has
      been implemented using standards-compliant linux operating systems and
      BGP routing protocol implementations (i.e., quagga). No new code was
      included, and all requirements were satisfied through standard
      configuration options.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document does not introduce any IANA considerations.</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>Security considerations are discussed in the references.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>This work is aligned with the FAA as per the SE2025 contract number
      DTFAWA-15-D-00030.</t>

      <t>This work is aligned with the NASA Safe Autonomous Systems Operation
      (SASO) program under NASA contract number NNA16BD84C.</t>

      <t>This work is aligned with the Boeing Information Technology (BIT)
      MobileNet program.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.8200"?>

      <?rfc include="reference.RFC.4456"?>

      <?rfc include="reference.RFC.4271"?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc include="reference.I-D.templin-intarea-6706bis"?>

      <?rfc ?>

      <?rfc include="reference.I-D.ietf-rtgwg-atn-bgp"?>
    </references>

    <section title="Change Log">
      <t>&lt;&lt; RFC Editor - remove prior to publication &gt;&gt;</t>

      <t>Changes from -00 to -01:</t>

      <t><list style="symbols">
          <t>added Route Reflectors</t>

          <t>introduced term "Overlay Service Provider (OSP)"</t>

          <t>removed estimate of number of routes for high-performance
          routers</t>

          <t>revised text on route optimization</t>

          <t>added use case and implementation sections</t>
        </list></t>

      <t>Status as of 01/23/2018:</t>

      <t><list style="symbols">
          <t>-00 draft published</t>
        </list></t>
    </section>
  </back>
</rfc>
