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

From: "Majumdar, Kausik" <[email-masked]>
Date: Mon, 1 Mar 2021 19:03:56 +0000

Hi Jeff, Warren,

I have gone through the draft, it is a well-written document. I agree with Acee that the doc is ready to be reviewed by the IDR WG. I have also noticed that Acee suggested some editorial changes, with that it looks good. I don't have anything more from the editorial side other than few minor points that I captured below, that might be good to discuss in tomorrow's meeting.

Comments are in >> -

In Section 2.3.2 BGP Auto-Discovery Device Role Requirements
>>Should we define the Code Points for the standard Device Roles and their corresponding functions?

In Section 2.4 Operator Configuration
>>Are we planning to use the BGP Autoconf mechanism for the session validation purposes? If so, how Autoconf would be used to collect the information to validate the sessions. I think we need to describe a little more here.

In Section 5.5    Discovery at Layer Seven
"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."

>>Reading through this section it is not clear what specific Layer Seven approach we are recommending here.

I think Security Considerations is well structured in the document and covered well.

Thanks,
Kausik

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 1 Mar 2021 23:37:06 +0000

Jeff and Warren,

I have read through the draft. It is very well written.

Just some minor comments:

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

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

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

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

Thank you,
Linda Dunbar
From: Bgp-autoconf <[email-masked]> On Behalf Of Majumdar, Kausik
Sent: Monday, March 1, 2021 1:04 PM
To: [email-masked]
Subject: [Bgp-autoconf] Review of draft-dt-idr-bgp-autoconf-considerations

Hi Jeff, Warren,

Comments are in >> -

Thanks,
Kausik

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 6 Mar 2021 13:40:55 -0500

Linda,

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

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 n…

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.

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

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

> "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

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 6 Mar 2021 14:13:16 -0500

Kausik,

> >>Should we define the Code Points for the standard Device Roles and their corresponding functions?

At this point in the process, I'm going to suggest we wait on that.  The
draft provides some example roles.  But, until the code space is defined,
we'll be speaking a bit too abstractly, I think.

I suspect this activity will happen early in the protocol work once IDR
picks up the design requirements.

> >>Are we planning to use the BGP Autoconf mechanism for the session validation purposes? If so, how Autoconf would be used to collect the information to validate the sessions. I think we need to de…

I've added text in a new section, Error Handling Considerations.  Please see
if that addresses the concerns.

> >>Reading through this section it is not clear what specific Layer Seven approach we are recommending here.

We decided on our call this week to drop that section.

-- Jeff