Internet DRAFT - draft-raszuk-idr-bgp-auto-session-setup
draft-raszuk-idr-bgp-auto-session-setup
IDR Working Group R. Raszuk, Ed.
Internet-Draft Bloomberg LP
Intended status: Standards Track December 8, 2019
Expires: June 10, 2020
BGP Automated Session Setup
draft-raszuk-idr-bgp-auto-session-setup-01
Abstract
This document proposes a solution for BGP deployments in some
specific environments to automatically establish BGP sessions without
need for manual peer configuration.
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 June 10, 2020.
Copyright Notice
Copyright (c) 2019 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
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.
Raszuk Expires June 10, 2020 [Page 1]
Internet-Draft draft-raszuk-idr-bgp-auto-session-setup December 2019
Table of Contents
1. Definitions of Terms Used in This Memo . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 2
4. Loopbacks reachability bootstrapping . . . . . . . . . . . . 3
5. ECMP routes recursion . . . . . . . . . . . . . . . . . . . . 4
6. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Advantages to alternative proposals . . . . . . . . . . . . . 4
8. Changes to BGP Finite State Machine . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
12.1. Normative References . . . . . . . . . . . . . . . . . . 5
12.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Definitions of Terms Used in This Memo
NLRI - Network Layer Reachability Information.
RIB - Routing Information Base.
AS - Autonomous System number.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Introduction
The popularity of use of BGP in number of data centers or campus
deployments where BGP is being used as/instead of IGP brings
operational challenges associated with setup of BGP peering relations
This proposal aims on automating the BGP session bring-up without
aprior knowledge of the peer's IP addresses by use of existing BGP
protocol.
3. Proposed Solution
When BGP attempts to establish the EBGP sessions with unknown peers
router will start sending BGP Session Explorer (BSE) packets which
are to be regular BGP session establishment packets containing plain
BGP OPEN Message except instead of regular peer address a multicast
Raszuk Expires June 10, 2020 [Page 2]
Internet-Draft draft-raszuk-idr-bgp-auto-session-setup December 2019
address will be used 224.0.0.2 "All Routers on this Subnet" as UDP
destination address. Destination port of this UDP packets is to be
assigned by IANA. Source address will be selected by the operator
either local interface address (when establishing plain p2p relation)
or loopback address (when establishing peering between loopback
addresses).
Authors leave this as open discussion point to use instead of well
known multicast address of 224.0.0.2 a new IANA assigned multicast
address dedicated for the purpose of BGP Auto Session Setup.
Unidirectional reception of BGP Session Explorers will allow for peer
to respond with standard unicast TCP BGP OPEN Message using
destination address indicated previously as source address of BSE
packets. Source address in the BGP OPEN Message attempt will be
peer's local operator's selected source address.
The above procedure will allow for automated BGP session bring-up
without aprior knowledge of the peer's BGP peering address for any
AFI/SAFI.
BGP Sessions Explorers are unidirectional and only are to be sent out
on those interfaces where there is no direct EBGP session established
on or which would be otherwise used as recursive members of L3 group
of parallel links with already recursive routes installed to
corresponding EBGP session between loopback addresses.
4. Loopbacks reachability bootstrapping
Upon reception of BGP Session Explorer packet on a BGP designated
port BGP will parse the BGP OPEN Message in an informational mode to
record peer's interest in EBGP session establishment. However at
this point there is an assumption that loopback addresses are
unreachable on both sides. When session is p2p session over
connected interface the reachability to session endpoints is by
default in place and no further work is needed.
In the case of loopbacks after successful parsing of BGP Session
Explorer packets BGP is to install in RIB BGP reachability towards
the source address of the BSE source address with the outgoing
interface BSE packet arrived on.
Such reachability is of temporary nature till BGP session is
established between peers and peers exchange in their corresponding
BGP UPDATE Messages loopback reachability with at least one next hop
belonging to local connected address.
Raszuk Expires June 10, 2020 [Page 3]
Internet-Draft draft-raszuk-idr-bgp-auto-session-setup December 2019
It is recommended that in the event of no session being established
such temporary reachability will time out after configurable timer
interval (default 180 seconds).
5. ECMP routes recursion
The described session establishment process will result in either
point to point EBGP sessions or EBGP sessions between loopback
addresses.
In the former case the direct point to point connected subnet is used
as peering address and there is no need for any additional
procedures.
In the case however when peering is established between loopbacks -
typically the case in the ECMP based deployments when multiple L3
interface interconnect given pair of routers the loopback address
used both as peering address and next hop of advertised routes need
to recursively resolve via all directly connected subnets in order to
effectively perform load balancing of traffic. For this task authors
recommend regular BGP UPDATE Message to be used along with new BGP
ATTRIBUTE MULTIPLE_HOP containing the list of all connected local
addresses configured to be used as ECMP paths towards non connected
next hop. The detailed proposal for this attribute has been
described in the former work: draft-bhatia-bgp-multiple-next-hops
[I-D.bhatia-bgp-multiple-next-hops].
An alternative methods for learning connected addresses towards not
connected next hop can also be used. The choice of methods of
accomplishing this reachability propagation is purposely made out of
scope of this specification allowing both operator's choice as well
as technology evolution in this space.
6. Scalability
Parsing received to port 179 TCP packets and fixed size BGP OPEN
Messages from all potential EBGP peers in applicable deployment
scenarios of the target space of this proposal may result in very
limited and contained need for additional processing. When port 179
is not open BGP OPEN Messages will be dropped. Upon establishing BGP
session no new BGP OPEN Messages will be send on a given subnet.
7. Advantages to alternative proposals
The solutions described does not require any new message on the wire
other then standard BGP OPEN Message already defined in other
documents.
Raszuk Expires June 10, 2020 [Page 4]
Internet-Draft draft-raszuk-idr-bgp-auto-session-setup December 2019
The proposed solution does not require any extra efforts for route
installation in RIB and FIB other then via standard BGP route
insertion and deletion procedures.
The proposed solutions reuses all of the existing BGP mechanisms in
the space of session establishment and session maintenance and does
not result in any race conditions or conflicts between existing and
new procedures.
The proposed solution by its design does not allow any additional
functionality like interface_ids or node/link topology discovery as
it is authors believe that there are much better methods to
accomplish those tasks outside of BGP protocol.
8. Changes to BGP Finite State Machine
The following changes to BGP FSM are proposed:
To be completed when/if document gets traction in the WG.
9. Security Considerations
No new security issues are introduced to the BGP protocol by this
specification.
All operational security procedures which are applicable to standard
BGP operation apply here.
It is highly recommended that TCP authentication when establishing
unicast TCP sessions is used.
10. IANA Considerations
This document request IANA to allocate UDP port number for BGP
Session Explorer messages.
11. Acknowledgments
Authors would like to thank ... for their valuable input.
12. References
12.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>.
Raszuk Expires June 10, 2020 [Page 5]
Internet-Draft draft-raszuk-idr-bgp-auto-session-setup December 2019
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.bhatia-bgp-multiple-next-hops]
Bhatia, M., "Advertising Multiple NextHop Routes in BGP",
draft-bhatia-bgp-multiple-next-hops-01 (work in progress),
August 2006.
Author's Address
Robert Raszuk (editor)
Bloomberg LP
731 Lexington Ave
New York City, NY 10022
USA
Email: robert@raszuk.net
Raszuk Expires June 10, 2020 [Page 6]
