478 lines
12 KiB
XML
478 lines
12 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
|
<?rfc comments="yes"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc inline="yes"?>
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc subcompact="yes"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="no"?>
|
|
<?rfc tocdepth="3"?>
|
|
<?rfc tocindent="yes"?>
|
|
<?rfc tocompact="yes"?>
|
|
|
|
<rfc category="info" docName="draft-ymbk-bgp-discovery-layers-01" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title>Trade-offs in BGP Peer Discovery</title>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>Arrcus, Inc. & Internet Initiative Japan</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>Washington</region>
|
|
<code>98110</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
</abstract>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="Intro" title="Introduction">
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="background" title="Background">
|
|
|
|
<t>
|
|
Previous design team discussions converged on a number of aspects
|
|
of the problem.
|
|
</t>
|
|
|
|
<section anchor="underlay" title="BGP is the Underlay">
|
|
|
|
<t>
|
|
The assumed environment has BGP used as the underlay routing
|
|
protocol in data center.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="reqs" title="Some Requirements">
|
|
|
|
<t>
|
|
Some requirements have been agreed by the design team as
|
|
follows:
|
|
</t>
|
|
<t>
|
|
<list style="symbols">
|
|
<t>
|
|
Support IPv4 and IPv6 address families, but do not assume
|
|
both are available.
|
|
</t>
|
|
<t>
|
|
Support discovery of the peering addresses for the BGP
|
|
session endpoints.
|
|
</t>
|
|
<t>
|
|
Support using either a device's external interface or one of
|
|
its loopback addresses for the BGP session endpoint.
|
|
</t>
|
|
<t>
|
|
Support discovery of the peers' ASs.
|
|
</t>
|
|
<t>
|
|
Agree on any BGP session authentication and parameters.
|
|
</t>
|
|
<t>
|
|
Enable Layer 3 link liveness detection, such as BFD.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="simplicity" title="Simplicity">
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
Simplicity is key. Features not absolutely needed will not be
|
|
included in the design.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section anchor="assumptions" title="Assumptions">
|
|
|
|
<t>
|
|
BGP OPEN will do the heavy lifting.
|
|
</t>
|
|
|
|
<t>
|
|
BGP discovery should not do anything that could be done by BGP
|
|
OPEN. Two sources of the same data are a recipe for errors.
|
|
</t>
|
|
|
|
<t>
|
|
BGP peering will be selective; every BGP speaker may not want to
|
|
peer with every other speaker.
|
|
</t>
|
|
|
|
<t>
|
|
Before BGP OPEN, there is discovery and there is choosing peers.
|
|
</t>
|
|
|
|
<t>
|
|
After discovery, it would be nice if another exchange was not
|
|
needed before BGP OPEN.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="needs" title="Needs of Discovery">
|
|
|
|
<t>
|
|
In discovery, an aspiring BGP speaker needs to discover:
|
|
</t>
|
|
<t>
|
|
<list style="symbols">
|
|
|
|
<t>
|
|
The set of possible peers,
|
|
</t>
|
|
|
|
<t>
|
|
To start, discovery does not know the potential peers' layer
|
|
three IP addresses.
|
|
</t>
|
|
|
|
<t>
|
|
Each one's attributes, a deployment defined set, e.g.: leaf,
|
|
spine, ice cream flavor, ... These attributes are arbitrary
|
|
and operator dependent. No assumptions should be made, code
|
|
points assigned,, etc.
|
|
</t>
|
|
|
|
<t>
|
|
Each one's layer three peering address(es), and
|
|
</t>
|
|
|
|
<t>
|
|
Other attributes required for BGP OPEN to succeed, e.g.
|
|
authentication data.
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="op-config" title="Operator Configuration">
|
|
|
|
<t>
|
|
Operator configuration should be able to decide at lest the
|
|
following:
|
|
</t>
|
|
<t>
|
|
<list style="symbols">
|
|
|
|
<t>
|
|
Select or otherwise filter which peers to actually try to BGP
|
|
OPEN,
|
|
</t>
|
|
|
|
<t>
|
|
What parameters to use, e.g.:
|
|
|
|
<list style="symbols">
|
|
|
|
<t>
|
|
IP addressing: IPv4, IPv6, Loopback, or Direct
|
|
</t>
|
|
|
|
<t>
|
|
Any special forwarding or routing needed for reaching the
|
|
prospective peer, e.g., loopback,
|
|
</t>
|
|
|
|
<t>
|
|
AS numbering, and
|
|
</t>
|
|
|
|
<t>
|
|
BGP Authentication Options.
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="success" title="Success Criteria">
|
|
|
|
<t>
|
|
What are the criteria for success and failure of the design
|
|
decisions, and how do we measure them?
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="layer2" title="Discovery at Layer Two">
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
There are two available candidates for peer discovery at Layer-2,
|
|
Link Layer Discovery Protocol, LLDP, and Layer 3 Discovery
|
|
Protocol, L3DL <xref target="I-D.ietf-lsvr-l3dl"/>.
|
|
</t>
|
|
|
|
<section anchor="lldp" title="Link Layer Discovery Protocol (LLDP)">
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
<xref target="I-D.acee-idr-lldp-peer-discovery"/> describes how
|
|
to use the LLDP IETF Organizationally Specific TLV to augment
|
|
the LLDP TLV set to transport BGP Config Sub-TLVs signaling
|
|
</t>
|
|
<t>
|
|
<list style="symbols">
|
|
<t>
|
|
AFI,
|
|
</t>
|
|
<t>
|
|
IP address (IPv4 or IPv6),
|
|
</t>
|
|
<t>
|
|
Local ASs,
|
|
</t>
|
|
<t>
|
|
Local BGP Identifier (AKA, BGP Router ID),
|
|
</t>
|
|
<t>
|
|
Session Group-ID,
|
|
</t>
|
|
<t>
|
|
BGP [Authentication] Session Capabilities, and
|
|
</t>
|
|
<t>
|
|
Local Address (Next Hop).
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Which of these are really necessary could be discussed.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="l3dl" title="Layer-3 Discovery Protocol (L3DL)">
|
|
|
|
<t>
|
|
L3DL <xref target="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.
|
|
</t>
|
|
|
|
<t>
|
|
L3DL Upper Layer Protocol Configuration, <xref
|
|
target="I-D.ietf-lsvr-l3dl-ulpc"/>, details signaling the
|
|
minimal set of parameters needed to start a BGP session with a
|
|
discovered peer. Details such as loopback peering are handled
|
|
by attributes in the L3DL protocol itself.
|
|
</t>
|
|
<t>
|
|
<list style="symbols">
|
|
<t>
|
|
AS number,
|
|
</t>
|
|
<t>
|
|
IP address, IPv4 or IPv6, and
|
|
</t>
|
|
<t>
|
|
BGP Authentication.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
L3DL and L3DL-ULPC have well-specified security mechanisms, see
|
|
<xref target="I-D.ietf-lsvr-l3dl-signing"/>.
|
|
</t>
|
|
|
|
<t>
|
|
This is similar but not quite the same as the needs of this IDR
|
|
Design Team. E.g., L3DL is designed to meet more complex needs.
|
|
L3DL's predecessor, LSOE, <xref target="I-D.ietf-lsvr-lsoe"/>,
|
|
was simpler and might be a better candidate for adaptation. A
|
|
week's work could customize the design for the IDR Design Team's
|
|
needs. But ...
|
|
</t>
|
|
|
|
<t>
|
|
Unlike LLDP, L3DL has only one implementation, and LSOE only one
|
|
open source implementation, and neither is significantly
|
|
deployed.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section anchor="layer3" title="Discovery at Layer Three">
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
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 local subnet, and hence broadcast and similar techniques may
|
|
not be applicable.
|
|
</t>
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
For switched or bridged multi-point which is at least on the same
|
|
subnet, VLAN, etc., broadcasts might be a viable approach.
|
|
</t>
|
|
|
|
<t>
|
|
There will be difficulty if one or both peers wish to use a
|
|
loopback for peering.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="layer7" title="Discovery at Layer Seven">
|
|
|
|
<t>
|
|
Peer discovery at Layer-7 requires application layer rendezvous
|
|
mechanisms analogous to those used by LISP, <xref
|
|
target="RFC6830"/> or the Bitcoin Protocol.
|
|
</t>
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
Rendezvous approaches may appeal to deployments which favor a
|
|
central control framework.
|
|
</t>
|
|
|
|
<t>
|
|
On the other hand, those who favor distributed protocols will have
|
|
the classic worries about fragility, redundancy, reliability, etc.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="seccons" title="Security Considerations">
|
|
<t>
|
|
None yet, but there will be many.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="acks" title="Acknowledgments">
|
|
<t>
|
|
The IDR BGP Discovery Design Team.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="IANA" title="IANA Considerations">
|
|
<t>
|
|
None
|
|
</t>
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<!--
|
|
[IEEE8021AB]
|
|
IEEE, "IEEE Standard for Local and Metropolitan Area
|
|
Networks - Station and Media Access Control Connectivity
|
|
Discovery", IEEE 802.1AB.
|
|
-->
|
|
<?rfc include="reference.RFC.6830"?>
|
|
<?rfc include="reference.I-D.acee-idr-lldp-peer-discovery"?>
|
|
<?rfc include="reference.I-D.ietf-lsvr-l3dl"?>
|
|
<?rfc include="reference.I-D.ietf-lsvr-l3dl-ulpc"?>
|
|
<?rfc include="reference.I-D.ietf-lsvr-l3dl-signing"?>
|
|
<?rfc include="reference.I-D.ietf-lsvr-lsoe"?>
|
|
</references>
|
|
|
|
<!--
|
|
<references title="Informative References">
|
|
</references>
|
|
-->
|
|
|
|
<section anchor="Acknowledgements" title="Acknowledgements">
|
|
<t>
|
|
The authors wish to thank .
|
|
</t>
|
|
</section>
|
|
|
|
</back>
|
|
|
|
</rfc>
|