Re: [Bgp-autoconf] Questions to draft‐dt‐idr‐bgp‐autoconf‐considerations‐00

[Jeffrey Haas <[e-mail]>]

Linda,

Jie has offered some good feedback on these points already.  My comments
follow partially to give my thinking on the matter.  This doesn't mean I
don't agree with Jie on most of these.


On Tue, Jan 26, 2021 at 11:54:32PM +0000, Linda Dunbar wrote:
> Jeff and Warren,
> 
> Section 2.3 Page 3 third bullet says “Discovery of BGP transport protocol end-points”:
> The previous bullet already stated that the directly attached interface address can be used. Can we assume that the "directly attached interface address" is the Transport protocol "end point" address?
> Is there any problem in using Reverse ARP (IPv4)  or Neighbor Solicitation (IPv6) to discover the neighbor’s link or loopback addresses? There is no mentioning of using RARP/NS in the document.

You'll find it in the most current document for today's call.  But that
said, that sort of environment isn't guaranteed.

It's also a place where the data-center use case may diverge from other use
cases for auto configuration.  It's thus documented for discussion.

> The 3rd bullet also says “layer 3 liveness mechanism such as BFD and support for GTSM”. Can node use BGP UPDATE to validate neighbor’s liveness?

BFD doesn't replace BGP's capability, it makes downtime detection faster.

> 4th bullet says “discovery of BGP peer session parameters relevant to peer selection such as AS, BGP ID, ..”
> Is there any reason that the information carried by BGP OPEN cannot be used?

You might recall some of our discussion being around a "peer selection"
process that needs some work in our text.  Just because you announce there's
a session available, you shouldn't have to open a BGP session to decide if
you wanted to open a bgp session.

As a working example, if you're doing a Clos fabric, you may not want to
even open a peering session with a peer that's in the same level as you.
It's a mis-wire.

Information such as BGP ID is also needed to determine if we're talking to
the same BGP Speaker.  

> 6th bullet says “once this information has been learned, a BGP Speaker has the necessary information…. to open BGP session”
> This requirement prohibits a node to learn peer's ASN number from BGP OPEN message. Is it necessary to have this requirement, and why?

See above about peer selection as a step.

> Section 2.4 says that “BGP auto-Discovery Protocol State may be carried in multiple transport protocols”
> BGP running over TCP,  what other transport protocols are implied here?

The auto-discovery mechanism, not BGP itself.  I've been trying to make sure
that when we're talking about the resulting auto-discovery protocol I call
it out verbosely to avoid confusion.  Do you have better wording
suggestions?

> Section 3:
> 1st bullet says “Select or otherwise filter which peers to actually try to send BGP OPEN msg”.
> Can the selection be NULL, meaning all directly connect neighbors?

I'd normally treat the NULL result as the empty one and thus send to none.
But it's possible to have an implementation that doesn't care about what it
connects to.  While this is possible, it seems likely to lead to
mis-connectivity.

Discussing the operational considerations is part of our enxt steps.

> Section 4.1 Transport considerations:
> Calling Layer 2 or Layer 3 as "transport" options is confusing, conflict with common used Transport Layer (TCP/UDP/QUIC).

What would you call this? 

> Section 5.1 says there are two available candidates for peer discovery at Layer 2.
> Should add the 3rd option:
> Reverse ARP (IPv4) can also find the IP address on P2P links.
> For IPv6: Neighbor Solicitation message [RFC4861] can be used to get neighbor's Link address and IP addresses

You'll find this in the document for today.  However, I put it in the layer
3 option since we need to have IP connectivity and the idea of a subnet for
this to work.  If you think that's an inappropriate categorization, we can
discuss today.

-- Jeff