336 lines
9.7 KiB
Text
336 lines
9.7 KiB
Text
|
||
|
||
|
||
|
||
Network Working Group R. Bush
|
||
Internet-Draft Arrcus, Inc. & Internet Initiative Japan
|
||
Updates: 6811 (if approved) May 25, 2020
|
||
Intended status: Informational
|
||
Expires: November 26, 2020
|
||
|
||
|
||
Trade-offs in BGP Peer Discovery
|
||
draft-ymbk-bgp-discovery-layers-00
|
||
|
||
Abstract
|
||
|
||
This draft is an exploration of the alternatives and trade-offs in
|
||
BGP peer discovery at various layers in the stack. It is based on
|
||
discussions in the IDR WG BGP Discovery Design Team. The current
|
||
target environment is the datacenter; while keeping an eye not to
|
||
preclude WAN deployment. This document is not intended to become an
|
||
RFC.
|
||
|
||
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 November 26, 2020.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2020 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
|
||
|
||
|
||
|
||
Bush Expires November 26, 2020 [Page 1]
|
||
|
||
Internet-Draft Trade-offs in BGP Peer Discovery May 2020
|
||
|
||
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
1. Introduction
|
||
|
||
This draft is an exploration of the alternatives and trade-offs in
|
||
BGP peer discovery at various layers in the stack. It is based on
|
||
discussions in the IDR WG BGP Discovery Design Team. The current
|
||
target environment is the datacenter; while keeping an eye not to
|
||
preclude WAN deployment. This document is not intended to become an
|
||
RFC.
|
||
|
||
2. Background
|
||
|
||
Previous design team discussions converged on a number of aspects of
|
||
the problem.
|
||
|
||
2.1. BGP is the Underlay
|
||
|
||
The assumedenvironment has BGP used as the underlay routing protocol
|
||
in data center.
|
||
|
||
2.2. Some Requirements
|
||
|
||
Some requirements have been agreed by the design team as follows:
|
||
|
||
o Support IPv4 and IPv6 address families, but do not assume both are
|
||
available.
|
||
o Support discovery of the peering addresses for the BGP session
|
||
endpoints.
|
||
o Support using either a device's external interface or one of its
|
||
loopback addresses for the BGP session endpoint.
|
||
o Support discoverery of the peers' ASs.
|
||
o Agree on any BGP session authentication and parameters.
|
||
o Enable Layer 3 link liveness detection, such as BFD.
|
||
|
||
2.3. Simplicity
|
||
|
||
The goal is to provide the minimal set of configuration parameters
|
||
needed by BGP OPEN to successfully start a BGP peering. The goal is
|
||
specifically not to replace or conflict with data exchanged during
|
||
BGP OPEN. Multiple sources of truth are a recipe for complexity and
|
||
hence painful errors.
|
||
|
||
Simplicity is key. Features not absolutely needed will not be
|
||
included in the design.
|
||
|
||
|
||
|
||
|
||
|
||
Bush Expires November 26, 2020 [Page 2]
|
||
|
||
Internet-Draft Trade-offs in BGP Peer Discovery May 2020
|
||
|
||
|
||
3. Assumptions
|
||
|
||
BGP OPEN will do the heavy lifting.
|
||
|
||
BGP discovery should not do anything that could be done by BGP OPEN.
|
||
Two sources of the same data are a recipe for errors.
|
||
|
||
BGP peering will be selective; every BGP speaker may not want to peer
|
||
with every other speaker.
|
||
|
||
Before BGP OPEN, there is discovery and there is choosing peers.
|
||
|
||
After discovery, it would be nice if another exchange was not needed
|
||
before BGP OPEN.
|
||
|
||
4. Needs of Discovery
|
||
|
||
In discovery, an aspiring BGP speaker needs to discover:
|
||
|
||
o The set of possible peers,
|
||
o To start, discovery does not know the potential peers' layer three
|
||
IP addresses.
|
||
o Each one's attributes, a deployment defined set, e.g.: leaf,
|
||
spine, ice cream flavor, ... These attributes are arbitrary and
|
||
operator dependednt. No assumptions should be made, code points
|
||
assigned,, etc.
|
||
o Each one's layer three peering address(es), and
|
||
o Other attributes required for BGP OPEN to succeed, e.g.
|
||
authentication data.
|
||
|
||
5. Operator Configuration
|
||
|
||
Operator configuration should be able to decide at lest the
|
||
following:
|
||
|
||
o Select or otherwise filter which peers to actually try to BGP
|
||
OPEN,
|
||
o What parameters to use, e.g.:
|
||
o
|
||
|
||
* IP addressing: IPv4, IPv6, Loopback, or Direct
|
||
* Any special forwarding or routing needed for reaching the
|
||
prospective peer, e.g., loopback,
|
||
* AS numbering, and
|
||
* BGP Authentication Options.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bush Expires November 26, 2020 [Page 3]
|
||
|
||
Internet-Draft Trade-offs in BGP Peer Discovery May 2020
|
||
|
||
|
||
6. Success Criteria
|
||
|
||
What are the criteria for success and failure of the design
|
||
decisions, and how do we measure them?
|
||
|
||
7. Discovery at Layer Two
|
||
|
||
BGP Discovery at Layer-2 would entail finding potential peers on a
|
||
LAN or on Point-to-Point links, discovering their Layer-3 attributes
|
||
such as IP addresses, etc.
|
||
|
||
There are two available candidates for peer discovery at Layer-2,
|
||
Link Layer Discovery Protocol, LLDP, and Layer 3 Discovery Protocol,
|
||
L3DL [I-D.ietf-lsvr-l3dl].
|
||
|
||
7.1. Link Layer Discovery Protocol (LLDP)
|
||
|
||
LLDP is a widely deployed protocol with implementations for most
|
||
devices. Unfortunately it does not currently reveal Layer-3 IP
|
||
addresses. There is an early LLDPv2 development to extend it in
|
||
IEEE.
|
||
|
||
7.2. Layer-3 Discovery Protocol (L3dl)
|
||
|
||
L3DL [I-D.ietf-lsvr-l3dl] is an ongoing development in the IETF LSVR
|
||
Working Group with the goals of discovering IP Layer-3 attributes of
|
||
links, such as neighbor IP addressing, logical link IP encapsulation
|
||
abilities, and link liveness which may then be disseminated using
|
||
BGP-SPF and similar protocols.
|
||
|
||
This is similar but not quite the sane as the needs of this IDR
|
||
Design Team. E.g., the result is likely more complex than is needed.
|
||
A week's work could customize the design for the IDR Design Team's
|
||
needs. But ...
|
||
|
||
Unlike LLDP, L3DL has only one implementation and is not widely
|
||
deployed.
|
||
|
||
8. Discovery at Layer Three
|
||
|
||
Discovery at Layer-3 can assume IP addressability, though the IP
|
||
addresses of potential peers are not known a priori and need to be
|
||
discovered before further negotiation.
|
||
|
||
The principal problem would appear to be discovery at Layer-3,
|
||
because one neither knows whether to use IPv4 or IPv6. This is
|
||
exacerbated by the possibility of a potential peer not being on the
|
||
|
||
|
||
|
||
|
||
Bush Expires November 26, 2020 [Page 4]
|
||
|
||
Internet-Draft Trade-offs in BGP Peer Discovery May 2020
|
||
|
||
|
||
local subnet, and hence broadcast and simiar techniques may not be
|
||
applicable.
|
||
|
||
If one can assume point-to-point links , then discovery might try
|
||
IPv6 link-local or even IPv4 link-local. Or maybe a link broadcast
|
||
protocol.
|
||
|
||
For switched or bridged multi-point which is at least on the same
|
||
subnet, VLAN, etc., broadcasts might be a viable approach.
|
||
|
||
There will be difficulty if one or both peers wish to use a loopback
|
||
for peering.
|
||
|
||
9. Discovery at Layer Seven
|
||
|
||
Peer discovery at Layer-7 requires application layer rendezcous
|
||
mechanisms analogous to those used by LISP, [RFC6830] or the Bitcoin
|
||
Protocol.
|
||
|
||
If the infrastructure is at all complex, e.g. multi-segment or worse,
|
||
then it will need prior routing/forwarding knowledge in order to
|
||
reach the rendezvous. In a BGP centric deployment this could pose a
|
||
chicken and egg problem.
|
||
|
||
Rendezvous approaches may appeal to deployments which favor a central
|
||
control framework.
|
||
|
||
On the other hand, those who favor distributed protocols will have
|
||
the classic worries about fragility, redundancy, reliability, etc.
|
||
|
||
10. Security Considerations
|
||
|
||
None yet, but there will be many.
|
||
|
||
11. Acknowledgments
|
||
|
||
The IDR BGP Discovery Design Team.
|
||
|
||
12. IANA Considerations
|
||
|
||
None
|
||
|
||
13. Normative References
|
||
|
||
[I-D.ietf-lsvr-l3dl]
|
||
Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery
|
||
and Liveness", draft-ietf-lsvr-l3dl-04 (work in progress),
|
||
May 2020.
|
||
|
||
|
||
|
||
Bush Expires November 26, 2020 [Page 5]
|
||
|
||
Internet-Draft Trade-offs in BGP Peer Discovery May 2020
|
||
|
||
|
||
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
|
||
Locator/ID Separation Protocol (LISP)", RFC 6830,
|
||
DOI 10.17487/RFC6830, January 2013,
|
||
<https://www.rfc-editor.org/info/rfc6830>.
|
||
|
||
Appendix A. Acknowledgements
|
||
|
||
The authors wish to thank .
|
||
|
||
Author's Address
|
||
|
||
Randy Bush
|
||
Arrcus, Inc. & Internet Initiative Japan
|
||
5147 Crystal Springs
|
||
Bainbridge Island, Washington 98110
|
||
US
|
||
|
||
Email: randy@psg.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bush Expires November 26, 2020 [Page 6]
|