IETF Logo Mail Archive

Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

" 徐小虎(义先) " <xiaohu.xxh@alibaba-inc.com> Fri, 13 July 2018 02:57 UTC

Return-Path: <xiaohu.xxh@alibaba-inc.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 9F030130DE3; Thu, 12 Jul 2018 19:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.02
X-Spam-Level:
X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gxdReDUPZPS5; Thu, 12 Jul 2018 19:57:44 -0700 (PDT)
Received: from out0-157.mail.aliyun.com (out0-157.mail.aliyun.com [140.205.0.157]) (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 051C5127332; Thu, 12 Jul 2018 19:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1531450657; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=HwhEK3e97VgslZH+fnkNRHExlaqSweXnEbYi986RYeA=; b=QXf1kAc13TW6d10L2hUndcKOhAtesBCQgWtixXp3L49XdF2AMBKjnZHpEqnH6bdQgVz5gndCFOhzwQ8DVX7iGTg6fCMcI5iyT7n/iW14bUv9EMw1vXZI4F07mMZDF6YFjNuxOQWjUyMhKbO7zXOBmgk/MrdRyrE0WaaEEhNqkik=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R691e4; CH=green; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e01546; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=5; SR=0; TI=W4_5305839_v5ForWebDing_0AC26464_1531449819764_o7001c6545;
Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5305839_v5ForWebDing_0AC26464_1531449819764_o7001c6545]) by e01l07390.eu6 at Fri, 13 Jul 2018 10:57:31 +0800
Date: Fri, 13 Jul 2018 10:57:31 +0800
From: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Eric C Rosen <erosen@juniper.net>
Cc: Susan Hares <shares@ndzh.com>, idr <idr@ietf.org>, draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>
Reply-To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
Message-ID: <79e465fc-bf5f-4dec-a97f-4eeeaf215e1b.xiaohu.xxh@alibaba-inc.com>
X-Mailer: [Alimail-Mailagent revision 268][W4_5305839][v5ForWebDing][Safari]
MIME-Version: 1.0
References: <013701d41227$579d2d10$06d78730$@ndzh.com> <d0ae2da8-e932-84f2-f634-3e0f280a6fb5@juniper.net>, <20180712200303.GU12853@pfrc.org>
In-Reply-To: <20180712200303.GU12853@pfrc.org>
x-aliyun-mail-creator: W4_5305839_v5ForWebDing_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA0LjUuNiAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTEuMC4zIFNhZmFyaS82MDQuNS42La
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_60671_4f038940_5b48151b_21c254"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/56Yq0Yrjba0qI1vaNsAbIwpzDGo>
Subject: Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 13 Jul 2018 02:57:47 -0000

Hi Jeff,

Thanks for pointing out that draft. Yes, it's a popular topic indeed :)

I just have a glance at that draft. If I understand it correctly, it was intended to advertise RRs' capabilities and therefore it should be designed for the iBGP scenario.

It seems that RFC7938 recommended to use eBGP rather than iBGP as an IGP within MSDCs (see below). In fact, many MSDCs do follow the EBGP-only design recommendations of RFC7938, AFAIK. The BGP neighbor auto-discovery mechanism as described in draft-xu-idr-neighbor-autodiscovery is applicable to those MSDCs which follows the recommendations of RFC7938.

5.1.  Choosing EBGP as the Routing Protocol

   REQ2 would give preference to the selection of a single routing
   protocol to reduce complexity and interdependencies.  While it is
   common to rely on an IGP in this situation, sometimes with either the
   addition of EBGP at the device bordering the WAN or Internal BGP
   (IBGP) throughout, this document proposes the use of an EBGP-only
   design.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Jeffrey Haas <jhaas@pfrc.org>
Send Time:2018年7月13日(星期五) 04:03
To:Eric C Rosen <erosen@juniper.net>
Cc:Susan Hares <shares@ndzh.com>; idr <idr@ietf.org>; draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

On Thu, Jul 12, 2018 at 10:35:12AM -0400, Eric C Rosen wrote:
> There is so much overlap with the idr-lldp-peer-discovery draft that
> I don't see how the WG could adopt both of them.  The
> idr-neighbor-autodiscovery draft thus should not be adopted unless
> the intention is to reject the idr-lldp-peer discovery draft. Is
> that the intention?  I don't recall seeing much discussion comparing
> and contrasting the two.

And not contradicting any of Eric's other good points, we have other work
happening outside of IDR that overlaps this auto discovery problem space:

https://datatracker.ietf.org/doc/draft-acee-ospf-bgp-rr/

Easy to say that it's a popular topic. :-)

-- Jeff

v2.23.0 | Report a Bug | By Email