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

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 7 Feb 2020 10:38:01 +0000

Hi all,

It seems we have some consensus to work on the DC case first. Then we can start to identify the set of requirements of BGP auto-conf for using BGP as the underlay protocol in DC.

I try to make an initial list requirement as below. Some of the requirements may be optional, and some may be missing. Any comment

EBGP using connected-interface address
EBGP using loopback address
ECMP
Validation of allowed peers
Liveness detection
Supported address family for session setup: IPv4, IPv6
Authentication
...

Please share your opinions about this list.

Best regards,
Jie

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Feb 2020 14:50:06 -0800

> ....

- signal your ip address (which will tell me v4 or v6) and, as
  it is the 21st century, assump MPBGP
- signal your asn.  if it is the same as mine, it's iBGP so
  no need to think about multi-hop etc
- signal how many hops i need to get to your listener
- signal the authentication

isn't the rest either discoverd/agreed in the OPEN or automagic?

randy

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 8 Feb 2020 00:19:06 +0100

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 ?

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.

>   it is the 21st century, assump MPBGP

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

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

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

> - signal the authentication

You mean type ? Well I would put those into pre-cfg template instead.

> > EBGP using loopback address

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

> > Validation of allowed peers

Sure but again this is local policy.

> > Liveness detection

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

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Feb 2020 15:31:37 -0800

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

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

doesn't bgp open negotiate this

> if it is not the same then you guess if this is multihop, disable

don't you know if it is single hop by the peer ip address?

> How would I ever know that apriori ?

if you don't, signal 42 or 255

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 8 Feb 2020 13:01:43 +0100

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.

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Feb 2020 11:08:39 -0800

mornin' robert

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

being a simple guy, i like simple!

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

how do we socialize this question?  maybe we, as the dt, put out a short
goals statement on idr and see if it flies?

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

having a bit of infosec blood, i am a bit more concerned.  but you are
right, it's tough; either a leap of faith or a bleedin' infrastructure;
see draft-ymbk-lsvr-l3dl-signing.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 8 Feb 2020 21:55:11 +0100

> goals statement on idr and see if it flies?

It would be interesting to first get a sense how dt feels about it ?

We already divided DC from WAN/IXP spaces.

For WAN/IXP clearly multihop is a requirement. But IMHO for DC it is not.
Anyone has a different opinion and could explain why ?

/* I am not sure how do we probe for such questions even within dt :) */

> see draft-ymbk-lsvr-l3dl-signing.

By all means you know much more in this space. My comment was just coming
from past experience when we designed auto CE peering to PE via BGP for ATT
they just insisted about two features: prefix range check and MD5 pre cfg.

---

From: Zhuangshunwan <[email-masked]>
Date: Sun, 9 Feb 2020 13:56:50 +0000

[Shunwan] IMO, in the DC space, IPv4 unicast or IPv6 unicast should be negotiated by default to establish the connectivity of the Underlay.  As for The other address families, can be negotiated if pre-configuration.

-----Original Message-----
From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Saturday, February 8, 2020 7:32 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC

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

> 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

--
Bgp-autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bgp-autoconf

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 10 Feb 2020 15:43:38 +0000

Hi Robert and Randy,

Please see some comments inline:

From: Robert Raszuk [mailto:[email-masked]]
Sent: Saturday, February 8, 2020 7:19 AM
To: Randy Bush <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]
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.

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

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

> EBGP using loopback address

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.

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

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

+1

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 10 Feb 2020 15:57:33 +0000

Hi Robert and all,

Please see inline with [Jie]:

Best regards,
Jie

From: Bgp-autoconf [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, February 9, 2020 4:55 AM
To: Randy Bush <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC

[Jie] Yes we as the design team need to reach some rough consensus on the requirement list first. Thus I’d encourage our members to express you opinions on the requirements. As mentioned in my previous reply, we could provide a minimal set of mandatory requirements and a relatively short list of optional requirements for the DC scenario.

For WAN/IXP clearly multihop is a requirement. But IMHO for DC it is not. Anyone has a different opinion and could explain why ?

[Jie] To be more precise, for BGP as DC underlay, it is likely that P2P session is the major requirement.

By all means you know much more in this space. My comment was just coming from past experience when we designed auto CE peering to PE via BGP for ATT they just insisted about two features: prefix range check and MD5 pre cfg.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Feb 2020 15:30:15 -0500

[choosing this message for the reply]

> isn't the rest either discoverd/agreed in the OPEN or automagic?

Mostly.  Later in the thread I see the opinion about authentication got more
complicated, which I think is a necessary thing.

One of the ideas I pushed for in the lldp draft, and mentioned similarly in
the Acee IGP RR discovery drafts was the idea of a "role".  It is left
intentionally unspecified in the draft at the moment since policy/config can
help reconcile it, but perhaps as we work on the design having a more formal
definition may be helpful.

A role in a DC fabric context can be what layer of the fabric the router is
operating at.  E.g. in a 3 layer fabric, leaf should interact with
aggregate, aggregate with leaf and spine, etc.  This helps with discovery
and helps avoid misconnectivity.

A role for a standard ISP PE would be "customer", "reflector", etc.

And yes, there's likely overlap with ideas such as ASPA.

---

An interesting question about layering also covers your point above:
Discovery lets you find a thing that speaks BGP and some of the expected
properties.  Some of the things the automation proposals could do could
either live in the discovery mechanism or in the BGP speaker itself.  Role,
for example.  Transport security mechanism likely has to live in the
discovery.

-- Jeff