Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC

Zhuangshunwan <zhuangshunwan@huawei.com> Sun, 09 February 2020 13:57 UTC

Return-Path: <zhuangshunwan@huawei.com>
X-Original-To: bgp-autoconf@ietfa.amsl.com
Delivered-To: bgp-autoconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249E3120106 for <bgp-autoconf@ietfa.amsl.com>; Sun, 9 Feb 2020 05:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ntbiF7cuudpT for <bgp-autoconf@ietfa.amsl.com>; Sun, 9 Feb 2020 05:57:13 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A33C120103 for <bgp-autoconf@ietf.org>; Sun, 9 Feb 2020 05:57:13 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 22EB83DC13E922A541C9 for <bgp-autoconf@ietf.org>; Sun, 9 Feb 2020 13:57:08 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 9 Feb 2020 13:57:07 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Sun, 9 Feb 2020 21:56:51 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: Randy Bush <randy@psg.com>, Robert Raszuk <robert@raszuk.net>
CC: "bgp-autoconf@ietf.org" <bgp-autoconf@ietf.org>
Thread-Topic: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC
Thread-Index: AdXdoUXCj6AoAVwuSs2cA3dZ7wwGNAAJJ0AAAAEDRwAAAG/pgABg9Q8Q
Date: Sun, 09 Feb 2020 13:56:50 +0000
Message-ID: <19AB2A007F56DB4E8257F949A2FB9858E6027272@NKGEML515-MBX.china.huawei.com>
References: <89bb996682564b99af57133a76b8dc6b@huawei.com> <m2a75u3tcx.wl-randy@psg.com> <CAOj+MMH7ERDbHt6jy1guLUg-ncqbVhv5GaYTd2Hb4a6R82sd7w@mail.gmail.com> <m27e0y3rfq.wl-randy@psg.com>
In-Reply-To: <m27e0y3rfq.wl-randy@psg.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.164.26]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/TXpaNlDCo8qQID7sFOAhFeli1m8>
Subject: Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC
X-BeenThere: bgp-autoconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP autoconfiguration design team discussion list <bgp-autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bgp-autoconf/>
List-Post: <mailto:bgp-autoconf@ietf.org>
List-Help: <mailto:bgp-autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Feb 2020 13:57:16 -0000

> Do you want to try all possible AFI/SAFIs in capabilities ?

doesn't bgp open negotiate this

[Shunwan] IMO, in the DC space, IPv4 unicast or IPv6 unicast should be negotiated by default to establish the connectivity of the Underlay.  As for The other address families, can be negotiated if pre-configuration.

-----Original Message-----
From: Bgp-autoconf [mailto:bgp-autoconf-bounces@ietf.org] On Behalf Of Randy Bush
Sent: Saturday, February 8, 2020 7:32 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: bgp-autoconf@ietf.org
Subject: Re: [Bgp-autoconf] Discussion about BGP autoconf requirements in DC

> Before we dive into bits and pieces is the assumption that auto 
> discovered stuff is ephemeral and disappears upon reboot or is to stay 
> for a while in the box ?

do we care?  this is discovery, not colonisation :)

> How about marking peers as upstream vs downstream?

or which flavor of routes i am supposed to give them.  maybe which community sets i should use?  perhaps we should see how simple we can make this, not how complex?

>>  - signal your ip address (which will tell me v4 or v6) and, as
>>   it is the 21st century, assump MPBGP
> Do you want to try all possible AFI/SAFIs in capabilities ?

doesn't bgp open negotiate this

>> - signal your asn.  if it is the same as mine, it's iBGP so
>>   no need to think about multi-hop etc
> if it is not the same then you guess if this is multihop, disable 
> connected-check or p2p ?

don't you know if it is single hop by the peer ip address?

>> - signal how many hops i need to get to your listener
> How would I ever know that apriori ?

if you don't, signal 42 or 255

>> - signal the authentication
> You mean type ? 

i am inclined to type and credential.

> Well I would put those into pre-cfg template instead.

threat model analysis needed here.  historically, tcp-md5 was to stop the nasty tcp resets of established sessions; authenticity was not the issue.  is that still true?  if so, i can trust you to tell me what hash, or whatever, to use.  if not, some external authority, such as pre-config, is needed.

randy

--
Bgp-autoconf mailing list
Bgp-autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/bgp-autoconf