randy/draft-bgp-discovery-layers
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

a first cut from notes

Browse source
This commit is contained in:
Randy Bush 2020-05-25 15:06:19 -07:00
parent 7114ee4aed
commit 0ba265ab8c
3 changed files with 749 additions and 188 deletions
Download patch file Download diff file Expand all files Collapse all files

336
draft-ymbk-bgp-discovery-layers.txt Normal file
View file

@ -0,0 +1,336 @@
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]

413
draft-ymbk-bgp-discovery-layers.xml Normal file
View 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. &amp; 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>

188
draft-ymbk-bgp-discovery-layers.yml
View file

@ -1,188 +0,0 @@
<?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="std" docName="draft-ietf-sidrops-ov-egress-00" updates="6811" ipr="trust200902">
<front>
<title>BGP RPKI-Based Origin Validation on Export</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Internet Initiative Japan &amp; Arrcus</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>
<author fullname="Rüdiger Volk" initials="R." surname="Volk">
<organization>Deutsche Telekom</organization>
</author>
<author fullname="Jakob Heitz" initials="J. " surname="Heitz">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>jheitz@cisco.com</email>
</address>
</author>
<date />
<abstract>
<t>A BGP speaker may perform RPKI origin validation not only on
routes received from BGP neighbors and routes that are redistributed
from other routing protocols, but also on routes it sends to BGP
neighbors. For egress policy, it is important that the
classification uses the effective origin AS of the processed route,
which may specifically be altered by the commonly available knobs
such as removing private ASs, confederation handling, and other
modifications of the origin AS.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in <xref target="RFC2119"/> only
when they appear in all upper case. They may also appear in lower
or mixed case as English words, without normative meaning.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document does not change the protocol or semantics of <xref
target="RFC6811"/> of RPKI-based origin validation. It highlights
an important use case of origin validation in eBGP egress policies,
explaining specifics of correct implementation in this context.</t>
<t>As the origin AS may be modified by outbound policy, policy
semantics based on RPKI Origin Validation state MUST be able to be
applied separately on distribution into BGP and on egress.</t>
<t>When applied to egress policy, the effective origin AS MUST be
used to determine the Origin Validation state. The effective origin
AS is that which will actually be the origin AS in the announcement.
It might be affected by removal of private AS(s), confederation, AS
migration, etc. If there are any AS_PATH modifications resulting in
origin AS change, then these MUST be taken into account.</t>
</section>
<section anchor="reading" title="Suggested Reading">
<t>It is assumed that the reader understands BGP, <xref
target="RFC4271"/>, the RPKI, <xref target="RFC6480"/>, Route Origin
Authorizations (ROAs), <xref target="RFC6482"/>, RPKI-based
Prefix Validation, <xref target="RFC6811"/>, and Origin Validation
Clarifications, <xref target="RFC8481"/>.</t>
</section>
<section anchor="all" title="Egress Processing">
<t>BGP implementations supporting RPKI-based origin validation
SHOULD provide the same policy configuration primitives for
decisions based on validation state available for use in ingress,
redistribution, and egress policies. When applied to egress policy,
validation state MUST be determined using the effective origin AS of
the route as it will (or would) be announced to the peer. The
effective origin AS may differ from that of the route in the RIB due
to commonly available knobs such as: removal of private ASs, AS path
manipulation, confederation handling, etc.</t>
<t>Egress policy handling can provide more robust protection for
outbound eBGP than relying solely on ingress (iBGP, eBGP, connected,
static, etc.) redistribution being configured and working correctly
- better support for the robustness principle.</t>
</section>
<section anchor="impl" title="Operational Considerations">
<t>Configurations may have complex policy where the final announced
origin AS may not be easily predicted before all policies have been
run. Therefore it SHOULD be possible to specify an origin
validation policy which MUST BE run after such non-deterministic
policies.</t>
<t>An operator SHOULD be able to list what announcements are not
sent to a peer because they were marked Invalid, as long as the
router still has them in memory.</t>
</section>
<section anchor="seccons" title="Security Considerations">
<t>This document does not create security considerations beyond
those of <xref target="RFC6811"/> and <xref target="RFC8481"/>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document has no IANA Considerations.</t>
<!--
<t>Note to RFC Editor: this section may be replaced on publication
as an RFC.</t>
-->
</section>
<!--
<section anchor="acks" title="Acknowledgments">
<t>Many thanks to John Scudder who had the patience to give
constructive review multiple times, and to Keyur Patel who noted
that the AS might have to be specified.</t>
</section>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.6482"?>
<?rfc include="reference.RFC.6811"?>
<?rfc include="reference.RFC.8481"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.RFC.6480"?>
</references>
</back>
</rfc>