Re: [Idr] BGP Auto-Discovery Protocol State Requirements

Jeffrey Haas <jhaas@pfrc.org> Fri, 19 March 2021 14:13 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 103813A1627 for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 07:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 J4Yj6sdgXo_X for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 07:13:18 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4193A1625 for <idr@ietf.org>; Fri, 19 Mar 2021 07:13:18 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 23A3D1E446; Fri, 19 Mar 2021 10:34:49 -0400 (EDT)
Date: Fri, 19 Mar 2021 10:34:48 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: Tony Przygienda <tonysietf@gmail.com>, "idr@ietf.org" <idr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Message-ID: <20210319143448.GM29692@pfrc.org>
References: <20210316210203.GC29692@pfrc.org> <20210318191936.GF29692@pfrc.org> <A288921D-0DB5-413D-B3E9-4DAA9334C5D3@cisco.com> <CA+wi2hNUYkmruBSq4Up4e84H__d48Phxj5TuZXh7wii0QrS3dw@mail.gmail.com> <20210319135025.GK29692@pfrc.org> <CAOj+MMGndgwqLoV_Un_1Bu3F3xPkg9ZD6=4V5FmYJgQiPD_1yw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMGndgwqLoV_Un_1Bu3F3xPkg9ZD6=4V5FmYJgQiPD_1yw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JpAcRYPtkJW8eEfy6Td6KbpB7f4>
Subject: Re: [Idr] BGP Auto-Discovery Protocol State Requirements
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: Fri, 19 Mar 2021 14:13:20 -0000

Robert,

On Fri, Mar 19, 2021 at 02:49:05PM +0100, Robert Raszuk wrote:
> > There's some discussion in the draft about what transport layer we use, and
> > a few of the headaches.  For BGP auto-discovery, the major implication is
> > how wide your want your messages to travel.
> 
> And this is precisely the fundamental point we would need to agree on.

Certainly one of them.

> Currently the answer is any transport. I recommended to limit it *only* to
> L2 links (physical or emulated).
> 
> For the DC use case I think this is more then enough.

Does that mean:
1. L2 encapsulated multicast
2. L2 encapsulated unicast to a well known MAC?
3. L3 multicast targeted to a single link (e.g. all-routers)?
4. Other?

> And if you take that as a base then to automatically establish BGP session
> is not that hard. In fact you may not need any protocol at all.
> 
> *All you need is two steps: *
> 
> *Step 1 - Find out who is on your link (directly via ICMP or by looking at
> likely already running LLDP or CDP :)*

See Appendix A.2.

ARP/ND can provide such a mechanism, but triggering them can be tricky.

"Ping the broadcast address" can cover this as well, and is an old and
common hack.

LLDP has a proposal. It had to add some of the state discussed in the design
team draft and is somewhat incomplete.  See Appendix A.1.1

CDP is proprietary and isn't a good candidate for IETF work.

Coworkers working on our implementation of A.2 note that "Router
Advertisement" works fine for this property, although it has extra semantics
that are possibly not desirable for this use case.

> *Step 2 - Among peers discovered in step 1 for each address you check if he
> is listening on 179. If so you send him an OPEN. *

"check" how?

As noted at the beginning of this thread, you may not be able to get your
SYN+ACK if you don't agree on security mechanisms or GTSM.  So, you need
that state either in your discovery mechanism, or your provisioning.

If you require it in your provisioning, you're making a design choice for
your mechanism.  Other implementors may not want to require explicit
provisioning for those things.

> Done.
> 
> Some suggested to add this info to LLDP from step 1 which is not bad idea
> either. But maybe IDR has no power to recommend additions to LLDP.

I suggest you read the cited appendix A.1.1 for a proposal.

I'll leave it to IETF's IEEE liaisons to comment on what happens if we want
a L2-specific protocol.  IEEE has previously had concerns over where such
work happens, and is one of the potential reasons we keep our proposals to L3.

L3DL will have worked through part of this already.  They also handle
authentication and fragmentation considerations.  See appendix A.1.2

> Side comment: When we worked on single side BGP we had very similar
> discussions. But large SP was very clear with the requirements ... If I
> enable auto peering on my LAN towards customer all I care to accept his
> sessions is MD5 match.

That's certainly one of the valid use cases.

Some providers may be fine with no security.

Other providers may want to limit peering based on some property of the
session.

The mechanism we specify needs to accommodate them.


-- Jeff (in general, read the draft)