a first cut from notes
This commit is contained in:
parent
7114ee4aed
commit
0ba265ab8c
3 changed files with 749 additions and 188 deletions
413
draft-ymbk-bgp-discovery-layers.xml
Normal file
413
draft-ymbk-bgp-discovery-layers.xml
Normal file
|
|
@ -0,0 +1,413 @@
|
|||
<?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-00" updates="6811" 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 assumedenvironment 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 discoverery 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 dependednt. 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.:
|
||||
</t>
|
||||
|
||||
<t>
|
||||
<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>
|
||||
|
||||
</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>
|
||||
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 ...
|
||||
</t>
|
||||
|
||||
<t>
|
||||
Unlike LLDP, L3DL has only one implementation and is not widely
|
||||
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 simiar 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 rendezcous
|
||||
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.ietf-lsvr-l3dl"?>
|
||||
</references>
|
||||
|
||||
<!--
|
||||
<references title="Informative References">
|
||||
</references>
|
||||
-->
|
||||
|
||||
<section anchor="Acknowledgements" title="Acknowledgements">
|
||||
<t>
|
||||
The authors wish to thank .
|
||||
</t>
|
||||
</section>
|
||||
|
||||
</back>
|
||||
|
||||
</rfc>
|
||||
Loading…
Add table
Add a link
Reference in a new issue