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 assumed environment 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 discovery 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 dependent. 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. describes how to use the LLDP IETF Organizationally Specific TLV to augment the LLDP TLV set to transport BGP Config Sub-TLVs signaling AFI, IP address (IPv4 or IPv6), Local ASs, Local BGP Identifier (AKA, BGP Router ID), Session Group-ID, BGP [Authentication] Session Capabilities, and Local Address (Next Hop). Which of these are really necessary could be discussed.

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. L3DL Upper Layer Protocol Configuration, , 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. AS number, IP address, IPv4 or IPv6, and BGP Authentication. L3DL and L3DL-ULPC have well-specified security mechanisms, see . This is similar but not quite the sane as the needs of this IDR Design Team. E.g., L3DL is designed to meet more complex needs. L3DL's predecessor, 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 ... Unlike LLDP, L3DL has only one implementation, and LSOE only one open source implementation, and neither is significantly 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 similar 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 rendezvous 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 .