Internet DRAFT - draft-raszuk-mi-bgp
draft-raszuk-mi-bgp
IDR Working Group R. Raszuk, Ed.
Internet-Draft Bloomberg LP
Intended status: Standards Track October 22, 2018
Expires: April 25, 2019
Multi Instance BGP
draft-raszuk-mi-bgp-00
Abstract
As the number of operational use cases of BGP grows there is demand
to increase the level of separation and processing independence
between various address families carried by BGP today. This document
augments base BGP specification in allowing local configuration of
BGP port number by the operator to run parallel fully disjoined BGP
instances allowing full processing separation between them.
While local BGP implementation may already assure BGP process or
thread robustnes the general aim here is to allow similar level of
groups of BGP address families independence when running BGP code on
general purpose hardware as well as x86 based route reflectors.
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 https://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 25, 2019.
Copyright Notice
Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of
Raszuk Expires April 25, 2019 [Page 1]
Internet-Draft mi-bgp October 2018
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.
Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Today's operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Related work . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Multi Instance Proposal . . . . . . . . . . . . . . . . . . . 4
5.1. Protocol changes . . . . . . . . . . . . . . . . . . . . 5
5.2. BGP Identifier BGP peering address . . . . . . . . . . . 5
6. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 5
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Contributors
The current document has been created based on parent document
Transport Instance BGP. Below is the list of contributors who
contributed to the previous document:
Keyur Patel, Arrcus Inc., 2077 Gateway Place Suite 400, San Jose,
CA, 95119, US, Email: keyur@arrcus.com
Bruno Decraene, France Telecom, 38 rue du General Leclerc, Issy
Moulineaux cedex 9, France, Email: bruno.decraene@orange-
ftgroup.com
Jakob Heitz, Cisco, 170 Tasman Dr, San Jose, CA 95134, US Email:
jheitz@cisco.com
Thomas D. Nadeau
Jie Dong, Huawei Technologies Co.,Ltd, KuiKe Building, No.9 Xinxi
Rd., Beijing, Hai-Dian District, 100085, P.R. China, Email:
dongjie_dj@huawei.com
Raszuk Expires April 25, 2019 [Page 2]
Internet-Draft mi-bgp October 2018
Yoshinobu Matsuzaki, Internet Initiative Japan Inc., Jinbocho
Mitsui Bldg., 1-105 Kanda Jinbo-cho, Tokyo, Chiyoda-ku, Japan,
Email: maz@iij.ad.jp
2. Introduction
BGP4 [RFC4271] protocol is practically a single standard today for
the distribution of an inter-domain routing information. Under many
applications it is also used as the protocol of choice when
disseminating various application-based information intra-domain.
It's popularity and it's wide use has been effectively provided by
it's extensibility, reliable transport, session protection as well as
built in loop prevention mechanisms.
It has been observed in both intra-domain as well as inter-domain
applications that reliable information distribution is an extremely
desired tool for many applications. The introduction of
Multiprotocol extensions to BGP [RFC4760] made it appealing for new
kinds of information to be carried over BGP4.
While these extensions have proven to be useful, they however have
increased the load of information as well as the type of information
that BGP was originally envisioned to carry. As example carrying
link state LSDB and TED databases with BGP-LS RFC7752 [RFC5512] with
all its extensions.
This draft proposes to group together similar classes of information
carried in BGP and execute it by separate process on a per AFI/SAFI
basis. Each such BGP process would be fully independent from each
other and will listen on the TCP port as chosen by local
configuration by the operator.
This draft proposes that the current BGP infrastructure will continue
to be used to disseminate Internet routing related information and
will continue to listen on BGP TCP port 179. Non Internet routing
information or private routing data are recommended to be handled by
parallel BGP processes listening on their own TCP ports.
Another point of view in favor of BGP instance separation is the
aspect of service protection. One could see BGP process responsible
for global routing due to it's global nature much more exposed to
control plane errors and attacks then potentially private only BGP
instance contained to one or few ASes, possibly under common
administration. In the same way one could also observe that by fully
separating global Internet BGP from any local BGP based services the
Internet itself can be fully isolated from any issues caused by local
service provider's services.
Raszuk Expires April 25, 2019 [Page 3]
Internet-Draft mi-bgp October 2018
3. Today's operation
In today's networks BGP4 operates per BGP specification [RFC4271].
This model of operation has proven to have number of disadvantages
when it comes to concurrent support of multiple applications when
amount of transported number of entries is already non trivial, when
is not bounded by application architecture and when it is
continuously growing.
There are many examples where major router vendors recommend to
separate route reflectors into disjoined clusters so Internet routes
are not affected by L3VPN routes or BGP-LS data. To put things into
right perspective one needs to observe that local per box scaling
numbers have already reached millions of VPN routes. BGP-LS is
carrying more and more IGP and TE data almost every day.
4. Related work
To address the session separation without forcing users to manually
bound each session or group of session to a different BGP peering
address Multisession BGP [I-D.ietf-idr-bgp-multisession] solution has
been proposed. It is our opinion that Multisession BGP is a tool to
automatically bound group of applications to different TCP sessions
however code complexity of handling this automation has resulted in
significant complications and in number of BGP code bases has been
disabled or even removed.
Observation also needs to be made that in this model all BGP OPEN
messages would still end up going to the same BGP TCP port number
179. Furthermore, all the incoming sessions would be handled by the
same BGP process. Number of applications BGP carries data for today
call for much stronger separation including not just session but
processing isolation and operator's control.
Multisession if still required could be applicable within each major
BGP instance by providing fine granularity of session separation
within a given instance.
5. Multi Instance Proposal
In order to minimize impact between different classes of applications
carried today or to be carried by BGP in the future to those of
critical nature for Internet connectivity, this document proposes to
run separate instances of BGP for each of them.
The separation of concurrent, but not necessarily congruent BGP
instances will be complete. Each such instance can run the same or
different bgp code base.
Raszuk Expires April 25, 2019 [Page 4]
Internet-Draft mi-bgp October 2018
5.1. Protocol changes
The proposed here Multi Instance BGP does not require any changes to
BGP4 protocol mechanism, state machine, error handling or operation.
The exact same procedures and semantics apply in the same way for
routing instance as well as for other instances of BGP. The
operational advantage in the instance separation is the ability to
apply different process level parameters and tuning for each launched
instance precisely fitting to the operator's needs.
The only protocol change proposed in this document is the ability to
specify locally TCP port number given BGP instance will be listening
on.
5.2. BGP Identifier BGP peering address
When running both independent instances on the same platform question
arises on the recommended choice for BGP Identifier [RFC6286] as well
as BGP peering address to be used.
It needs to be observed that since via different BGP OPEN TCP port
number and then different session ports if only implementation allows
there is no requirement this specification would enforce to make any
of those different between any instances.
Another advantage of sharing the same peering address of BGP sessions
between instances is that in the event of operator's choice to use
fast failure detection tools like BFD [RFC5880] the same event can be
passed to both instances without any additional need to run two
parallel and independent BFD sessions.
6. Summary of benefits
Below is a combined list of main benefits provided by Multi Instance
BGP:
Isolation and independence from protocol or process failures
caused by any instance.
Independence in: CPU usage, memory space and internal platform's
resources.
Different port for BGP OPEN messages allowing the same BGP
router_id or peering address sharing between instances.
Different and fully isolated TCP sessions between instances. Each
instance may still benefit from multisessions BGP proposal within
each instance.
Raszuk Expires April 25, 2019 [Page 5]
Internet-Draft mi-bgp October 2018
Possibility of different IP precedence BGP message marking for
more fair and accurate PHB treatment.
7. Applications
Recent BGP extensions RFC7752 [RFC7752] define a way to carry link
state information over BGP transport. Fate sharing of such new type
of data with existing BGP address families is mutually risky. While
originally intended to be physically separated operational experience
proves that very often it is used just as an "add-on" to existing
data already carried over BGP including being handled by the same set
of BGP infrastructure (ex: route reflectors). Separating BGP-LS to
travel over disjoined TCP sessions will not only reduce mutual
impact, but also enable separate processing of it (ex: pinning to
different CPU core) even on the same BGP hardware.
Another group of potential candidates for Multi Instance BGP could be
any type of auto discovery mechanism for other applications or for
BGP itself [I-D.raszuk-idr-bgp-auto-discovery]. Other examples may
include: L2VPN/VPLS or MVPN Auto Discovery [RFC6513] as possible
candidates.
Another class of applications perfectly fitting the separate BGP
instance model for it's global information distribution authors
foresee a mapping plane of identifiers to locators in the new
evolving internet architecture. As example LISP-ALT [RFC6836] is
already calling to use BGP as a mapping plane protocol to simplify
initial deployment. While it is foreseen that in the future those
may migrate to better distribution schemes for example LISP-DHT to
get enough of initial traction and momentum a Multi Instance BGP
seems like a very good match to the mapping plane requirements.
One may observe that Service Providers may choose to deploy a new
instances of BGP to carry their critical services (example L3VPNs)
over it for full isolation from Internet BGP. In such application
they will be able to prioritize such instance according to their
internal policy and offered services prioritization.
8. Security considerations
Multi Instance BGP proposed in this document does not introduce any
new security concerns as compared to base BGP4 specification
[RFC4271]. Also all security work applicable to base routing
instance BGP does also apply as is to transport instance BGP.
Raszuk Expires April 25, 2019 [Page 6]
Internet-Draft mi-bgp October 2018
9. IANA Considerations
This document presents no requirements to IANA.
10. Acknowledgments
The authors would like to thank Randy Bush, Tom Scholl and Joel
Halpern for their valuable comments provided to the parent document -
BGP Transport Instance.
11. References
11.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,
<https://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,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
11.2. Informative References
[I-D.ietf-idr-advisory]
Scholl, T., Scudder, J., Steenbergen, R., and D. Freedman,
"BGP Advisory Message", draft-ietf-idr-advisory-00 (work
in progress), October 2009.
[I-D.ietf-idr-bgp-multisession]
Scudder, J., Appanna, C., and I. Varlashkin, "Multisession
BGP", draft-ietf-idr-bgp-multisession-07 (work in
progress), September 2012.
Raszuk Expires April 25, 2019 [Page 7]
Internet-Draft mi-bgp October 2018
[I-D.ietf-ospf-transport-instance]
Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport
Instance Extensions", draft-ietf-ospf-transport-
instance-11 (work in progress), June 2014.
[I-D.raszuk-idr-bgp-auto-discovery]
Raszuk, R., Mitchell, J., Kumari, W., Patel, K., and J.
Scudder, "BGP Auto Discovery", draft-raszuk-idr-bgp-auto-
discovery-05 (work in progress), May 2016.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <https://www.rfc-editor.org/info/rfc4684>.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512,
DOI 10.17487/RFC5512, April 2009,
<https://www.rfc-editor.org/info/rfc5512>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
Raszuk Expires April 25, 2019 [Page 8]
Internet-Draft mi-bgp October 2018
Author's Address
Robert Raszuk (editor)
Bloomberg LP
731 Lexington Ave
New York, NY 10022
US
Email: robert@raszuk.net
Raszuk Expires April 25, 2019 [Page 9]
