Subject: [Idr] draft-minto-idr-bgp-autodiscovery

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Jul 2021 21:21:20 +0200

Dear WG,

I have noticed this draft appeared on today's IDR WG meeting agenda if
time permits.

I would like to highlight that the core transport idea of
autodiscovery using 1 hop LAN multicast with UDP has been proposed a few
years back - except with much simpler messages.

Quote from:
https://www.ietf.org/archive/id/draft-raszuk-idr-bgp-auto-session-setup-01.txt

3.  Proposed Solution

   When BGP attempts to establish the EBGP sessions with unknown peers
   router will start sending BGP Session Explorer (BSE) packets which
   are to be regular BGP session establishment packets containing plain
   BGP OPEN Message except instead of regular peer address a multicast
   address will be used 224.0.0.2 "All Routers on this Subnet" as UDP
   destination address.  Destination port of this UDP packets is to be
   assigned by IANA.  Source address will be selected by the operator
   either local interface address (when establishing plain p2p relation)
   or loopback address (when establishing peering between loopback
   addresses).

   Authors leave this as open discussion point to use instead of well
   known multicast address of 224.0.0.2 a new IANA assigned multicast
   address dedicated for the purpose of BGP Auto Session Setup.

I contacted the authors offline a few weeks back and extended the
invitation to work together, but received no response.

While I completely agree that IETF can build proposals based on the
previous work I find it a bit odd that even no reference to previous
work can be found in the current version of subject draft.

Thx,

R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Jul 2021 17:26:55 -0400

[Speaking as an individual contributor.]

Robert,

> I have noticed this draft appeared on today's IDR WG meeting agenda if

That would be the Friday session, not Thursday.

> invitation to work together, but received no response.

Your original email was in a somewhat more accusatory tone.  Thank you for
the chance to address this in a public forum.

Working through the proposals discussed in the BGP Auto-discovery Design
Team document[1], Appendix A:

draft-xu-idr-neighbor-autodiscovery:
- 00 published in December 2016.
- Contains peering addresses and link attributes.
- Carried in L3 multicast, suggests 224.0.0.2.

draft-acee-idr-lldp-peer-discovery:
- 00 published in March 2017 on top of LLDP.
- Contains peering addresses as its primary information.
- Carried in L2 multicast.

draft-raszuk-idr-bgp-auto-session-setup:
- 00 published July 2018
- Contains BGP OPEN message (section 3)
- Carried in L3 multicast, suggests 224.0.0.2.

draft-ietf-lsvr-l3dl-ulpc:
- 00 published in May 2020 on top of L3DL.
- Contains peering addresses as its primary information.
- Carried in L2 multicast.

draft-acee-ospf-bgp-rr is elided.

draft-minto-idr-bgp-autodiscovery:
- 00 published July 2021.
- Contains peering addresses as its primary information.
- Carried in L3 multicast, group is unspecified.

Comparing specifically draft-minto vs. draft-raszuk:
- draft-raszuk contains a BGP OPEN message. The majority of the information
  carried in a BGP OPEN message was declared undesirable session state to
  not be carried in the auto-discovery protocol per Working Group consensus.
- draft-raszuk indirectly carries a transport address as part of the src
  address carrying the multicast PDU.
- draft-minto was authored to carry the required transport state in the
  discovery protocol and use BGP "discover at open" procedures to gather the
  remaining material per section 2.3 of the autodiscovery requirements.
- Both leverage IP multicast.

The largest portion of commonality between the two drafts is they leverage
IP multicast.  The PDU contents of draft-minto share commonality with the
proposals that carry the transport state in their PDUs.  It intentionally
does not carry the state carried in the BGP OPEN PDU.

IP multicast to carry routing information is certainly not novel.  Minimally
RIPv2 made use of it in November 1994.

The analysis of the previous proposals in the autoconf-considerations draft
notes where those proposals overlap or differ from the requirements.

> work can be found in the current version of subject draft.

The authors of draft-minto worked from the autoconf-considerations draft
requirements.  Rather than work from a previous proposal and needing to
discard text, their attempt was to try to capture those requirements in a
clean slate fashion.

The authors will likely welcome comments on their draft, including
acknowledging prior relevant works.

-- Jeff

[1] https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-autoconf-considerations-01

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Jul 2021 23:39:21 +0200

Hi Jeff,

Thank you for your note.

The most important aspect of auto discovery for me is the messaging aspect
in which both drafts pretty much equate.

I understand that what we carry within this UDP link multicast transport is
different in both drafts.

I took bare minimum to start with, draft-minto used fields from DT
document. I never said that what we carry must be ctrictly limited to what
is placed in the OPEN msg.

Bottom line - I am happy to see this model being pushed by Juniper. It is
only that I feel bad taste the way it was proposed - but nevertheless I
wish it all the best and in fact will support the adoption when it get's to
it on the list. That's all.

Cheers,
Robert.

PS. Indeed IDR is tomorrow PT. Apologies - I was looking from wrong time
zone when typing the mail. In some countries it is already Friday :).

On Thu, Jul 29, 2021 at 11:26 PM Jeffrey Haas <[email-masked]> wrote:

> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-autoconf-considerations-01
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 29 Jul 2021 18:17:40 -0400

Jeff and Robert: 

[WG chair hat on] 
Thank you for your public discussion regarding 
draft-minto-idr-bgp-autodiscovery. 
 
Please note that IDR WG chairs gathered from the 
6/21/2021 interim on auto-configuration and 
the mail list information that we will adopt 
draft-ietf-idr-bgp-autoconf-considerations-01.txt.  
The WG adoption period on this requirements 
draft will close on 7/30 (tomorrow). 

In my status messages, I have indicated
that proposals would be accepted for 
bgp auto-configurations proposals 
that align with this requirements 
document for the DC.  I hope that past 
proposals who wish to be considered
will revise their technologies
and resubmit their proposals. 

We will be having an interim on 10/11/2021 
to discuss proposals for BGP auto-configuration.  
Please consider revising/creating a proposal
and asking for a slot.  Publication of your 
proposal in August or September may help you 
get feedback prior to this meeting. 
[WG chair hat off]
[individual contributor hat on]
I agree with Jeff's analysis of the drafts.

Cheers, Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, July 29, 2021 5:27 PM
To: Robert Raszuk
Cc: idr@ietf. org
Subject: Re: [Idr] draft-minto-idr-bgp-autodiscovery

Robert,

> years back - except with much simpler messages.
https://www.ietf.org/archive/id/draft-raszuk-idr-bgp-auto-session-setup-01.t
xt

-- Jeff

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-autoconf-considerat
ions-01

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr