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

Jeffrey Haas <jhaas@pfrc.org> Thu, 29 July 2021 21:26 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312D73A085E for <idr@ietfa.amsl.com>; Thu, 29 Jul 2021 14:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FWXGKBCdFKt for <idr@ietfa.amsl.com>; Thu, 29 Jul 2021 14:26:56 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A1FDF3A085C for <idr@ietf.org>; Thu, 29 Jul 2021 14:26:56 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D1BB21E27C; Thu, 29 Jul 2021 17:26:55 -0400 (EDT)
Date: Thu, 29 Jul 2021 17:26:55 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: "idr@ietf. org" <idr@ietf.org>
Message-ID: <20210729212655.GA1154@pfrc.org>
References: <CAOj+MMEpQt6rULP4tB4NaM3uu-OJr6shS5sAjSb8XFZ7_C3DVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOj+MMEpQt6rULP4tB4NaM3uu-OJr6shS5sAjSb8XFZ7_C3DVw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JCpfeUi-z9c_9QHrGsRz1kmKRMY>
Subject: Re: [Idr] draft-minto-idr-bgp-autodiscovery
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jul 2021 21:26:59 -0000

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

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-considerations-01