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

[Susan Hares <[e-mail]>]

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:[e-mail]] 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

[Speaking as an individual contributor.]

Robert,

On Thu, Jul 29, 2021 at 09:21:20PM +0200, Robert Raszuk wrote:
> I have noticed this draft appeared on today's IDR WG meeting agenda if
> time permits.

That would be the Friday session, not Thursday.

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

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.

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

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-considerat
ions-01

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