< draft-templin-rtgwg-scalable-bgp-00.txt   draft-templin-rtgwg-scalable-bgp-01.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology Internet-Draft G. Saccone
Intended status: Informational January 23, 2019 Intended status: Informational Boeing Research & Technology
Expires: July 27, 2019 Expires: August 2, 2019 G. Dawra
LinkedIn
A. Lindem
V. Moreno
Cisco Systems, Inc.
January 29, 2019
Scalable De-Aggregation for Overlays Using the Border Gateway Protocol Scalable De-Aggregation for Overlays Using the Border Gateway Protocol
(BGP) (BGP)
draft-templin-rtgwg-scalable-bgp-00.txt draft-templin-rtgwg-scalable-bgp-01.txt
Abstract Abstract
The Border Gateway Protocol (BGP) has well-known limitations in terms The Border Gateway Protocol (BGP) has well-known limitations in terms
of the numbers of routes that can be carried and stability of the of the numbers of routes that can be carried and stability of the
routing system. This is especially true when mobile nodes frequently routing system. This is especially true when mobile nodes frequently
change their network attachment points, which in the past has change their network attachment points, which in the past has
resulted in excessive announcements and withdrawals of de-aggregated resulted in excessive announcements and withdrawals of de-aggregated
prefixes. This document discusses a means of accommodating scalable prefixes. This document discusses a means of accommodating scalable
de-aggregation of IPv6 prefixes for overlay networks using BGP. de-aggregation of IPv6 prefixes for overlay networks using BGP.
skipping to change at page 1, line 37 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2019. This Internet-Draft will expire on August 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview and Analysis . . . . . . . . . . . . . . . . . . . . 2 2. Overview and Analysis . . . . . . . . . . . . . . . . . . . . 2
3. Opportunities and Limitations . . . . . . . . . . . . . . . . 3 3. Opportunities and Limitations . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 4 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The Border Gateway Protocol (BGP) [RFC4271] has well-known The Border Gateway Protocol (BGP) [RFC4271] has well-known
limitations in terms of the numbers of routes that can be carried and limitations in terms of the numbers of routes that can be carried and
the stability of the routing system. This is especially true for the stability of the routing system. This is especially true for
routing systems that include mobile nodes that frequently change routing systems that include mobile nodes that frequently change
their network attachment points, which in the past have resulted in their network attachment points, which in the past have resulted in
excessive announcements and withdrawals of de-aggregated prefixes. excessive announcements and withdrawals of de-aggregated prefixes.
This document discusses a means of accommodating scalable de- This document discusses a means of accommodating scalable de-
aggregation of IPv6 prefixes [RFC8200] for overlay networks using aggregation of IPv6 prefixes [RFC8200] for overlay networks using
BGP. BGP.
2. Overview and Analysis 2. Overview and Analysis
As discussed in [I-D.ietf-rtgwg-atn-bgp] and As discussed in [I-D.ietf-rtgwg-atn-bgp] and
[I-D.templin-intarea-6706bis], the method for accommodating scalable [I-D.templin-intarea-6706bis], the method for accommodating de-
de-aggregation is to institute an overlay network instance of BGP aggregation is to institute an overlay network instance of BGP that
that is separate and independent from the global Internet BGP routing is separate and independent from the global Internet BGP routing
system. The overlay is presented to the global Internet as a small system. The overlay is presented to the global Internet as a small
number of aggregated IPv6 prefixes (also known as Mobility Service number of aggregated IPv6 prefixes (also known as Mobility Service
Prefixes (MSPs)) that never change. In this way, the Internet BGP Prefixes (MSPs)) that never change. In this way, the Internet BGP
routing system sees only stable aggregated MSPs (e.g., 2001:db8::/32) routing system sees only stable aggregated MSPs (e.g., 2001:db8::/32)
and is completely unaware of any de-aggregation or mobility-related and is completely unaware of any de-aggregation or mobility-related
churn that may be occurring within the overlay. churn that may be occurring within the overlay.
The overlay consists of a core Autonomous System (AS) with core AS The overlay is operated by an Overlay Service Provider (OSP), and
Border Routers (c-ASBRs) that connect to stub ASes with stub ASBRs consists of a core Autonomous System (AS) with core AS Border Routers
(s-ASBRs) in a hub-and-spokes fashion. Mobile nodes associate with (c-ASBRs) that connect to stub ASes with stub ASBRs (s-ASBRs) in a
nearby (i.e., regional) s-ASBRs for extended timeframes, and change hub-and-spokes fashion. Mobile nodes associate with nearby (i.e.,
to new s-ASBRs only after significant topological or geographic regional) stub ASes for extended timeframes, and change to new stub
movements. Mobility-related changes between stub ASes are therefore ASes only after movements of significant topological or geographical
normally on a long-duration timescale. distance. Mobility-related changes between stub ASes are therefore
normally infrequent.
The s-ASBRs use eBGP to announce de-aggregated Mobile Network The s-ASBRs use eBGP to announce de-aggregated Mobile Network
Prefixes (MNP) of mobile nodes (e.g., 2001:db8:1:2::/64) to their Prefixes (MNPs) of mobile nodes (e.g., 2001:db8:1:2::/64, etc.) to
neighboring c-ASBRs, but do not announce fine-grained mobility events their neighboring c-ASBRs, but do not announce fine-grained mobility
such as a mobile node moving to a new network attachment point. events such as a mobile node moving to a new network attachment
Instead, mobile nodes coordinate with s-ASBRs using mobility point. Instead, mobile nodes coordinate with stub ASes using
protocols such as MIPv6, LISP, AERO, etc. and s-ASBRs accommodate mobility protocols such as MIPv6, LISP, AERO, etc. and stub ASes
these localized mobility events without disturbing the c-ASBRs. accommodate these localized mobility events without disturbing the
c-ASBRs.
The c-ASBRs originate "default" to their neighboring s-ASBRs but do The c-ASBRs originate "default" to their neighboring s-ASBRs but do
not announce any MNP routes. In this way, MNP announcements and not announce any MNP routes. In this way, MNP announcements and
withdrawals are unidirectional from s-ASBRs to c-ASBRs only, thereby withdrawals are unidirectional from s-ASBRs to c-ASBRs only, thereby
suppressing BGP updates on the reverse path. The c-ASBRs in turn use suppressing BGP updates on the reverse path. The c-ASBRs in turn use
iBGP to maintain a consistent view of the full topology. iBGP to maintain a consistent view of the full topology. BGP Route
Reflectors (RRs) [RFC4456] can also be used to support increased
c-ASBR scaling.
We expect that each c-ASBR should be able to carry at least as many Each c-ASBR should be able to carry at least as many routes as a
routes as can be carried by a typical core router in the global typical core router in the global public Internet BGP routing system.
public Internet BGP routing system. Since the number of active Since the number of active routes in the Internet is rapidly
routes in the Internet is quickly approaching 1 million (1M), we approaching 1 million (1M), viable c-ASBRs must be capable of
therefore assume that each set of c-ASBRs can carry at least 1M MNP carrying at least 1M MNP routes (this has been proven even for BGP
routes which has been proven even for BGP running on lightweight running on lightweight virtual machines). The method for increasing
virtual machines. The method for increasing scaling therefore is to scaling therefore is to divide the MSP into longer sub-MSPs, and to
divide the MSP into longer sub-MSPs, and to assign a different set of assign a different set of c-ASBRs for each sub-MSP.
c-ASBRs for each sub-MSP.
For example, the MSP 2001:db8::/32 could be sub-divided into sub-MSPs 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, 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 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 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) route filters such that BGP updates are only sent to the c-ASBR(s)
that aggregate the specific sub-MSP. Then, assuming 1000 or more that aggregate the specific sub-MSP. Then, assuming 1 thousand (1K)
sub-MSPs (each with its own set of c-ASBRs) the entire BGP overlay or more sub-MSPs (each with its own set of c-ASBRs) the entire BGP
routing system should be able to service 1 billion (1B) MSPs or more. overlay routing system should be able to service 1 billion (1B) MNPs
or more.
3. Opportunities and Limitations 3. Opportunities and Limitations
Since a lightweight virtual machine (e.g., a Ubuntu linux image Since a lightweight virtual machine (e.g., a linux image running
running Quagga in the cloud) can service up to 1M MNPs using BGP, it quagga in the cloud) can service up to 1M MNPs using BGP, it is
is conceivable that dedicated high-performance router hardware could likely that dedicated high-performance IPv6 router hardware could
support even more - perhaps by a factor of 10 or more. With such support even more. With such dedicated high-performance hardware,
dedicated high-performance hardware, the numbers of MNPs that can be the number of MNPs could be increased further.
serviced could be increased further.
The deployed numbers of s-ASBRs even for very large overlays should The deployed numbers of s-ASBRs even for very large overlays should
not exceed the c-ASBR's capacity for BGP peering sessions. For not exceed a c-ASBR's capacity for BGP peering sessions. For
example, c-ASBRs should be capable of supporting a few thousands to a example, c-ASBRs should be capable of servicing1K or more BGP peering
few tens of thousands of BGP peering sessions but it is not known sessions, with the upper bound limited by keepalive and update
whether more could be supported. 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.
By the same token, the maximum number of c-ASBR sets should be based Mobile nodes should refrain from moving rapidly between stub ASes for
on the number of BGP peering sessions each s-ASBR can comfortably no good reason, since the objective is only to reduce routing stretch
accommodate, since each s-ASBR must peer with each c-ASBR set. 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.
Packets sent between end systems that associate with different Packets sent between mobile nodes that associate with different stub
s-ASBRs would initially need to be forwarded through the core AS, ASes would initially need to be forwarded through the core AS, which
which presents a forwarding bottleneck. For this reason, some form presents a forwarding bottleneck. For this reason, a route
of route optimization is needed to significantly reduce congestion in optimization function is needed to reduce congestion in the core.
the core and preferably to also allow for direct end system to end Since c-ASBRs should be commercial off-the-shelf (COTS) dedicated
system communications without involving s-ASBRs. Since c-ASBRs high-performance IPv6 routers, however, they should not be required
should be standard commercial off-the-shelf (COTS) dedicated high- to participate directly in any out-of-band route optimization
performance IPv6 routers, however, they should not be required to signaling. Instead, route optimization should be coordinated by stub
participate in any ancillary route optimization signaling. The AERO AS network elements and/or the mobile nodes themselves.
route optimization function honors this design consideration.
Further opportunities and limitations are discussed in more detail in 4. Use Cases
the references [I-D.ietf-rtgwg-atn-bgp][I-D.templin-intarea-6706bis].
4. IANA Considerations 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.
5. Implementation Status
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.
6. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
5. Security Considerations 7. Security Considerations
Security considerations are discussed in the references. Security considerations are discussed in the references.
6. Acknowledgements 8. Acknowledgements
This work is aligned with the FAA as per the SE2025 contract number This work is aligned with the FAA as per the SE2025 contract number
DTFAWA-15-D-00030. DTFAWA-15-D-00030.
This work is aligned with the NASA Safe Autonomous Systems Operation This work is aligned with the NASA Safe Autonomous Systems Operation
(SASO) program under NASA contract number NNA16BD84C. (SASO) program under NASA contract number NNA16BD84C.
This work is aligned with the Boeing Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program. MobileNet program.
7. References 9. References
7.1. Normative References 9.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
7.2. Informative References 9.2. Informative References
[I-D.ietf-rtgwg-atn-bgp] [I-D.ietf-rtgwg-atn-bgp]
Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. Templin, F., Saccone, G., Dawra, G., Lindem, A., and V.
Moreno, "A Simple BGP-based Mobile Routing System for the Moreno, "A Simple BGP-based Mobile Routing System for the
Aeronautical Telecommunications Network", draft-ietf- Aeronautical Telecommunications Network", draft-ietf-
rtgwg-atn-bgp-01 (work in progress), January 2019. rtgwg-atn-bgp-01 (work in progress), January 2019.
[I-D.templin-intarea-6706bis] [I-D.templin-intarea-6706bis]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-intarea-6706bis-03 (work in (AERO)", draft-templin-intarea-6706bis-03 (work in
progress), December 2018. progress), December 2018.
Appendix A. Change Log Appendix A. Change Log
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from -00 to -01:
o added Route Reflectors
o introduced term "Overlay Service Provider (OSP)"
o removed estimate of number of routes for high-performance routers
o revised text on route optimization
o added use case and implementation sections
Status as of 01/23/2018: Status as of 01/23/2018:
o -00 draft published o -00 draft published
Author's Address Authors' Addresses
Fred L. Templin (editor) Fred L. Templin (editor)
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
USA USA
Email: fltemplin@acm.org Email: fltemplin@acm.org
Greg Saccone
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: gregory.t.saccone@boeing.com
Gaurav Dawra
LinkedIn
USA
Email: gdawra.ietf@gmail.com
Acee Lindem
Cisco Systems, Inc.
USA
Email: acee@cisco.com
Victor Moreno
Cisco Systems, Inc.
USA
Email: vimoreno@cisco.com
 End of changes. 25 change blocks. 
75 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/