Subject: [Bgp-autoconf] Minutes and action points of the conference call

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 25 Feb 2020 15:27:51 +0000

Hi all,

First of all, thank you for attending the conference call, we had good discussion on several items, and many thanks to Sue and others who helped with the minutes.

The minutes is on https://etherpad.ietf.org:9009/p/bgp-autoconf-feb-25, please check if you want to make any change to it.

I also summarized our discussion and action points as below:

- We agreed to work on DC first, while keep an eye on what makes the other cases different.

- For DC case, will focus on intra-data center which uses BGP as underlay, either interface addresses or loopbacks can be used for peering. Inter-DC and VPNs are out of scope.

- We had some discussion about whether we should cover the misconnectivity or misconfiguration detection, there is still no clear result.

- The team agrees that discovering the role of a device could be useful, something similar has been used in RIFT.

- We discussed the security requirements, the authentication has two properties, transport or object security, and authenticating the peer.

- In order to reduce the number of parallel peers between two nodes, need to use loopbacks to setup only one session, then need to consider how to automatically generate the configuration of routes to peer's loopback.

- Enablement of BFD based on auto-discovery is considered as one optional function, while the complexity needs to be considered.

- Some considerations on Zero touch provisioning (ZTP). It is assumed some level of provisioning/pre-configuration is still required.

The team agrees to look at the list of solution drafts, summarize the requirements from each draft, and find a minimal common set.

Action points:
1. The author of each draft to summarize the list of requirement from his draft, and share it on design team list. (by end of this Friday)
2. Other people can provide additional comments to the summarized requirements. (in next week)
3. The team to provide a minimal common set.

Best regards,
Jie

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Feb 2020 14:48:03 -0800

> 1. The author of each draft to summarize the list of requirement from
>    his draft, and share it on design team list.

from draft-ymbk-lsvr-l3dl-ulpc

   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 pain.
   
   If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6,
   then multiple sets of BGP sub-TLVs MAY BE exchanged within the BGP
   ULPC PDU or multiple BGP ULPC PDUs may be sent, one for each address
   family.

   A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU for
   an particular address family at any point in time; receipt of a new
   BGP ULPC PDU for a particular address family replaces any previous
   one.

   If there are one or more open BGP sessions, receipt of a new BGP ULPC
   PDU does not affect these sessions and the PDU SHOULD be discarded.
   If a peer wishes to replace an open BGP session, they must first
   close the running session and then send a new BGP ULPC PDU.

   As a link may have multiple encapsulations and multiple addresses for
   an IP encapsulation, which address of which encapsulation is to be
   used for the BGP session MUST be specified.

   For each BGP peering on a link here MUST be one agreed encapsulation,
   and the addresses used MUST be in the corresponding L3DP IPv4/IPv6
   Announcement PDUs.  If a peering address has been announced as a
   loopback, a two or three (one or both ends could be loopbacks) hop
   BGP session will be established.  Otherwise a direct one hop session
   is used.

which is built on top of draft-ymbk-lsvr-l3dl, which has a wider set of
goals, among them link discovery/verification:

   The Massive Data Center (MDC) environment presents unusual problems
   of scale, e.g. O(10,000) forwarding devices, while its homogeneity
   presents opportunities for simple approaches.  Approaches such as
   Jupiter Rising [JUPITER] use a central controller to deal with
   scaling, while BGP-SPF [I-D.ietf-lsvr-bgp-spf] provides massive
   scale-out without centralization using a tried and tested scalable
   distributed control plane, offering a scalable routing solution in
   Clos [Clos0][Clos1] and similar environments.  But BGP-SPF and
   similar higher level device-spanning protocols, e.g.
   [I-D.malhotra-bess-evpn-lsoe], need logical link state and addressing
   data from the network to build the routing topology.  They also need
   prompt but prudent reaction to (logical) link failure.

   Layer 3 Discovery and Liveness (L3DL) provides brutally simple
   mechanisms for devices to

   o  Discover each other's unique endpoint identification,

   o  Discover mutually supported layer 3 encapsulations, e.g.  IP/MPLS,

   o  Discover Layer 3 IP and/or MPLS addressing of interfaces of the
      encapsulations,

   o  Present these data, using a very restricted profile of a BGP-LS
      [RFC7752] API, to BGP-SPF which computes the topology and builds
      routing and forwarding tables,

   o  Enable Layer 3 link liveness such as BFD,

   o  Provide Layer 2 keep-alive messages for session continuity, and
      finally

   o  Provide for authenticity verification of protocol messages.

   This protocol may be more widely applicable to a range of routing and
   similar protocols which need layer 3 discovery and characterisation.

randy

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 27 Feb 2020 07:44:41 +0000

Thanks to Randy for summarizing the requirements from the L3DL drafts. 

Authors of other drafts, please also share the summary of requirements from your draft to the design team list. Thanks.

Best regards,
Jie

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2020 6:48 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bgp-autoconf] Minutes and action points of the conference call

   

which is built on top of draft-ymbk-lsvr-l3dl, which has a wider set of goals, among them link discovery/verification:

randy

---

From: "徐小虎(义先)" <[email-masked]>
Date: Fri, 28 Feb 2020 09:10:30 +0800

Hi all,

The following requirements are quoted from https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-12#page-4

4.  Requirements

   This section describe the requirements for the BGP hop-by-hop routing
   deployments that were considered for the definition of the BGP
   Neighbor Discovery extensions proposed in this document.

   Following are the key requirements related for the BGP neighbor
   discovery process:

   1.  It should perform discovery of directly connected BGP routers.
       Mechanism should support either IPv4 or IPv6 or a dual stack
       design and it should be generic for any link-layer.

   2.  It should include exchange of BGP peering addresses (IPv4 or IPv6
       or both) that routers can use to automatically setup BGP TCP
       peering between themselves.  The mechanism should leverage the
       existing capability negotiation process performed as part of the
       BGP TCP session establishment.

   3.  When BGP peering is desired to be performed over loopback
       addresses of the routers, then the mechanism should automatically
       setup reachability to the loopback over one or more underlying
       directly connected links between them.  In this scenario, the
       mechanism should also provide resolution for the BGP next-hop
       address (i.e. the loopback address) for the BGP routes exchanged
       over these sessions between the loopback addresses.

   4.  Mechanism should enable exchange of link-level information such
       as IP addresses and link attributes between the directly
       connected BGP routers.  It should be extensible to include other
       information in the future.

   5.  Mechanism should be limited to link scope for security and use
       link-local addressing only.  Cryptographic mechanisms should be
       also provided for additional security.

   6.  Mechanism should support capabilities for performing optional
       validation of parameters to detect misconfiguration (e.g. link
       address subnet mismatch, peering between incorrect AS, etc.) in
       an extensible manner before going on to use the link and the
       setup of the BGP TCP peering session over it.

   7.  The mechanism should not affect or change the BGP TCP session
       establishment procedures and the BGP routing exchange over the
       TCP session other than the interactions for triggering the setup/
       removal of peer session that is based on discovery mechanism.

   8.  The mechanism should leverage existing fast-detection techniques
       for failures that are used currently for EBGP sessions over
       directly connected links like fast-external-failover and BFD.

   9.  The mechanism should focus on the discovery process and exchange
       of status as a control plane procedure and be sufficiently
       loosely coupled with the base BGP operations to enable

       implementations to ensure scalability of BGP operations when
       using the discovery procedures.

Best regards,
Xiaohu
------------------------------------------------------------------
From:Dongjie (Jimmy) <[email-masked]>
Send Time:2020年2月25日(星期二) 23:28
To:[email-masked] <[email-masked]>
Subject:[Bgp-autoconf] Minutes and action points of the conference call

Hi all, 

- In order to reduce the number of parallel peers between two nodes, need to use loopbacks to setup only one session, then need to consider how to automatically generate the configuration of routes to peer’s loopback.

Action points: 

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 28 Feb 2020 14:42:10 +0000

Hi Xiaohu,

Thanks for providing the list of requirements in your draft.

Best regards,
Jie

From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of 徐小虎(义先)
Sent: Friday, February 28, 2020 9:11 AM
To: Bgp-autoconf <[email-masked]>; [email-masked]
Subject: Re: [Bgp-autoconf] Minutes and action points of the conference call

Hi all,

4<https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-12#section-4>.  Requirements

   discovery process:

Best regards,
Xiaohu
------------------------------------------------------------------
From:Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Send Time:2020年2月25日(星期二) 23:28
To:[email-masked] <[email-masked]<mailto:[email-masked]>>
Subject:[Bgp-autoconf] Minutes and action points of the conference call

Hi all,

Action points:

Best regards,
Jie