Re: [Bgp-autoconf] Review of draft-dt-idr-bgp-autoconf-considerations

[Jeffrey Haas <[e-mail]>]

Linda,

On Mon, Mar 01, 2021 at 11:37:06PM +0000, Linda Dunbar wrote:
>   *   Page 2 Section 2.3 third bullet has "Authentication Method". But  I don't see any of the described methods has auto discovering "authentication method". Is it really a requirement of BGP Auto-Discovery protocol?

I've updated the text to transport security parameters since that's what
we're really representing.


>   *   Page 2 Section 2.3 Fourth bullet: The following BGP peer session parameters  are also present in a BGP OPEN message. If a node can trust the parameters discovered by BGP Auto-discovery, why not trust the same information from BGP Open?

It's a matter for peer selection.  Discovering something that speaks BGP is
one part of the procedure.  However, you may not want to open a peering
session with something unless it is a thing you want to have a session with.
For example, a mismatch in desired device role along with AS number - as
would be in a BGP Clos fabric.

>    *  Discovery of BGP peer session parameters relevant to peer
>       selection such as Autonomous System (AS) Numbers, BGP Identifiers,
>       supported address families/subsequent-address families (AFI/
>       SAFIs), and device roles.
> 
> 
> 
>   *   Section 6 IANA consideration: For Layer 3 discovery, do you need IANA to register a specific MULTICAST address for BGP auto discovery?

A given protocol document would need to make that request.  This is the
requirements document.

>   *   Section 3.5: you have the following description:
>       ".  Negotiated keying solutions, such as
>       IKE, may be desireable but not mandatory for the solution."
> 
> Under what circumstance, the IKE is desired?  Is it for the scenario that  peer is  NOT trusted for Auto-config? With  IKE, a node can authenticate any internet reachable peers, which one to choose?

Some people might want to use IKE so they get all of the properties it is
good for.  Some might prefer static keying.  If you want to enable both
scenarios, then it needs to be mentioned as an option.

>   *   Page 5: first sentence doesn't quite belong there:
> "The length of message supported by the protocol."

Consider LLDP.  If auto-discovery is part of that existing protocol, its
length considerations limits what things you can support for auto-discovery.
For example, long lists of device roles.

-- Jeff