From nobody Wed May 13 07:38:43 2020 Return-Path: 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 4E2C23A0B92 for ; Wed, 13 May 2020 07:38:41 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 EiHwsG9rOwQg for ; Wed, 13 May 2020 07:38:39 -0700 (PDT) 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 128B33A0B2E for ; Wed, 13 May 2020 07:38:39 -0700 (PDT) Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C3479F0690E73F832B95 for ; Wed, 13 May 2020 15:38:37 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Wed, 13 May 2020 15:38:37 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 13 May 2020 22:38:34 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Wed, 13 May 2020 22:38:34 +0800 From: "Dongjie (Jimmy)" To: "bgp-autoconf@ietf.org" Thread-Topic: Move forward with bgp autoconf requirements and design principle Thread-Index: AdYpNA7kwObJ16uITyuAVIK7h4Vm9g== Date: Wed, 13 May 2020 14:38:34 +0000 Message-ID: <0d8841f4daf143439a237c91333744e4@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.186.102] Content-Type: multipart/alternative; boundary="_000_0d8841f4daf143439a237c91333744e4huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle X-BeenThere: bgp-autoconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP autoconfiguration design team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 14:38:41 -0000 --_000_0d8841f4daf143439a237c91333744e4huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, It's been some time since our presentation on the IDR virtual interim. On t= hat meeting we discussed the next steps, which include: 1. Confirm the minimal set of common requirements 2. Reach consensus on the design principles 3. Put the above two into a requirement document 4. Hand the solution discussion to the WG Currently we are still at the first step, while hopefully we could finalize= d the minimal set of common requirements quickly (by end of this month?) ba= sed on the discussions we had before. The minimal set of requirements we have are as below: * Support IPv4 and IPv6 address family * Support to use either interface or loopback address for BGP session * Support to discover the peering IP address * Support to discover the peering ASN * Support authentication of control message * Enable Layer 3 link liveness detection, such as BFD * The capability of communicating arbitrary attributes to peers according t= o operators' need Note the last one was under discussion before the virtual meeting, if you h= ave any opinion on it, please share it on this list. The second step may need more effort, which means more discussion on the ma= il list is encouraged, and we may arrange one or two conference calls if ne= eded. Once we get step 1 and 2 settled, step 3 should be relatively easier (hopef= ully:)). Inputs are always welcome. Thanks. Best regards, Jie --_000_0d8841f4daf143439a237c91333744e4huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

It’s been some time since= our presentation on the IDR virtual interim. On that meeting we discussed = the next steps, which include:

 

1. Confirm the minimal set of c= ommon requirements

2. Reach consensus on the desig= n principles

3. Put the above two into a req= uirement document

4. Hand the solution discussion= to the WG

 

Currently we are still at the f= irst step, while hopefully we could finalized the minimal set of common req= uirements quickly (by end of this month?) based on the discussions we had b= efore.

 

The minimal set of requirements= we have are as below:

 

• Support IPv4 and IPv6 address family

• Support to use either interface or loopback address for = BGP session

• Support to discover the peering IP address

• Support to discover the peering ASN

• Support authentication of control message

• Enable Layer 3 link liveness detection, such as BFD=

• The capability of communicating arbitrary attributes to peers according to = operators’ need

 

Note the last one was under dis= cussion before the virtual meeting, if you have any opinion on it, please s= hare it on this list.

 

The second step may need more e= ffort, which means more discussion on the mail list is encouraged, and we m= ay arrange one or two conference calls if needed.

 

Once we get step 1 and 2 settle= d, step 3 should be relatively easier (hopefullyJ).=

 

Inputs are always welcome. Than= ks.

 

Best regards,=

Jie

--_000_0d8841f4daf143439a237c91333744e4huaweicom_-- From nobody Wed May 27 09:46:38 2020 Return-Path: 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 934103A0F4D for ; Wed, 27 May 2020 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ms0M1Zes-Cle for ; Wed, 27 May 2020 09:46:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C4E123A0FA7 for ; Wed, 27 May 2020 09:46:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jdzC7-0002zU-7B; Wed, 27 May 2020 16:46:19 +0000 Date: Wed, 27 May 2020 09:46:18 -0700 Message-ID: From: Randy Bush To: "Dongjie (Jimmy)" Cc: "bgp-autoconf@ietf.org" In-Reply-To: <0d8841f4daf143439a237c91333744e4@huawei.com> References: <0d8841f4daf143439a237c91333744e4@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle X-BeenThere: bgp-autoconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP autoconfiguration design team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 16:46:36 -0000 so, a small attempt to move forward again git be found at https://git.rg.net/randy/draft-bgp-discovery-layers randy Network Working Group R. Bush Internet-Draft Arrcus, Inc. & Internet Initiative Japan Updates: 6811 (if approved) May 25, 2020 Intended status: Informational Expires: November 26, 2020 Trade-offs in BGP Peer Discovery draft-ymbk-bgp-discovery-layers-00 Abstract This draft is an exploration of the alternatives and trade-offs in BGP peer discovery at various layers in the stack. It is based on discussions in the IDR WG BGP Discovery Design Team. The current target environment is the datacenter; while keeping an eye not to preclude WAN deployment. This document is not intended to become an RFC. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 26, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bush Expires November 26, 2020 [Page 1] Internet-Draft Trade-offs in BGP Peer Discovery May 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction This draft is an exploration of the alternatives and trade-offs in BGP peer discovery at various layers in the stack. It is based on discussions in the IDR WG BGP Discovery Design Team. The current target environment is the datacenter; while keeping an eye not to preclude WAN deployment. This document is not intended to become an RFC. 2. Background Previous design team discussions converged on a number of aspects of the problem. 2.1. BGP is the Underlay The assumed environment has BGP used as the underlay routing protocol in data center. 2.2. Some Requirements Some requirements have been agreed by the design team as follows: o Support IPv4 and IPv6 address families, but do not assume both are available. o Support discovery of the peering addresses for the BGP session endpoints. o Support using either a device's external interface or one of its loopback addresses for the BGP session endpoint. o Support discovery of the peers' ASs. o Agree on any BGP session authentication and parameters. o Enable Layer 3 link liveness detection, such as BFD. 2.3. Simplicity The goal is to provide the minimal set of configuration parameters needed by BGP OPEN to successfully start a BGP peering. The goal is specifically not to replace or conflict with data exchanged during BGP OPEN. Multiple sources of truth are a recipe for complexity and hence painful errors. Simplicity is key. Features not absolutely needed will not be included in the design. Bush Expires November 26, 2020 [Page 2] Internet-Draft Trade-offs in BGP Peer Discovery May 2020 3. Assumptions BGP OPEN will do the heavy lifting. BGP discovery should not do anything that could be done by BGP OPEN. Two sources of the same data are a recipe for errors. BGP peering will be selective; every BGP speaker may not want to peer with every other speaker. Before BGP OPEN, there is discovery and there is choosing peers. After discovery, it would be nice if another exchange was not needed before BGP OPEN. 4. Needs of Discovery In discovery, an aspiring BGP speaker needs to discover: o The set of possible peers, o To start, discovery does not know the potential peers' layer three IP addresses. o Each one's attributes, a deployment defined set, e.g.: leaf, spine, ice cream flavor, ... These attributes are arbitrary and operator dependent. No assumptions should be made, code points assigned,, etc. o Each one's layer three peering address(es), and o Other attributes required for BGP OPEN to succeed, e.g. authentication data. 5. Operator Configuration Operator configuration should be able to decide at lest the following: o Select or otherwise filter which peers to actually try to BGP OPEN, o What parameters to use, e.g.: * IP addressing: IPv4, IPv6, Loopback, or Direct * Any special forwarding or routing needed for reaching the prospective peer, e.g., loopback, * AS numbering, and * BGP Authentication Options. Bush Expires November 26, 2020 [Page 3] Internet-Draft Trade-offs in BGP Peer Discovery May 2020 6. Success Criteria What are the criteria for success and failure of the design decisions, and how do we measure them? 7. Discovery at Layer Two BGP Discovery at Layer-2 would entail finding potential peers on a LAN or on Point-to-Point links, discovering their Layer-3 attributes such as IP addresses, etc. There are two available candidates for peer discovery at Layer-2, Link Layer Discovery Protocol, LLDP, and Layer 3 Discovery Protocol, L3DL [I-D.ietf-lsvr-l3dl]. 7.1. Link Layer Discovery Protocol (LLDP) LLDP is a widely deployed protocol with implementations for most devices. Unfortunately it does not currently reveal Layer-3 IP addresses. There is an early LLDPv2 development to extend it in IEEE. [I-D.acee-idr-lldp-peer-discovery] describes how to use the LLDP IETF Organizationally Specific TLV to augment the LLDP TLV set to transport BGP Config Sub-TLVs signaling o AFI, o IP address (IPv4 or IPv6), o Local ASs, o Local BGP Identifier (AKA, BGP Router ID), o Session Group-ID, o BGP [Authentication] Session Capabilities, and o Local Address (Next Hop). Which of these are really necessary could be discussed. 7.2. Layer-3 Discovery Protocol (L3DL) L3DL [I-D.ietf-lsvr-l3dl] is an ongoing development in the IETF LSVR Working Group with the goals of discovering IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness which may then be disseminated using BGP-SPF and similar protocols. L3DL Upper Layer Protocol Configuration, [I-D.ymbk-lsvr-l3dl-ulpc], details signaling the minimal set of parameters needed to start a BGP session with a discovered peer. Details such as loopback peering are handled by attributes in the L3DL protocol itself. Bush Expires November 26, 2020 [Page 4] Internet-Draft Trade-offs in BGP Peer Discovery May 2020 o AS number, o IP address, IPv4 or IPv6, and o BGP Authentication. L3DL and L3DL-ULPC have well-specified security mechanisms, see [I-D.ymbk-lsvr-l3dl-signing]. This is similar but not quite the sane as the needs of this IDR Design Team. E.g., L3DL is designed to meet more complex needs. L3DL's predecessor, LSOE, [I-D.ymbk-lsvr-lsoe], was simpler and might be a better candidate for adaptation. A week's work could customize the design for the IDR Design Team's needs. But ... Unlike LLDP, L3DL has only one implementation, and LSOE only one open source implementation, and neither is significantly deployed. 8. Discovery at Layer Three Discovery at Layer-3 can assume IP addressability, though the IP addresses of potential peers are not known a priori and need to be discovered before further negotiation. The principal problem would appear to be discovery at Layer-3, because one neither knows whether to use IPv4 or IPv6. This is exacerbated by the possibility of a potential peer not being on the local subnet, and hence broadcast and similar techniques may not be applicable. If one can assume point-to-point links , then discovery might try IPv6 link-local or even IPv4 link-local. Or maybe a link broadcast protocol. For switched or bridged multi-point which is at least on the same subnet, VLAN, etc., broadcasts might be a viable approach. There will be difficulty if one or both peers wish to use a loopback for peering. 9. Discovery at Layer Seven Peer discovery at Layer-7 requires application layer rendezvous mechanisms analogous to those used by LISP, [RFC6830] or the Bitcoin Protocol. If the infrastructure is at all complex, e.g. multi-segment or worse, then it will need prior routing/forwarding knowledge in order to reach the rendezvous. In a BGP centric deployment this could pose a chicken and egg problem. Bush Expires November 26, 2020 [Page 5] Internet-Draft Trade-offs in BGP Peer Discovery May 2020 Rendezvous approaches may appeal to deployments which favor a central control framework. On the other hand, those who favor distributed protocols will have the classic worries about fragility, redundancy, reliability, etc. 10. Security Considerations None yet, but there will be many. 11. Acknowledgments The IDR BGP Discovery Design Team. 12. IANA Considerations None 13. Normative References [I-D.acee-idr-lldp-peer-discovery] Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, "BGP Logical Link Discovery Protocol (LLDP) Peer Discovery", draft-acee-idr-lldp-peer-discovery-06 (work in progress), November 2019. [I-D.ietf-lsvr-l3dl] Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery and Liveness", draft-ietf-lsvr-l3dl-04 (work in progress), May 2020. [I-D.ymbk-lsvr-l3dl-signing] Bush, R. and R. Austein, "Layer 3 Discovery and Liveness Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in progress), May 2020. [I-D.ymbk-lsvr-l3dl-ulpc] Bush, R. and K. Patel, "L3DL Upper Layer Protocol Configuration", draft-ymbk-lsvr-l3dl-ulpc-03 (work in progress), May 2020. [I-D.ymbk-lsvr-lsoe] Bush, R., Austein, R., and K. Patel, "Link State Over Ethernet", draft-ymbk-lsvr-lsoe-03 (work in progress), November 2018. Bush Expires November 26, 2020 [Page 6] Internet-Draft Trade-offs in BGP Peer Discovery May 2020 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . Appendix A. Acknowledgements The authors wish to thank . Author's Address Randy Bush Arrcus, Inc. & Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US Email: randy@psg.com Bush Expires November 26, 2020 [Page 7] From nobody Wed May 27 19:56:01 2020 Return-Path: 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 398763A0B45; Wed, 27 May 2020 19:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com 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 nunFpBZFFPoA; Wed, 27 May 2020 19:55:58 -0700 (PDT) Received: from out0-148.mail.aliyun.com (out0-148.mail.aliyun.com [140.205.0.148]) (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 9F2913A0B4B; Wed, 27 May 2020 19:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1590634551; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=IqrTH8v+Jkgdh0+3EtZXlICPOE9dR4zN8g7QBzPwk5o=; b=Rvo9lJLh7IV/35ob0utPCaDsnX8QjNX/pkSjD3wS7c+JU59227Kiy6GK2GYUg8/6lQJSwzL8sCvQHguL7elzR/qtAFBZ5bnf1uOB/am80hoHN6XEkvGoywEGDuESeyAEOzI5BcVdBHXPGsERdvy4bHkDK9gdzpaKyYOVup86W3E= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R641e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01a16384; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=W4_5899425_v5ForWebDing_0A930BF4_1590633258223_o7001c260u; Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5899425_v5ForWebDing_0A930BF4_1590633258223_o7001c260u]) by e01l07447.eu6 at Thu, 28 May 2020 10:55:50 +0800 Date: Thu, 28 May 2020 10:55:50 +0800 From: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" To: "Bgp-autoconf" , "=?UTF-8?B?RG9uZ2ppZSAoSmltbXkp?=" Cc: "bgp-autoconf@ietf.org" Reply-To: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" Message-ID: <5d8a04e6-a4b4-4cbf-8fcb-ec70cca6f31f.xiaohu.xxh@alibaba-inc.com> X-Mailer: [Alimail-Mailagent revision 4][W4_5899425][v5ForWebDing][Safari] MIME-Version: 1.0 References: <0d8841f4daf143439a237c91333744e4@huawei.com>, x-aliyun-mail-creator: W4_5899425_v5ForWebDing_NjATW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA1LjEuMTUgKEtIVE1MLCBsaWtlIEdlY2tvKSBWZXJzaW9uLzEyLjAuMyBTYWZhcmkvNjA1LjEuMTU=XQ In-Reply-To: Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_26653_53818940_5ecf2836_bf6106" Archived-At: Subject: Re: [Bgp-autoconf] =?utf-8?q?Move_forward_with_bgp_autoconf_requirem?= =?utf-8?q?ents_and_design_principle?= X-BeenThere: bgp-autoconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP autoconfiguration design team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 02:56:00 -0000 ------=ALIBOUNDARY_26653_53818940_5ecf2836_bf6106 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlIGZvbGxvd2luZyBhbmFseXNpcyBvbiBkaXNjb3ZlcnkgYXQgbGF5ZXIzIHN1cnByaXNlZCBt ZS4gU2VlIG15IGNvbW1lbnRzIGlubGluZS4KCgo4LiAgRGlzY292ZXJ5IGF0IExheWVyIFRocmVl CgogICBEaXNjb3ZlcnkgYXQgTGF5ZXItMyBjYW4gYXNzdW1lIElQIGFkZHJlc3NhYmlsaXR5LCB0 aG91Z2ggdGhlIElQCiAgIGFkZHJlc3NlcyBvZiBwb3RlbnRpYWwgcGVlcnMgYXJlIG5vdCBrbm93 biBhIHByaW9yaSBhbmQgbmVlZCB0byBiZQogICBkaXNjb3ZlcmVkIGJlZm9yZSBmdXJ0aGVyIG5l Z290aWF0aW9uLgoKW1hpYW9odV0gSXQgaGFzIGJlZW4gcHJvdmVuIHRoYXQgbXVsdGljYXN0IGlz IGEgZ29vZCBjaG9pY2UgdG8gYWRkcmVzcyB0aGUgYWJvdmUgY29uY2Vybi4gRm9yIG1vcmUgZGV0 YWlscywgcmVmZXIgdG8gTERQIHBlZXIgZGlzY292ZXJ5IG1lY2hhbmlzbTopCgogICBUaGUgcHJp bmNpcGFsIHByb2JsZW0gd291bGQgYXBwZWFyIHRvIGJlIGRpc2NvdmVyeSBhdCBMYXllci0zLAog ICBiZWNhdXNlIG9uZSBuZWl0aGVyIGtub3dzIHdoZXRoZXIgdG8gdXNlIElQdjQgb3IgSVB2Ni4g IFRoaXMgaXMKICAgZXhhY2VyYmF0ZWQgYnkgdGhlIHBvc3NpYmlsaXR5IG9mIGEgcG90ZW50aWFs IHBlZXIgbm90IGJlaW5nIG9uIHRoZQogICBsb2NhbCBzdWJuZXQsIGFuZCBoZW5jZSBicm9hZGNh c3QgYW5kIHNpbWlsYXIgdGVjaG5pcXVlcyBtYXkgbm90IGJlCiAgIGFwcGxpY2FibGUuCgpbWGlh b2h1XSBBcmUgeW91IGludGVuZGVkIHRvIHBlcmZvcm0gcGVlciBkaXNjb3Zlcnkgd2l0aCB1bnRy dXN0ZWQgZGV2aWNlcyB3aGljaCBhcmUgbm90IHVuZGVyIHlvdXIgY29udHJvbD8gSWYgbm90LCB3 aHkgZG9uJ3QgeW91IGtub3cgd2hldGhlciB0byB1c2UgSVB2NCBvciBJUHY2IHdpdGhpbiB5b3Vy IG93biBuZXR3b3JrIChlLmcuLCB0aGUgZGF0YWNlbnRlciBuZXR3b3JrIG9yIG1ldHJvIG5ldHdv cmsgd2hpY2ggYXJlIHRoZSBtYWpvciBzY2VuYXJpb3MgZm9yIEJHUCBwZWVyIGF1dG8tZGlzY292 ZXJ5KT8KCiAgIElmIG9uZSBjYW4gYXNzdW1lIHBvaW50LXRvLXBvaW50IGxpbmtzICwgdGhlbiBk aXNjb3ZlcnkgbWlnaHQgdHJ5CiAgIElQdjYgbGluay1sb2NhbCBvciBldmVuIElQdjQgbGluay1s b2NhbC4gIE9yIG1heWJlIGEgbGluayBicm9hZGNhc3QKICAgcHJvdG9jb2wuCgogICBGb3Igc3dp dGNoZWQgb3IgYnJpZGdlZCBtdWx0aS1wb2ludCB3aGljaCBpcyBhdCBsZWFzdCBvbiB0aGUgc2Ft ZQogICBzdWJuZXQsIFZMQU4sIGV0Yy4sIGJyb2FkY2FzdHMgbWlnaHQgYmUgYSB2aWFibGUgYXBw cm9hY2guCgpbWGlhb2h1XSBJdCBoYXMgYmVlbiBwcm92ZW4gdGhhdCBtdWx0aWNhc3QgaXMgYXBw bGljYWJsZSB0byBib3RoIHAycCBhbmQgYnJvYWRjYXN0IG5ldHdvcmtzLiAKCiAgIFRoZXJlIHdp bGwgYmUgZGlmZmljdWx0eSBpZiBvbmUgb3IgYm90aCBwZWVycyB3aXNoIHRvIHVzZSBhIGxvb3Bi YWNrCiAgIGZvciBwZWVyaW5nLgoKW1hpYW9odV0gSSB3b3VsZCBsaWtlIHRvIGtub3cgd2hhdCdz IHRoZSBleGFjdCBkaWZmaWN1bHR5IGluIHVzaW5nIGxvb3BiYWNrIGFkZHJlc3NlcyBmb3IgQkdQ IHNlc3Npb24gZXN0YWJsaXNobWVudD8gCgpCZXN0IHJlZ2FyZHMsClhpYW9odQoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkJ1c2ggICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMjYsIDIwMjAgICAgICAgICAgICAgICBbUGFnZSA3XQoKLS0gCkJncC1hdXRvY29uZiBt YWlsaW5nIGxpc3QKQmdwLWF1dG9jb25mQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYmdwLWF1dG9jb25mCgo= ------=ALIBOUNDARY_26653_53818940_5ecf2836_bf6106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImxpbmUt aGVpZ2h0OjEuNztmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4IC4wcHgg LjBweCAzMC4wcHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQt c2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPlRoZSBmb2xsb3dpbmcgYW5hbHlzaXMmbmJzcDtv biBkaXNjb3ZlcnkgYXQgbGF5ZXIzIHN1cnByaXNlZCBtZS4gU2VlIG15IGNvbW1lbnRzIGlubGlu ZS48YnIgPjxiciA+PGJyID44LiZuYnNwOyZuYnNwO0Rpc2NvdmVyeSZuYnNwO2F0Jm5ic3A7TGF5 ZXImbmJzcDtUaHJlZTxiciA+PGJyID4mbmJzcDsmbmJzcDsmbmJzcDtEaXNjb3ZlcnkmbmJzcDth dCZuYnNwO0xheWVyLTMmbmJzcDtjYW4mbmJzcDthc3N1bWUmbmJzcDtJUCZuYnNwO2FkZHJlc3Nh YmlsaXR5LCZuYnNwO3Rob3VnaCZuYnNwO3RoZSZuYnNwO0lQPGJyID4mbmJzcDsmbmJzcDsmbmJz cDthZGRyZXNzZXMmbmJzcDtvZiZuYnNwO3BvdGVudGlhbCZuYnNwO3BlZXJzJm5ic3A7YXJlJm5i c3A7bm90Jm5ic3A7a25vd24mbmJzcDthJm5ic3A7cHJpb3JpJm5ic3A7YW5kJm5ic3A7bmVlZCZu YnNwO3RvJm5ic3A7YmU8YnIgPiZuYnNwOyZuYnNwOyZuYnNwO2Rpc2NvdmVyZWQmbmJzcDtiZWZv cmUmbmJzcDtmdXJ0aGVyJm5ic3A7bmVnb3RpYXRpb24uPC9kaXY+PGRpdiAgc3R5bGU9Im1hcmdp bjouMHB4IC4wcHggLjBweCAzMC4wcHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGks U2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPjxiciA+PC9kaXY+PGRpdiAg c3R5bGU9Im1hcmdpbjouMHB4IC4wcHggLjBweCAzMC4wcHg7Zm9udC1mYW1pbHk6VGFob21hLEFy aWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPltYaWFv aHVdIEl0IGhhcyBiZWVuIHByb3ZlbiB0aGF0IG11bHRpY2FzdCBpcyBhIGdvb2QgY2hvaWNlIHRv IGFkZHJlc3MgdGhlIGFib3ZlIGNvbmNlcm4uIEZvciBtb3JlIGRldGFpbHMsIHJlZmVyIHRvJm5i c3A7TERQIHBlZXIgZGlzY292ZXJ5IG1lY2hhbmlzbTopPGJyID48YnIgPiZuYnNwOyZuYnNwOyZu YnNwO1RoZSZuYnNwO3ByaW5jaXBhbCZuYnNwO3Byb2JsZW0mbmJzcDt3b3VsZCZuYnNwO2FwcGVh ciZuYnNwO3RvJm5ic3A7YmUmbmJzcDtkaXNjb3ZlcnkmbmJzcDthdCZuYnNwO0xheWVyLTMsPGJy ID4mbmJzcDsmbmJzcDsmbmJzcDtiZWNhdXNlJm5ic3A7b25lJm5ic3A7bmVpdGhlciZuYnNwO2tu b3dzJm5ic3A7d2hldGhlciZuYnNwO3RvJm5ic3A7dXNlJm5ic3A7SVB2NCZuYnNwO29yJm5ic3A7 SVB2Ni4mbmJzcDsmbmJzcDtUaGlzJm5ic3A7aXM8YnIgPiZuYnNwOyZuYnNwOyZuYnNwO2V4YWNl cmJhdGVkJm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtwb3NzaWJpbGl0eSZuYnNwO29mJm5ic3A7YSZu YnNwO3BvdGVudGlhbCZuYnNwO3BlZXImbmJzcDtub3QmbmJzcDtiZWluZyZuYnNwO29uJm5ic3A7 dGhlPGJyID4mbmJzcDsmbmJzcDsmbmJzcDtsb2NhbCZuYnNwO3N1Ym5ldCwmbmJzcDthbmQmbmJz cDtoZW5jZSZuYnNwO2Jyb2FkY2FzdCZuYnNwO2FuZCZuYnNwO3NpbWlsYXImbmJzcDt0ZWNobmlx dWVzJm5ic3A7bWF5Jm5ic3A7bm90Jm5ic3A7YmU8YnIgPiZuYnNwOyZuYnNwOyZuYnNwO2FwcGxp Y2FibGUuPC9kaXY+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4IC4wcHggLjBweCAzMC4wcHg7Zm9u dC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29s b3I6IzAwMDAwMDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4IC4wcHggLjBw eCAzMC4wcHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6 ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPltYaWFvaHVdIEFyZSB5b3UgaW50ZW5kZWQgdG8gcGVy Zm9ybSBwZWVyIGRpc2NvdmVyeSB3aXRoIHVudHJ1c3RlZCBkZXZpY2VzIHdoaWNoIGFyZSZuYnNw O25vdCB1bmRlciB5b3VyIGNvbnRyb2w/IElmIG5vdCwgd2h5IGRvbid0IHlvdSBrbm93IHdoZXRo ZXIgdG8gdXNlIElQdjQgb3IgSVB2NiB3aXRoaW4geW91ciBvd24gbmV0d29yayAoZS5nLiwgdGhl IGRhdGFjZW50ZXIgbmV0d29yayBvciBtZXRybyBuZXR3b3JrIHdoaWNoIGFyZSB0aGUmbmJzcDtt YWpvciBzY2VuYXJpb3MgZm9yIEJHUCBwZWVyJm5ic3A7YXV0by1kaXNjb3ZlcnkpPzxiciA+PGJy ID4mbmJzcDsmbmJzcDsmbmJzcDtJZiZuYnNwO29uZSZuYnNwO2NhbiZuYnNwO2Fzc3VtZSZuYnNw O3BvaW50LXRvLXBvaW50Jm5ic3A7bGlua3MmbmJzcDssJm5ic3A7dGhlbiZuYnNwO2Rpc2NvdmVy eSZuYnNwO21pZ2h0Jm5ic3A7dHJ5PGJyID4mbmJzcDsmbmJzcDsmbmJzcDtJUHY2Jm5ic3A7bGlu ay1sb2NhbCZuYnNwO29yJm5ic3A7ZXZlbiZuYnNwO0lQdjQmbmJzcDtsaW5rLWxvY2FsLiZuYnNw OyZuYnNwO09yJm5ic3A7bWF5YmUmbmJzcDthJm5ic3A7bGluayZuYnNwO2Jyb2FkY2FzdDxiciA+ Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdG9jb2wuPC9kaXY+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4 IC4wcHggLjBweCAzMC4wcHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3Vu O2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPjxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Rm9yJm5ic3A7c3dpdGNoZWQmbmJzcDtvciZuYnNwO2JyaWRnZWQmbmJzcDttdWx0aS1wb2ludCZu YnNwO3doaWNoJm5ic3A7aXMmbmJzcDthdCZuYnNwO2xlYXN0Jm5ic3A7b24mbmJzcDt0aGUmbmJz cDtzYW1lPGJyID4mbmJzcDsmbmJzcDsmbmJzcDtzdWJuZXQsJm5ic3A7VkxBTiwmbmJzcDtldGMu LCZuYnNwO2Jyb2FkY2FzdHMmbmJzcDttaWdodCZuYnNwO2JlJm5ic3A7YSZuYnNwO3ZpYWJsZSZu YnNwO2FwcHJvYWNoLjxiciA+PGJyID5bWGlhb2h1XSBJdCBoYXMgYmVlbiBwcm92ZW4gdGhhdCBt dWx0aWNhc3QmbmJzcDtpcyBhcHBsaWNhYmxlIHRvIGJvdGggcDJwIGFuZCBicm9hZGNhc3QgbmV0 d29ya3MuJm5ic3A7PC9kaXY+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4IC4wcHggLjBweCAzMC4w cHg7Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4w cHg7Y29sb3I6IzAwMDAwMDsiPiZuYnNwOzxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlcmUmbmJz cDt3aWxsJm5ic3A7YmUmbmJzcDtkaWZmaWN1bHR5Jm5ic3A7aWYmbmJzcDtvbmUmbmJzcDtvciZu YnNwO2JvdGgmbmJzcDtwZWVycyZuYnNwO3dpc2gmbmJzcDt0byZuYnNwO3VzZSZuYnNwO2EmbmJz cDtsb29wYmFjazxiciA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Zm9yJm5ic3A7cGVlcmluZy48L2Rpdj48 ZGl2ICBzdHlsZT0ibWFyZ2luOi4wcHggLjBweCAuMHB4IDMwLjBweDtmb250LWZhbWlseTpUYWhv bWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+ PGJyID48L2Rpdj48ZGl2ICBzdHlsZT0ibWFyZ2luOi4wcHggLjBweCAuMHB4IDMwLjBweDtmb250 LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xv cjojMDAwMDAwOyI+W1hpYW9odV0gSSB3b3VsZCBsaWtlIHRvIGtub3cgd2hhdCdzIHRoZSBleGFj dCBkaWZmaWN1bHR5IGluIHVzaW5nIGxvb3BiYWNrIGFkZHJlc3NlcyBmb3IgQkdQIHNlc3Npb24g ZXN0YWJsaXNobWVudD8mbmJzcDs8L2Rpdj48ZGl2ICBzdHlsZT0ibWFyZ2luOi4wcHggLjBweCAu MHB4IDMwLjBweDtmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGJyID48L2Rpdj48ZGl2ICBzdHlsZT0ibWFyZ2lu Oi4wcHggLjBweCAuMHB4IDMwLjBweDtmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxT aW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+QmVzdCByZWdhcmRzLDwvZGl2 PjxkaXYgIHN0eWxlPSJtYXJnaW46LjBweCAuMHB4IC4wcHggMzAuMHB4O2ZvbnQtZmFtaWx5OlRh aG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7 Ij5YaWFvaHU8YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJyID48YnIg PjxiciA+PGJyID48YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJyID48 YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJyID48YnIgPjxiciA+PGJy ID5CdXNoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7RXhwaXJlcyZuYnNwO05vdmVtYmVyJm5ic3A7MjYsJm5ic3A7MjAyMCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tQYWdlJm5ic3A7N108YnIgPjxiciA+LS0mbmJz cDs8YnIgPkJncC1hdXRvY29uZiZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyID5CZ3AtYXV0b2Nv bmZAaWV0Zi5vcmc8YnIgPjxhICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2JncC1hdXRvY29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYmdwLWF1dG9jb25mPC9hPjwvZGl2PjxkaXYgIHN0eWxlPSJsaW5l LWhlaWdodDoyMC4wcHg7Y2xlYXI6Ym90aDsiPjxiciA+PC9kaXY+PC9kaXY+PC9kaXY+ ------=ALIBOUNDARY_26653_53818940_5ecf2836_bf6106-- From nobody Fri May 29 09:05:15 2020 Return-Path: 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 5CA863A0D7F for ; Fri, 29 May 2020 09:05:13 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 skNC7C4Ar8pl for ; Fri, 29 May 2020 09:05:11 -0700 (PDT) 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 4F5143A0E37 for ; Fri, 29 May 2020 09:04:48 -0700 (PDT) Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2D504168BE628E7D2BF6 for ; Fri, 29 May 2020 17:04:45 +0100 (IST) Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Fri, 29 May 2020 17:04:44 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 30 May 2020 00:04:42 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Sat, 30 May 2020 00:04:42 +0800 From: "Dongjie (Jimmy)" To: Randy Bush CC: "bgp-autoconf@ietf.org" Thread-Topic: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle Thread-Index: AdYpNA7kwObJ16uITyuAVIK7h4Vm9gKzzrMAAHHqx7A= Date: Fri, 29 May 2020 16:04:42 +0000 Message-ID: <6e6dca9ffe9b41839419715e1608ddef@huawei.com> References: <0d8841f4daf143439a237c91333744e4@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.184.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle X-BeenThere: bgp-autoconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP autoconfiguration design team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:05:13 -0000 Hi Randy,=20 Thanks a lot for putting things together into a document. IMO it can be con= sidered as the base of our deliverable to the WG, and other team members co= uld raise comments to specific text to help improving it. I'd suggest every= one to read it and give your comments to the list (It is good to see Xiaohu= already sent some comments) And please see some initial comments from my side inline: > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, May 28, 2020 12:46 AM > To: Dongjie (Jimmy) > Cc: bgp-autoconf@ietf.org > Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements > and design principle >=20 > so, a small attempt to move forward again >=20 > git be found at https://git.rg.net/randy/draft-bgp-discovery-layers >=20 > randy >=20 >=20 >=20 > Network Working Group R. > Bush > Internet-Draft Arrcus, Inc. & Internet Initiative Japan > Updates: 6811 (if approved) May 25, > 2020 > Intended status: Informational > Expires: November 26, 2020 >=20 >=20 > Trade-offs in BGP Peer Discovery > draft-ymbk-bgp-discovery-layers-00 >=20 > Abstract >=20 > This draft is an exploration of the alternatives and trade-offs in > BGP peer discovery at various layers in the stack. It is based on > discussions in the IDR WG BGP Discovery Design Team. The current > target environment is the datacenter; while keeping an eye not to > preclude WAN deployment. This document is not intended to become an > RFC. >=20 > Status of This Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at https://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on November 26, 2020. >=20 > Copyright Notice >=20 > Copyright (c) 2020 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (https://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 1] >=20 > Internet-Draft Trade-offs in BGP Peer Discovery May 2020 >=20 >=20 > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 > 1. Introduction >=20 > This draft is an exploration of the alternatives and trade-offs in > BGP peer discovery at various layers in the stack. It is based on > discussions in the IDR WG BGP Discovery Design Team. The current > target environment is the datacenter; while keeping an eye not to > preclude WAN deployment. This document is not intended to become an > RFC. >=20 > 2. Background >=20 > Previous design team discussions converged on a number of aspects of > the problem. >=20 > 2.1. BGP is the Underlay >=20 > The assumed environment has BGP used as the underlay routing protocol > in data center. >=20 > 2.2. Some Requirements >=20 > Some requirements have been agreed by the design team as follows: >=20 > o Support IPv4 and IPv6 address families, but do not assume both are > available. > o Support discovery of the peering addresses for the BGP session > endpoints. > o Support using either a device's external interface or one of its > loopback addresses for the BGP session endpoint. > o Support discovery of the peers' ASs. > o Agree on any BGP session authentication and parameters. > o Enable Layer 3 link liveness detection, such as BFD. >=20 > 2.3. Simplicity >=20 > The goal is to provide the minimal set of configuration parameters > needed by BGP OPEN to successfully start a BGP peering. The goal is > specifically not to replace or conflict with data exchanged during > BGP OPEN. Multiple sources of truth are a recipe for complexity and > hence painful errors. >=20 > Simplicity is key. Features not absolutely needed will not be > included in the design. >=20 >=20 >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 2] >=20 > Internet-Draft Trade-offs in BGP Peer Discovery May 2020 >=20 >=20 > 3. Assumptions >=20 > BGP OPEN will do the heavy lifting. >=20 > BGP discovery should not do anything that could be done by BGP OPEN. > Two sources of the same data are a recipe for errors. >=20 > BGP peering will be selective; every BGP speaker may not want to peer > with every other speaker. >=20 > Before BGP OPEN, there is discovery and there is choosing peers. >=20 > After discovery, it would be nice if another exchange was not needed > before BGP OPEN. >=20 > 4. Needs of Discovery >=20 > In discovery, an aspiring BGP speaker needs to discover: >=20 > o The set of possible peers, > o To start, discovery does not know the potential peers' layer three > IP addresses. > o Each one's attributes, a deployment defined set, e.g.: leaf, > spine, ice cream flavor, ... These attributes are arbitrary and > operator dependent. No assumptions should be made, code points > assigned,, etc. > o Each one's layer three peering address(es), and > o Other attributes required for BGP OPEN to succeed, e.g. > authentication data. The second bullet maybe more close to "assumptions"? And perhaps the rest of list could merge with section 2.2?=20 >=20 > 5. Operator Configuration >=20 > Operator configuration should be able to decide at lest the > following: >=20 > o Select or otherwise filter which peers to actually try to BGP > OPEN, > o What parameters to use, e.g.: >=20 > * IP addressing: IPv4, IPv6, Loopback, or Direct > * Any special forwarding or routing needed for reaching the > prospective peer, e.g., loopback, > * AS numbering, and > * BGP Authentication Options. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 3] >=20 > Internet-Draft Trade-offs in BGP Peer Discovery May 2020 >=20 >=20 > 6. Success Criteria >=20 > What are the criteria for success and failure of the design > decisions, and how do we measure them? In my understanding this is about the design principle as mentioned in our = slides on IDR virtual meeting. Here I put the summarized bullets here for r= eference, and we can have some discussion about each of them, and pick the = common set agreed by the team.=20 o Independent from BGP session establishment o Not affect or change BGP session establishment and routing exchange, othe= r than the interactions for triggering the setup/removal of peer session ba= sed on discovery mechanism o Generic for any link-layer protocol o Make use of a currently implemented and deployed DC switch protocol to re= duce the cost and complexity o Make use of existing BGP protocol for automating the BGP session bring-up o Widely applicable to a range of routing and similar protocols which need = layer 3 discovery and characterization o Length of the message size supported >=20 > 7. Discovery at Layer Two >=20 > BGP Discovery at Layer-2 would entail finding potential peers on a > LAN or on Point-to-Point links, discovering their Layer-3 attributes > such as IP addresses, etc. >=20 > There are two available candidates for peer discovery at Layer-2, > Link Layer Discovery Protocol, LLDP, and Layer 3 Discovery Protocol, > L3DL [I-D.ietf-lsvr-l3dl]. >=20 > 7.1. Link Layer Discovery Protocol (LLDP) >=20 > LLDP is a widely deployed protocol with implementations for most > devices. Unfortunately it does not currently reveal Layer-3 IP > addresses. There is an early LLDPv2 development to extend it in > IEEE. >=20 > [I-D.acee-idr-lldp-peer-discovery] describes how to use the LLDP IETF > Organizationally Specific TLV to augment the LLDP TLV set to > transport BGP Config Sub-TLVs signaling >=20 > o AFI, > o IP address (IPv4 or IPv6), > o Local ASs, > o Local BGP Identifier (AKA, BGP Router ID), > o Session Group-ID, > o BGP [Authentication] Session Capabilities, and > o Local Address (Next Hop). >=20 > Which of these are really necessary could be discussed. >=20 > 7.2. Layer-3 Discovery Protocol (L3DL) >=20 > L3DL [I-D.ietf-lsvr-l3dl] is an ongoing development in the IETF LSVR > Working Group with the goals of discovering IP Layer-3 attributes of > links, such as neighbor IP addressing, logical link IP encapsulation > abilities, and link liveness which may then be disseminated using > BGP-SPF and similar protocols. >=20 > L3DL Upper Layer Protocol Configuration, [I-D.ymbk-lsvr-l3dl-ulpc], > details signaling the minimal set of parameters needed to start a BGP > session with a discovered peer. Details such as loopback peering are > handled by attributes in the L3DL protocol itself. >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 4] >=20 > Internet-Draft Trade-offs in BGP Peer Discovery May 2020 >=20 >=20 > o AS number, > o IP address, IPv4 or IPv6, and > o BGP Authentication. >=20 > L3DL and L3DL-ULPC have well-specified security mechanisms, see > [I-D.ymbk-lsvr-l3dl-signing]. >=20 > This is similar but not quite the sane as the needs of this IDR > Design Team. E.g., L3DL is designed to meet more complex needs. > L3DL's predecessor, LSOE, [I-D.ymbk-lsvr-lsoe], was simpler and might > be a better candidate for adaptation. A week's work could customize > the design for the IDR Design Team's needs. But ... >=20 > Unlike LLDP, L3DL has only one implementation, and LSOE only one open > source implementation, and neither is significantly deployed. As you mentioned the implementation status of L3DL here, if possible perhap= s the implementation of L3DL-ulpc and the LLDP extensions in previous secti= on could also be provided, as it would be helpful if some experience could = be learned and documented, which would guide the design in the next step. >=20 > 8. Discovery at Layer Three >=20 > Discovery at Layer-3 can assume IP addressability, though the IP > addresses of potential peers are not known a priori and need to be > discovered before further negotiation. >=20 > The principal problem would appear to be discovery at Layer-3, > because one neither knows whether to use IPv4 or IPv6. This is > exacerbated by the possibility of a potential peer not being on the > local subnet, and hence broadcast and similar techniques may not be > applicable. >=20 > If one can assume point-to-point links , then discovery might try > IPv6 link-local or even IPv4 link-local. Or maybe a link broadcast > protocol. >=20 > For switched or bridged multi-point which is at least on the same > subnet, VLAN, etc., broadcasts might be a viable approach. >=20 > There will be difficulty if one or both peers wish to use a loopback > for peering. Some information about another existing proposal draft-xu-neighbor-autodisc= overy may also be included in this document. Perhaps Xiaohu could help with= some text?=20 >=20 > 9. Discovery at Layer Seven >=20 > Peer discovery at Layer-7 requires application layer rendezvous > mechanisms analogous to those used by LISP, [RFC6830] or the Bitcoin > Protocol. >=20 > If the infrastructure is at all complex, e.g. multi-segment or worse, > then it will need prior routing/forwarding knowledge in order to > reach the rendezvous. In a BGP centric deployment this could pose a > chicken and egg problem. >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 5] >=20 > Internet-Draft Trade-offs in BGP Peer Discovery May 2020 >=20 >=20 > Rendezvous approaches may appeal to deployments which favor a central > control framework. >=20 > On the other hand, those who favor distributed protocols will have > the classic worries about fragility, redundancy, reliability, etc. This section is interesting, although we didn't have discussion about this = category before (based on my memory). Is this also related to the Sparse pe= ering model in BGP-SPF? Or maybe I misunderstood your intention here.=20 Best regards, Jie >=20 > 10. Security Considerations >=20 > None yet, but there will be many. >=20 > 11. Acknowledgments >=20 > The IDR BGP Discovery Design Team. >=20 > 12. IANA Considerations >=20 > None >=20 > 13. Normative References >=20 > [I-D.acee-idr-lldp-peer-discovery] > Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, > "BGP Logical Link Discovery Protocol (LLDP) Peer > Discovery", draft-acee-idr-lldp-peer-discovery-06 (work in > progress), November 2019. >=20 > [I-D.ietf-lsvr-l3dl] > Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery > and Liveness", draft-ietf-lsvr-l3dl-04 (work in progress), > May 2020. >=20 > [I-D.ymbk-lsvr-l3dl-signing] > Bush, R. and R. Austein, "Layer 3 Discovery and Liveness > Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in > progress), May 2020. >=20 > [I-D.ymbk-lsvr-l3dl-ulpc] > Bush, R. and K. Patel, "L3DL Upper Layer Protocol > Configuration", draft-ymbk-lsvr-l3dl-ulpc-03 (work in > progress), May 2020. >=20 > [I-D.ymbk-lsvr-lsoe] > Bush, R., Austein, R., and K. Patel, "Link State Over > Ethernet", draft-ymbk-lsvr-lsoe-03 (work in progress), > November 2018. >=20 >=20 >=20 >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 6] >=20 > Internet-Draft Trade-offs in BGP Peer Discovery May 2020 >=20 >=20 > [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The > Locator/ID Separation Protocol (LISP)", RFC 6830, > DOI 10.17487/RFC6830, January 2013, > . >=20 > Appendix A. Acknowledgements >=20 > The authors wish to thank . >=20 > Author's Address >=20 > Randy Bush > Arrcus, Inc. & Internet Initiative Japan > 5147 Crystal Springs > Bainbridge Island, Washington 98110 > US >=20 > Email: randy@psg.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Bush Expires November 26, 2020 > [Page 7]