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

" 徐小虎(义先) " <xiaohu.xxh@alibaba-inc.com> Thu, 12 July 2018 09:33 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 C03DB13109F; Thu, 12 Jul 2018 02:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level:
X-Spam-Status: No, score=-1.019 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, 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 mgRr30zFF_IT; Thu, 12 Jul 2018 02:33:08 -0700 (PDT)
Received: from out0-158.mail.aliyun.com (out0-158.mail.aliyun.com [140.205.0.158]) (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 811EA130DFE; Thu, 12 Jul 2018 02:33:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1531387980; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=0EqKUgDuM9gH2rNV6IuRzZgmuW0y6TLWlsC7qxATPIk=; b=W6+z0MrHRGafdoOOCCaNMrv0mVu6ufJa8/8IDfillOTnF1gDUgdH3ikTXww2KQ8X9xOe6H3I1D+/yZPV8yiUe8coGJIEDtxDQFBj26XTdJTk5UOzD7HNoHcOx5blctauSS2UaW/VaD7jNIMMs2A7lmOBGHP1NNp7ZVgF3X46/vw=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R641e4; CH=green; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l01425; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=7; SR=0; TI=W4_5305839_v5ForWebDing_0AC264B4_1531387693590_o7001c426k;
Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5305839_v5ForWebDing_0AC264B4_1531387693590_o7001c426k]) by e02c03272.eu6 at Thu, 12 Jul 2018 17:32:59 +0800
Date: Thu, 12 Jul 2018 17:32:59 +0800
From: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
To: rraszuk <rraszuk@gmail.com>
Cc: Idr <idr-bounces@ietf.org>, Gaurav Dawra <gdawra.ietf@gmail.com>, idr wg <idr@ietf.org>, lsvr-chairs <lsvr-chairs@ietf.org>, draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>, Susan Hares <shares@ndzh.com>
Reply-To: "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>
Message-ID: <28ef469c-19d6-43b8-a881-d697e7a8569c.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> <E0D48054-CE8E-44AE-AD22-D95F56CAF603@gmail.com> <7220CFF5-1AF7-4644-B078-E545BDF2E346@icloud.com> <242ed290-d6e9-41f9-931d-955e81f62f0d.xiaohu.xxh@alibaba-inc.com> <CA+b+ERn72WsAJj2Em4qZzDSiEcGbh1mhGO+CM0aD_JXPcOX6NQ@mail.gmail.com> <89530067-fe75-4301-ad0e-35f3891cbfaa.xiaohu.xxh@alibaba-inc.com>, <CA+b+ERn32brH+yqM5XQsu_uiW+Jp_kMeim86j_EDHbFhJogQVA@mail.gmail.com>
In-Reply-To: <CA+b+ERn32brH+yqM5XQsu_uiW+Jp_kMeim86j_EDHbFhJogQVA@mail.gmail.com>
x-aliyun-mail-creator: W4_5305839_v5ForWebDing_QvNTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA0LjUuNiAoS0hUTUwsIGxpa2UgR2Vja28pIFZlcnNpb24vMTEuMC4zIFNhZmFyaS82MDQuNS42La
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_83262_49347940_5b47204b_20a1ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/M3FiT8sICjQwPOXVh-sSdKCLN9E>
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: Thu, 12 Jul 2018 09:33:11 -0000

What's LSVR in your mind? isn't it built on the existing BGP code base?

By the way, have you heard any interest on this mechanism from users of the L2/L3VPN?:)

Xiaohu


------------------------------------------------------------------
From:Robert Raszuk <robert@raszuk.net>
Send Time:2018年7月12日(星期四) 17:13
To:徐小虎(义先) <xiaohu.xxh@alibaba-inc.com>
Cc:Idr <idr-bounces@ietf.org>; Gaurav Dawra <gdawra.ietf@gmail.com>; idr wg <idr@ietf.org>; lsvr-chairs <lsvr-chairs@ietf.org>; draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>; Susan Hares <shares@ndzh.com>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery


BGP code is a BGP code and regardless if this is running on a router in the Internet or in the MSDC , regardless if it comes from vendor X, Y or Z it is the same code base. 

It is *BAD*  idea to now glue BGP code base with LSVR. And this is first draft which attempts do so in a very subtle manner by proposing two TLVs. 

If we allow this to go through (because of sympathy to "reuse existing" approach) the consequences down the road will be rather ugly for all BGP based worlds (Internet, MSDC, but also enterprises with internal routing, users of L2 and L3VPN etc ...). 

Thx,
R.



On Thu, Jul 12, 2018 at 11:06 AM, 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com> wrote:

Robert,

The mechanism as described in this draft is only targeted for the MSDC where RFC7938 has been enabled. It's absolutely not targeted for the global routing system:)

Best regards,
Xiaohu

------------------------------------------------------------------
From:Robert Raszuk <robert@raszuk.net>
Send Time:2018年7月12日(星期四) 17:00
To:徐小虎(义先) <xiaohu.xxh@alibaba-inc.com>
Cc:Idr <idr-bounces@ietf.org>; Gaurav Dawra <gdawra.ietf@gmail.com>; idr wg <idr@ietf.org>; lsvr-chairs <lsvr-chairs@ietf.org>; draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>; Susan Hares <shares@ndzh.com>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery


And that is precisely what IMHO we should avoid. 

Clear separation from BGP global routing and BGP as IGP including LSVR is: 

- extremely important for stability of the former 
- very need for innovation and new features velocity of the latter 

Thx,
R.

On Thu, Jul 12, 2018 at 10:54 AM, 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com> wrote:
Hi Gunter, 

Thanks for your email and suggestion. I believe the BGP peer discovery mechanism as described in this draft is applicable to the use of BGP as IGP (https://tools.ietf.org/html/rfc7938) and LSVR as well. 

Ketan, one co-auhtor of this draft would present this draft on the LSVR session.

Best regards,
Xiaohu

------------------------------------------------------------------
From:Gunter Van De Velde <guntervandeveldecc=40icloud.com@dmarc.ietf.org>
Send Time:2018年7月12日(星期四) 15:24
To:Gaurav Dawra <gdawra.ietf@gmail.com>
Cc:idr wg <idr@ietf.org>; lsvr-chairs <lsvr-chairs@ietf.org>; draft-xu-idr-neighbor-autodiscovery <draft-xu-idr-neighbor-autodiscovery@ietf.org>; Susan Hares <shares@ndzh.com>
Subject:Re: [Idr] WG adoption call for draft-xu-idr-neighbor-autodiscovery

LSVR realises that there is need for a neighbour and liveliness detection mechanism, and is making effort to understand the particular LSVR requirements for a solution. 

From a very high level perspective, there are few ways to address the aspect of LSVR peer discovery and liveliness detection:
1) Create something new
2) Extend something existing
3) Re-use something existing

LSVR has no technology religion about any of these, and would like to progress with a solution space that most 
optimal answers the particular LSVR requirements. 

Within LSVR WG meeting at IETF102, there is time reserved to discuss about these matters, and if you feel interested, we could add this draft into the agenda?

Brgds,
G/





On 11 Jul 2018, at 19:39, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Sue,

Support.

1) Yes
2) Yes, BGP is most commonly used in most DCs. However, it may have applications beyond that.
3) yes, in order to simplify operations for DCs. Single CP is needed.
4) it should be reviewed by LSVR WG.

Gaurav

On Mon, Jul 2, 2018 at 10:08 AM, Susan Hares <shares@ndzh.com> wrote:
Greetings: 
This begins a 2 week WG adoption call for draft-xu-idr-neighbor-autodiscovery (July 2 – July 16).  
https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/
The authors of this draft should send their IPR statements in response to this email.  I hope the authors will ihelp their vacationing co-authors to respond by July 7th.  
The WG should consider the following: 
1) Does BGP need to have an autodiscovery mechanism for peers within Data Centers? 
2) Does this mechanism work for other deployments? 
3) If so, should be passed in BGP Hello message?  
Or should it be a part of another protocol (e.g. LLDP, BFD, etc). 
4) Does this interact with any of the LSVR work? 
I want to thank the authors for their patience while we sorted through some of the WG LC for other drafts.  We decided to wait until some of those discussion were cleared up prior to starting a new WG Adoption call.
Susan Hares 
_______________________________________________
 Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr



_______________________________________________
 Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr