Re: [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements
"Susan Hares" <shares@ndzh.com> Mon, 10 June 2019 19:30 UTC
Return-Path: <shares@ndzh.com>
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 D5B561200B3; Mon, 10 Jun 2019 12:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 dMSs3361NhxC; Mon, 10 Jun 2019 12:30:10 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3879812008B; Mon, 10 Jun 2019 12:30:10 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.25.175.69;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Cc: lsvr@ietf.org
Date: Mon, 10 Jun 2019 15:30:05 -0400
Message-ID: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0203_01D51FA1.61A90440"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdUfwtnkXvyVBwtNTGCKb+kjo9I/HA==
Content-Language: en-us
X-Antivirus: AVG (VPS 190610-6, 06/10/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/toAvZz8G0OtC816mbcQ5acL4giU>
Subject: Re: [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-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: Mon, 10 Jun 2019 19:30:12 -0000
This is a list of requirements for autodiscovery from: draft-xu-idr-neighbor-autodiscovery requirements: --------------------------- 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. From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, June 10, 2019 3:26 PM To: idr@ietf.org Cc: lsvr@ietf.org Subject: [Idr] Issue 2: Auto-configuration Requirements IDR WG: Does IDR think that we should include a generalized auto-discovery protocol in the IDR WG charter? If so, should it be for WAN or Data Center or IPRAN topologies (grid/ring)? LSVR is progressing with Layer 3 liveness in draft-ietf-lsvr-l3dl-00 https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/ LSVR is progressing because IDR did not have a consensus on requirements for a general Layer 3 liveness protocol in 2018. This thread is to discuss the requirements for a generalized or a specific auto-discovery protocol associated with BGP. My next posts will contain the requirements for LSVR Layer 3 liveness and draft-xu-idr-neighbor-autodiscovery requirements https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/ Sue Hares
- Re: [Idr] Issue 2: Auto-configuration Requirement… Susan Hares
- Re: [Idr] [Lsvr] Issue 2: Auto-configuration Requ… Robert Raszuk
- Re: [Idr] [Lsvr] Issue 2: Auto-configuration Requ… Randy Bush
- Re: [Idr] [Lsvr] Issue 2: Auto-configuration Requ… Robert Raszuk
- Re: [Idr] [Lsvr] Issue 2: Auto-configuration Requ… Randy Bush
- Re: [Idr] [Lsvr] Issue 2: Auto-configuration Requ… Susan Hares