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

[Randy Bush <[e-mail]>]

> 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