Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC

["Dongjie (Jimmy)" <[e-mail]>]

Hi Robert and Randy,

Please see some comments inline:

From: Robert Raszuk [mailto:[e-mail]]
Sent: Saturday, February 8, 2020 7:19 AM
To: Randy Bush <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>; [e-mail]
Subject: Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC

Hi Randy & Dongjie,

Before we dive into bits and pieces is the assumption that auto discovered stuff is ephemeral and disappears upon reboot or is to stay for a while in the box ?

[Jie] IMO we don’t have assumption about this, and it depends on the type of information discovered.

How about marking peers as upstream vs downstream? See we may wan to apply different peer templates up vs down say different prefix limits as example - example to compute vs spine from a given TOR.

[Jie] Another possible example is to determine whether to advertise an default route or the full table to the peer.

>  - signal your ip address (which will tell me v4 or v6) and, as
>   it is the 21st century, assump MPBGP

Do you want to try all possible AFI/SAFIs in capabilities ?

[Jie] Perhaps we need to be clear whether the signaled addresses are used for underlay BGP peering?

> - signal your asn.  if it is the same as mine, it's iBGP so
>   no need to think about multi-hop etc

if it is not the same then you guess if this is multihop, disable connected-check or p2p ?

[Jie] The signaled ASN may be used by the peer for validation of the peering relationship. One question is do we also  cover iBGP P2P in the DC underlay scenario?

> - signal how many hops i need to get to your listener

How would I ever know that apriori ? BTSH in autodiscovery case is a little bit tricky :).

[Jie] Is this about multi-hop iBGP? If so, is it what we need to consider for the DC scenario?

> - signal the authentication

You mean type ? Well I would put those into pre-cfg template instead.
> EBGP using connected-interface address
> EBGP using loopback address
> ECMP

ECMP is not property of the session. It is internal thing to given end. I don't think we need to autodiscover it.

[Jie] ECMP is a useful feature when loopback is used for the session. Such configuration may be generated automatically based on the autodiscovery.

> Validation of allowed peers

Sure but again this is local policy.

[Jie] It requires the information for validation (e.g. ASN, peer address range) to be signaled to the peer.

> Liveness detection

You mean BFD on/off + BFD flavor ? Or something else ?

[Jie] The liveness can be based on both the autodiscovery mechanism itself and BFD. For the latter the capability and parameters of BFD could be signaled.

> Supported address family for session setup: IPv4, IPv6

+1

> Authentication

as commented above

Thx,
r.

PS. I really do not know how far we want to go here but there is few things which ORF can help us with too.

[Jie] My understanding is the design team should provide a minimal set of mandatory requirement and a relatively short list of optional requirements. If some information could be obtained via existing BGP mechanism, then its priority in BGP autoconf should be low. While I’m a little curious what information above can be provided by ORF?

Best regards,
Jie