diff --git a/draft-ymbk-bgp-discovery-layers.txt b/draft-ymbk-bgp-discovery-layers.txt new file mode 100644 index 0000000..3222c09 --- /dev/null +++ b/draft-ymbk-bgp-discovery-layers.txt @@ -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, + . + +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] diff --git a/draft-ymbk-bgp-discovery-layers.xml b/draft-ymbk-bgp-discovery-layers.xml new file mode 100644 index 0000000..0a3c090 --- /dev/null +++ b/draft-ymbk-bgp-discovery-layers.xml @@ -0,0 +1,413 @@ + + + + + + + + + + + + + + + + + + Trade-offs in BGP Peer Discovery + + + Arrcus, Inc. & Internet Initiative Japan +
+ + 5147 Crystal Springs + Bainbridge Island + Washington + 98110 + US + + randy@psg.com +
+ + + + + + + + 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. + + + + + + + + +
+ + + 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. + + +
+ +
+ + + Previous design team discussions converged on a number of aspects + of the problem. + + +
+ + + The assumedenvironment has BGP used as the underlay routing + protocol in data center. + + +
+ +
+ + + Some requirements have been agreed by the design team as + follows: + + + + + Support IPv4 and IPv6 address families, but do not assume + both are available. + + + Support discovery of the peering addresses for the BGP + session endpoints. + + + Support using either a device's external interface or one of + its loopback addresses for the BGP session endpoint. + + + Support discoverery of the peers' ASs. + + + Agree on any BGP session authentication and parameters. + + + Enable Layer 3 link liveness detection, such as BFD. + + + +
+ +
+ + + 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. + + +
+ +
+ +
+ + + 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. + + +
+ +
+ + + In discovery, an aspiring BGP speaker needs to discover: + + + + + + The set of possible peers, + + + + To start, discovery does not know the potential peers' layer + three IP addresses. + + + + 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. + + + + Each one's layer three peering address(es), and + + + + Other attributes required for BGP OPEN to succeed, e.g. + authentication data. + + + + + +
+ +
+ + + Operator configuration should be able to decide at lest the + following: + + + + + + Select or otherwise filter which peers to actually try to BGP + OPEN, + + + + What parameters to use, e.g.: + + + + + + + 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. + + + + + + + + +
+ +
+ + + What are the criteria for success and failure of the design + decisions, and how do we measure them? + + +
+ +
+ + + 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 . + + +
+ + + 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. + + +
+ +
+ + + 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. + + +
+ +
+ +
+ + + 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 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. + + +
+ +
+ + + Peer discovery at Layer-7 requires application layer rendezcous + mechanisms analogous to those used by LISP, 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. + + +
+ +
+ + None yet, but there will be many. + +
+ +
+ + The IDR BGP Discovery Design Team. + +
+ +
+ + None + +
+ + + + + + + + + + + + + +
+ + The authors wish to thank . + +
+ + + + diff --git a/draft-ymbk-bgp-discovery-layers.yml b/draft-ymbk-bgp-discovery-layers.yml deleted file mode 100644 index aa451d9..0000000 --- a/draft-ymbk-bgp-discovery-layers.yml +++ /dev/null @@ -1,188 +0,0 @@ - - - - - - - - - - - - - - - - - BGP RPKI-Based Origin Validation on Export - - - Internet Initiative Japan & Arrcus -
- - 5147 Crystal Springs - Bainbridge Island - Washington - 98110 - US - - randy@psg.com -
- - - - Deutsche Telekom - - - - Cisco -
- - 170 West Tasman Drive - San Jose - CA - 95134 - USA - - jheitz@cisco.com -
- - - - - - - 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. - - - - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" - are to be interpreted as described in only - when they appear in all upper case. They may also appear in lower - or mixed case as English words, without normative meaning. - - - - - - - -
- - This document does not change the protocol or semantics of 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. - - 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. - - 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. - -
- -
- - It is assumed that the reader understands BGP, , the RPKI, , Route Origin - Authorizations (ROAs), , RPKI-based - Prefix Validation, , and Origin Validation - Clarifications, . - -
- -
- - 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. - - 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. - -
- -
- - 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. - - 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. - -
- -
- - This document does not create security considerations beyond - those of and . - -
- -
- - This document has no IANA Considerations. - - -
- - - - - - - - - - - - - - - - - - - - - -