Re: [Bgp-autoconf] Minutes and action points of the conference call
"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 28 February 2020 14:42 UTC
Return-Path: <jie.dong@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 F06B73A18FF; Fri, 28 Feb 2020 06:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 WVLLTablmKo4; Fri, 28 Feb 2020 06:42:16 -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 95A823A193B; Fri, 28 Feb 2020 06:42:15 -0800 (PST)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4293059D224C3CB6DB59; Fri, 28 Feb 2020 14:42:14 +0000 (GMT)
Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Feb 2020 14:42:12 +0000
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml702-chm.china.huawei.com (10.98.57.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 28 Feb 2020 22:42:10 +0800
Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Fri, 28 Feb 2020 22:42:10 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>, Bgp-autoconf <bgp-autoconf-bounces@ietf.org>, "bgp-autoconf@ietf.org" <bgp-autoconf@ietf.org>
Thread-Topic: [Bgp-autoconf] Minutes and action points of the conference call
Thread-Index: AdXr7hePhzMOppJARo6tbqvLM4QuyQBoriMAACzwi5A=
Date: Fri, 28 Feb 2020 14:42:10 +0000
Message-ID: <1c1ad107c3c84759ba74178650154168@huawei.com>
References: <37b4733413184637b822528e7939f677@huawei.com> <fd087e05-861f-4d49-9086-88b7009196cd.xiaohu.xxh@alibaba-inc.com>
In-Reply-To: <fd087e05-861f-4d49-9086-88b7009196cd.xiaohu.xxh@alibaba-inc.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.219.142]
Content-Type: multipart/alternative; boundary="_000_1c1ad107c3c84759ba74178650154168huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/TCLc87S20QC6rY5V4t-iVxxQC5I>
Subject: Re: [Bgp-autoconf] Minutes and action points of the conference call
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: Fri, 28 Feb 2020 14:42:26 -0000
Hi Xiaohu, Thanks for providing the list of requirements in your draft. Best regards, Jie From: Bgp-autoconf [mailto:bgp-autoconf-bounces@ietf.org] On Behalf Of 徐小虎(义先) Sent: Friday, February 28, 2020 9:11 AM To: Bgp-autoconf <bgp-autoconf-bounces@ietf.org>; bgp-autoconf@ietf.org Subject: Re: [Bgp-autoconf] Minutes and action points of the conference call Hi all, The following requirements are quoted from https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-12#page-4 4<https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery-12#section-4>. Requirements This section describe the requirements for the BGP hop-by-hop routing deployments that were considered for the definition of the BGP Neighbor Discovery extensions proposed in this document. Following are the key requirements related for the BGP neighbor discovery process: 1. It should perform discovery of directly connected BGP routers. Mechanism should support either IPv4 or IPv6 or a dual stack design and it should be generic for any link-layer. 2. It should include exchange of BGP peering addresses (IPv4 or IPv6 or both) that routers can use to automatically setup BGP TCP peering between themselves. The mechanism should leverage the existing capability negotiation process performed as part of the BGP TCP session establishment. 3. When BGP peering is desired to be performed over loopback addresses of the routers, then the mechanism should automatically setup reachability to the loopback over one or more underlying directly connected links between them. In this scenario, the mechanism should also provide resolution for the BGP next-hop address (i.e. the loopback address) for the BGP routes exchanged over these sessions between the loopback addresses. 4. Mechanism should enable exchange of link-level information such as IP addresses and link attributes between the directly connected BGP routers. It should be extensible to include other information in the future. 5. Mechanism should be limited to link scope for security and use link-local addressing only. Cryptographic mechanisms should be also provided for additional security. 6. Mechanism should support capabilities for performing optional validation of parameters to detect misconfiguration (e.g. link address subnet mismatch, peering between incorrect AS, etc.) in an extensible manner before going on to use the link and the setup of the BGP TCP peering session over it. 7. The mechanism should not affect or change the BGP TCP session establishment procedures and the BGP routing exchange over the TCP session other than the interactions for triggering the setup/ removal of peer session that is based on discovery mechanism. 8. The mechanism should leverage existing fast-detection techniques for failures that are used currently for EBGP sessions over directly connected links like fast-external-failover and BFD. 9. The mechanism should focus on the discovery process and exchange of status as a control plane procedure and be sufficiently loosely coupled with the base BGP operations to enable implementations to ensure scalability of BGP operations when using the discovery procedures. Best regards, Xiaohu ------------------------------------------------------------------ From:Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> Send Time:2020年2月25日(星期二) 23:28 To:bgp-autoconf@ietf.org <bgp-autoconf@ietf.org<mailto:bgp-autoconf@ietf.org>> Subject:[Bgp-autoconf] Minutes and action points of the conference call Hi all, First of all, thank you for attending the conference call, we had good discussion on several items, and many thanks to Sue and others who helped with the minutes. The minutes is on https://etherpad.ietf.org:9009/p/bgp-autoconf-feb-25, please check if you want to make any change to it. I also summarized our discussion and action points as below: - We agreed to work on DC first, while keep an eye on what makes the other cases different. - For DC case, will focus on intra-data center which uses BGP as underlay, either interface addresses or loopbacks can be used for peering. Inter-DC and VPNs are out of scope. - We had some discussion about whether we should cover the misconnectivity or misconfiguration detection, there is still no clear result. - The team agrees that discovering the role of a device could be useful, something similar has been used in RIFT. - We discussed the security requirements, the authentication has two properties, transport or object security, and authenticating the peer. - In order to reduce the number of parallel peers between two nodes, need to use loopbacks to setup only one session, then need to consider how to automatically generate the configuration of routes to peer’s loopback. - Enablement of BFD based on auto-discovery is considered as one optional function, while the complexity needs to be considered. - Some considerations on Zero touch provisioning (ZTP). It is assumed some level of provisioning/pre-configuration is still required. The team agrees to look at the list of solution drafts, summarize the requirements from each draft, and find a minimal common set. Action points: 1. The author of each draft to summarize the list of requirement from his draft, and share it on design team list. (by end of this Friday) 2. Other people can provide additional comments to the summarized requirements. (in next week) 3. The team to provide a minimal common set. Best regards, Jie
- [Bgp-autoconf] Minutes and action points of the c… Dongjie (Jimmy)
- Re: [Bgp-autoconf] Minutes and action points of t… Randy Bush
- Re: [Bgp-autoconf] Minutes and action points of t… Dongjie (Jimmy)
- Re: [Bgp-autoconf] Minutes and action points of t… 徐小虎(义先)
- Re: [Bgp-autoconf] Minutes and action points of t… Dongjie (Jimmy)