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

Robert Raszuk <robert@raszuk.net> Thu, 29 July 2021 21:39 UTC

Return-Path: <robert@raszuk.net>
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 1FC373A0955 for <idr@ietfa.amsl.com>; Thu, 29 Jul 2021 14:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 viF51kmp1uzC for <idr@ietfa.amsl.com>; Thu, 29 Jul 2021 14:39:15 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467363A094F for <idr@ietf.org>; Thu, 29 Jul 2021 14:39:15 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id u3so13578241lff.9 for <idr@ietf.org>; Thu, 29 Jul 2021 14:39:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4oG1fEpFAJlIfkQJ3jRXpVUD0InX/p7H+w9YFwlNrHs=; b=eCQvqh3TcJPjyfuirJ/PJeAfSmjvp778K6plhNZzuEYTtY4qHt8nRwLbC0+zMm695T 0fHTUa3XCccnsGpC2lCdDUU1RgDKXKkaf0wj37sD5YLC1CyGxWxpvUFv21GEGiVlLajE nG0EzilpIBYlQmH5FSO6L5QOeHJX72ZnDvFHqHbal1H8ifPCYCca9lWKVAnvS45nDhiC HrMgnJdjjluW0QhYbKnNmmPMpA/aLtpyTAPk33VBwaFyqFRjhBb5gqur+lZcuX67D9C3 v+9UNrRFNakNDD+XukQeKwqRa6ABVj5vQ8ixFQIHkg8G2bQN3GbqS+15txfhGdLuXObg XbUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4oG1fEpFAJlIfkQJ3jRXpVUD0InX/p7H+w9YFwlNrHs=; b=By8/WQkcHh8dV9hG56nl2sgtSrY082rY2R30SR67QGamFz+3Fk7t0imUOKiacrVR5A oSFPJB5K/BAlqa8ThJWRkkPsIbmx+ENhXnZDjX5WqXd2AAh0gzBd6XXuTw4G7XraRX+j GfU6Ro2IcsezlX+Bc2p7oxC9RbrQRD7VGaz0oOjJwIJHm8fSfWytsUWTQxLJW6k2YV5W gHWnTJKDSfIVCyjMNDwEQ7+pQT+8MQhtNLhVNkHz3XhrGiHno9T6GT2Ysr/ilDyPut8o ebL6MmSxEgj/KVeGery+Jypw6Z+pE1/GTLD8MRuBD18+MDwFXI8zevQL9k3QakWFMQZJ THRw==
X-Gm-Message-State: AOAM53102R46COved59EoT7zycn1Yo1+887sdPqm/f3XGG9IDKQyw2/J 3ZBKDzMEaeqUiY1TokoU9etBDlzSej5K6t21moUyhB5Pt3A=
X-Google-Smtp-Source: ABdhPJwPPn2DVelquTl+xK7ymeL9I4v5XBansGDVQsP9WrCVA7zRQomLl8ousXQbnjwjJSgzyJqMnIskPushgX0GI30=
X-Received: by 2002:a05:6512:3dac:: with SMTP id k44mr5406543lfv.541.1627594752372; Thu, 29 Jul 2021 14:39:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMEpQt6rULP4tB4NaM3uu-OJr6shS5sAjSb8XFZ7_C3DVw@mail.gmail.com> <20210729212655.GA1154@pfrc.org>
In-Reply-To: <20210729212655.GA1154@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 29 Jul 2021 23:39:21 +0200
Message-ID: <CAOj+MMHvFbnHwJHia+jz8dLJSynoFzfx7MbTpg4NQeSHdHa6+g@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000dc59f05c849ef61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nHdeMORPFvUzazivLlAApffUhDE>
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:39:20 -0000

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 <jhaas@pfrc.org> wrote:

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