Subject: [GROW] BGP Auto Discovery and BGP Auto Session Setup

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 20:24:11 +0100

Dear WG,

We have seen formation of BGP Autodiscovery WG followed by total silence.
Well maybe group is
live just not everyone got onto its private list :)

Regardless of this I refreshed and resubmitted two proposals in this very
space.

1. BGP Auto Discovery

https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-06

and

2. BGP Automated Session Setup

https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01

*Ad 1:*

First document is focused on WAN and IX scenario where establishing
full mesh of IBGP or

selected eBGP peering can automate the operational management tasks or
if run in informational

mode could validate NMS session setup correctness.

Original proposal was presented many years ago in Vienna and at that
point suggested extension to

IGPs to flood discovery information for IBGP auto mesh. Later based on
the input and discussions with

Pedro the proposal got simplified to use classic Route Reflector as
bootstrap node (info broker).

Last input from Jon and Warren added the ability to also automate
setup of eBGP sessions in selected

scenarios.

Since then the document was shelved for some time waiting for IDR WG
turn to deal with discovery topic.

So here we are.

*Ad 2: *

The second document first published in July 2018 provides a very
trivial to implement mechanism (without

even changing BGP state machine) to automatically establish common LAN
or p2p interfaces BGP sessions.

Typical use case would be Clos DC fabrics, customer PE-CE LANs, TORs
to Compute Nodes etc ...

Comments, questions, feedback on both proposals all very welcome.

Kind regards,

Robert.

---

From: Alejandro Acosta <[email-masked]>
Date: Wed, 11 Dec 2019 22:47:02 -0400

Hello Robert,

 I just read the first document, I guess for most people could be
"interesting" too see BGP Auto Discovery, I'm not sure yet if I'm in
favor or against.

 Hope this is not a crazy comment. Well, in the document you (and other
co-authors) do not mention much about -any possible- impact this
mechanism could have in bgp route selection algorithm (which anyhow is
by default managed by vendors and modified by administrators). As far as
I could understand from your doc, routers can identify which prefixes
were learnt by auto-discovered devices and which were learnt by the
"traditional" BGP operation. Am I right? which one would you trust
more?, new administrative distance or something like that?.

Thanks,

Alejandro,

On 12/11/19 3:24 PM, Robert Raszuk wrote:
> Dear WG,
>
> We have seen formation of BGP Autodiscovery WG followed by total
> silence. Well maybe group is 
> Regardless of this I refreshed and resubmitted two proposals in this
> very space. 
>
>
>   1. BGP Auto Discovery
>
>
> *_Ad 1:_*
> *_Ad 2: _*
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Dec 2019 09:53:00 +0100

Hello Alejandro,

Many thx for your comments.

To respond to your question there is no preference to the best path
selection process based on the method BGP session is established.

Of course one could you this method just as a validation of manual mesh
correctness or rather completeness, but if so while routers could keep list
of autodiscover peers we would not necessarily establish actual BGP
sessions to those if NMS or manual sessions are already present.

Said all of this if you and others think there is need to work more on your
point I am open to hear the actual justification.

Many thanks,
Robert

On Thu, Dec 12, 2019 at 3:47 AM Alejandro Acosta <
[email-masked]> wrote:

> "interesting" too see BGP Auto Discovery, I'm not sure yet if I'm in favor
> or against.
>
> co-authors) do not mention much about -any possible- impact this mechanism
> could have in bgp route selection algorithm (which anyhow is by default
> managed by vendors and modified by administrators). As far as I could
> understand from your doc, routers can identify which prefixes were learnt
> by auto-discovered devices and which were learnt by the "traditional" BGP
> operation. Am I right? which one would you trust more?, new administrative
> distance or something like that?.
>
>
> Thanks,
>
>
> Alejandro,
>
>
>  First document is focused on WAN and IX scenario where establishing full mesh of IBGP or
>
> selected eBGP peering can automate the operational management tasks or if run in informational
>
>  Original proposal was presented many years ago in Vienna and at that point suggested extension to
>
> IGPs to flood discovery information for IBGP auto mesh. Later based on the input and discussions with
>
> Pedro the proposal got simplified to use classic Route Reflector as bootstrap node (info broker).
>
>  Last input from Jon and Warren added the ability to also automate setup of eBGP sessions in selected
>
> scenarios.
>
>  Since then the document was shelved for some time waiting for IDR WG turn to deal with discovery topic.
>
>  So here we are.
>
>  *Ad 2: *
>
>  The second document first published in July 2018 provides a very trivial to implement mechanism (without
>
> even changing BGP state machine) to automatically establish common LAN or p2p interfaces BGP sessions.
>
>  Typical use case would be Clos DC fabrics, customer PE-CE LANs, TORs to Compute Nodes etc ...
>
> GROW mailing [email-masked]://www.ietf.org/mailman/listinfo/grow
>