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

[Randy Bush <[e-mail]>]

> 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