[Bgp-autoconf] Summarized requirements

"Dongjie (Jimmy)" <jie.dong@huawei.com> Mon, 02 March 2020 16:03 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 90F7C3A0A64; Mon, 2 Mar 2020 08:03:05 -0800 (PST)
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, HTML_MESSAGE=0.001, 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 bdge-QEYe2of; Mon, 2 Mar 2020 08:03:02 -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 492B43A0A08; Mon, 2 Mar 2020 08:03:02 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D882D1D4FA1282E979A3; Mon, 2 Mar 2020 16:02:59 +0000 (GMT)
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 2 Mar 2020 16:02:59 +0000
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml701-chm.china.huawei.com (10.98.57.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 3 Mar 2020 00:02:56 +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; Tue, 3 Mar 2020 00:02:56 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "bgp-autoconf@ietf.org" <bgp-autoconf@ietf.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>
Thread-Topic: Summarized requirements
Thread-Index: AdXwq+AS2E124aA3TECiMItBfrT2fw==
Date: Mon, 02 Mar 2020 16:02:56 +0000
Message-ID: <46f4bc24513b4d009d7e99f507037619@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.179.92]
Content-Type: multipart/alternative; boundary="_000_46f4bc24513b4d009d7e99f507037619huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/a6JCSbhvCFiqJG1TUeZTFyTeFj4>
Subject: [Bgp-autoconf] Summarized requirements
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: Mon, 02 Mar 2020 16:03:11 -0000

Hi all,

First of all, thanks again to the draft authors who send the summarized requirements from their drafts. I made a list based on the collected requirements, and tried to classify them into "common requirements", "union of other functional requirements" and "requirements about design principle":


1.       Common requirements



l  Support IPv4 and IPv6 address family

l  Support using interface or loopback address for BGP session

l  Support to discover the peering IP address

l  Support to discover the peering ASN

l  Support authentication of control message

l  Enable Layer 3 link liveness detection, such as BFD


2.       Union of other functional requirements (could be considered optional)


l  Discover mutually supported encapsulation

l  Provide Layer 2 keep-alive messages for session continuity

l  Discover the role of the connected nodes

l  Automatic setup of reachability to peer's loopback over one or more connected links

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

l  Enable exchange of IP addresses and link attributes between the directly connected BGP routers. should be extensible to include other information in future.

l  Discover neighbor's BGP ID for consistency check or avoid connection collision

l  Discovery parameters relating to the BGP peer session (e.g., the local address)

l  Mechanism should be limited to link scope for security and use link-local addressing only

l  Support optional validation of parameters to detect misconfiguration (e.g. link address subnet mismatch, peering between incorrect AS, etc.) in an extensible manner


3.       Requirements about design principle:


l  Independent from BGP session establishment

l  Widely applicable to a range of routing and similar protocols which need layer 3 discovery and characterization

l  Not affect or change BGP session establishment and routing exchange, other than the interactions for triggering the setup/removal of peer session that is based on discovery mechanism

l  Generic for any link-layer protocol

l  Make use of a currently implemented and deployed DC switch protocol to reduce the cost and complexity

l  Make use of existing BGP protocol for automating the BGP session bring-up

Firstly please check if there is any requirement I missed. Then I'd need your opinions on whether some requirement should be moved from the "other functional requirements" to the "common requirements" category, or vise versa. One example is "discover the role of the connected nodes" which seems was widely accepted on our conference call.

After the functional requirement lists are determined, we could move forward to have some further discussion about the design principle.

Thoughts?

Best regards,
Jie