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

[Robert Raszuk <[e-mail]>]

Hi,

So as proven in working implementations (see Cumulus) bare min you need to
automagically operate is a peer's address. They take it from link local and
are done. SAFI is always 1. AFI depends on the IP as you suggested. eBGP AS
is learned from OPEN.

So their basic interface level bgp cfg is this:

- add bgp autonomous-system 65000
   - add bgp neighbor swp51 interface remote-as external
   - add bgp neighbor swp52 interface remote-as external

Anything else seems topping on the cake.

There is also an interesting case Cumulus did for unnumbered loopback
peering ... well it is actually IPv4 loopback to lPv4 loopback but using
IPv6 link local as next hops. Works on p2p breaks few hops away.

I am not stating that we should or should not but do we have full agreement
that DC case must cover any other BGP peering except p2p and lo2lo over p2p
? Is there a real requirement to discover your peers few IP hops away ?
Even if you discover - how will you get there ?

As far as md5, A0, XYZ to validate if you are legitimate peer this really
is not an autodiscovery part. IMO it should be part of preconfigured
template.

Thx a lot,
R.


On Sat, Feb 8, 2020 at 12:31 AM Randy Bush <[e-mail]> wrote:

> > 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 ?
>
> do we care?  this is discovery, not colonisation :)
>
> > How about marking peers as upstream vs downstream?
>
> or which flavor of routes i am supposed to give them.  maybe which
> community sets i should use?  perhaps we should see how simple we
> can make this, not how complex?
>
> >>  - 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 ?
>
> doesn't bgp open negotiate this
>
> >> - 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 ?
>
> don't you know if it is single hop by the peer ip address?
>
> >> - signal how many hops i need to get to your listener
> > How would I ever know that apriori ?
>
> if you don't, signal 42 or 255
>
> >> - signal the authentication
> > You mean type ?
>
> i am inclined to type and credential.
>
> > Well I would put those into pre-cfg template instead.
>
> threat model analysis needed here.  historically, tcp-md5 was to stop
> the nasty tcp resets of established sessions; authenticity was not the
> issue.  is that still true?  if so, i can trust you to tell me what
> hash, or whatever, to use.  if not, some external authority, such as
> pre-config, is needed.
>
> randy
>