Subject: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 13 May 2020 14:38:34 +0000

Hi all,

It's been some time since our presentation on the IDR virtual interim. On that meeting we discussed the next steps, which include:

1. Confirm the minimal set of common requirements
2. Reach consensus on the design principles
3. Put the above two into a requirement document
4. Hand the solution discussion to the WG

Currently we are still at the first step, while hopefully we could finalized the minimal set of common requirements quickly (by end of this month?) based on the discussions we had before.

The minimal set of requirements we have are as below:

* Support IPv4 and IPv6 address family
* Support to use either interface or loopback address for BGP session
* Support to discover the peering IP address
* Support to discover the peering ASN
* Support authentication of control message
* Enable Layer 3 link liveness detection, such as BFD
* The capability of communicating arbitrary attributes to peers according to operators' need

Note the last one was under discussion before the virtual meeting, if you have any opinion on it, please share it on this list.

The second step may need more effort, which means more discussion on the mail list is encouraged, and we may arrange one or two conference calls if needed.

Once we get step 1 and 2 settled, step 3 should be relatively easier (hopefully:)).

Inputs are always welcome. Thanks.

Best regards,
Jie

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 May 2020 09:46:18 -0700

so, a small attempt to move forward again

git be found at https://git.rg.net/randy/draft-bgp-discovery-layers

randy

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 assumed environment 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 discovery 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 dependent.  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.:

      *  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.

   [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

   o  AFI,
   o  IP address (IPv4 or IPv6),
   o  Local ASs,
   o  Local BGP Identifier (AKA, BGP Router ID),
   o  Session Group-ID,
   o  BGP [Authentication] Session Capabilities, and
   o  Local Address (Next Hop).

   Which of these are really necessary could be discussed.

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.

   L3DL Upper Layer Protocol Configuration, [I-D.ymbk-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.

Bush                    Expires November 26, 2020               [Page 4]

Internet-Draft      Trade-offs in BGP Peer Discovery            May 2020

   o  AS number,
   o  IP address, IPv4 or IPv6, and
   o  BGP Authentication.

   L3DL and L3DL-ULPC have well-specified security mechanisms, see
   [I-D.ymbk-lsvr-l3dl-signing].

   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, [I-D.ymbk-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 ...

   Unlike LLDP, L3DL has only one implementation, and LSOE only one open
   source implementation, and neither is significantly 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
   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.

9.  Discovery at Layer Seven

   Peer discovery at Layer-7 requires application layer rendezvous
   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.

Bush                    Expires November 26, 2020               [Page 5]

Internet-Draft      Trade-offs in BGP Peer Discovery            May 2020

   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.acee-idr-lldp-peer-discovery]
              Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu,
              "BGP Logical Link Discovery Protocol (LLDP) Peer
              Discovery", draft-acee-idr-lldp-peer-discovery-06 (work in
              progress), November 2019.

   [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.

   [I-D.ymbk-lsvr-l3dl-signing]
              Bush, R. and R. Austein, "Layer 3 Discovery and Liveness
              Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in
              progress), May 2020.

   [I-D.ymbk-lsvr-l3dl-ulpc]
              Bush, R. and K. Patel, "L3DL Upper Layer Protocol
              Configuration", draft-ymbk-lsvr-l3dl-ulpc-03 (work in
              progress), May 2020.

   [I-D.ymbk-lsvr-lsoe]
              Bush, R., Austein, R., and K. Patel, "Link State Over
              Ethernet", draft-ymbk-lsvr-lsoe-03 (work in progress),
              November 2018.

Bush                    Expires November 26, 2020               [Page 6]

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: [email-masked]

Bush                    Expires November 26, 2020               [Page 7]

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 28 May 2020 10:55:50 +0800

The following analysis on discovery at layer3 surprised me. See my comments inline.

[Xiaohu] It has been proven that multicast is a good choice to address the above concern. For more details, refer to LDP peer discovery mechanism:)

[Xiaohu] Are you intended to perform peer discovery with untrusted devices which are not under your control? If not, why don't you know whether to use IPv4 or IPv6 within your own network (e.g., the datacenter network or metro network which are the major scenarios for BGP peer auto-discovery)?

[Xiaohu] It has been proven that multicast is applicable to both p2p and broadcast networks. 

[Xiaohu] I would like to know what's the exact difficulty in using loopback addresses for BGP session establishment? 

Best regards,
Xiaohu

-- 
Bgp-autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bgp-autoconf

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 29 May 2020 16:04:42 +0000

Hi Randy, 

Thanks a lot for putting things together into a document. IMO it can be considered as the base of our deliverable to the WG, and other team members could raise comments to specific text to help improving it. I'd suggest everyone to read it and give your comments to the list (It is good to see Xiaohu already sent some comments)

And please see some initial comments from my side inline:

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, May 28, 2020 12:46 AM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
> and design principle
> 

>    o  Other attributes required for BGP OPEN to succeed, e.g.

The second bullet maybe more close to "assumptions"?

And perhaps the rest of list could merge with section 2.2? 

>    decisions, and how do we measure them?

In my understanding this is about the design principle as mentioned in our slides on IDR virtual meeting. Here I put the summarized bullets here for reference, and we can have some discussion about each of them, and pick the common set agreed by the team. 

o Independent from BGP session establishment

o Not affect or change BGP session establishment and routing exchange, other than the interactions for triggering the setup/removal of peer session based on discovery mechanism

o Generic for any link-layer protocol

o Make use of a currently implemented and deployed DC switch protocol to reduce the cost and complexity

o Make use of existing BGP protocol for automating the BGP session bring-up

o Widely applicable to a range of routing and similar protocols which need layer 3 discovery and characterization

o Length of the message size supported

>    source implementation, and neither is significantly deployed.

As you mentioned the implementation status of L3DL here, if possible perhaps the implementation of L3DL-ulpc and the LLDP extensions in previous section could also be provided, as it would be helpful if some experience could be learned and documented, which would guide the design in the next step.

>    There will be difficulty if one or both peers wish to use a loopback

Some information about another existing proposal draft-xu-neighbor-autodiscovery may also be included in this document. Perhaps Xiaohu could help with some text? 

>    the classic worries about fragility, redundancy, reliability, etc.

This section is interesting, although we didn't have discussion about this category before (based on my memory). Is this also related to the Sparse peering model in BGP-SPF? Or maybe I misunderstood your intention here. 

Best regards,
Jie