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

Robert Raszuk <robert@raszuk.net> Thu, 12 July 2018 09:13 UTC

Return-Path: <rraszuk@gmail.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 12327130DC0; Thu, 12 Jul 2018 02:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WdJ3SBvYn0ot; Thu, 12 Jul 2018 02:12:59 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 6C2A512F1A2; Thu, 12 Jul 2018 02:12:59 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id b17-v6so20231209pfi.0; Thu, 12 Jul 2018 02:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QuRPIb6xKuf0lagO7y9ScXP6zll7I3bLhrzTmDc0Zx4=; b=vUmLBWQxh/gI84nokw+hUiYExQxnVI8Iny4P0MwByZEMGyPYafPpgNej/UpAotjRq4 qBQU5HkrYC1oVBC9B+zBLfCa+VPqncpzS+IRPxzSJA1L6vrXllx2vMzUFeCZAXstIPKq x6Lx0/sfCfps14/mAKTRwkNk80M2IbviILK3g8SnR3KSztx/EmRtb0TtD3UBcbHus60M HTVzIogZYTSdPuSUVKtGl1ekvKKsrXDrkp44AVzWx9nduEQ8zG/j0SZmtjNnFAzPvVeQ hhFwRMIbAY/E7Xd29kJn3XJsPg2NZ1Wtn8uAOmQmZ1DCZgnJj+ClnbH3Tes0jsr9p1D8 9lTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QuRPIb6xKuf0lagO7y9ScXP6zll7I3bLhrzTmDc0Zx4=; b=k7WgCLWY3hPszfmH2cu9EnWxCFgXvcnvo2biYknUzOqB5OyYXbTZQS34qFuuLbO1rF iVCc4A1vwpvoS5fiD5XVpsJPlObtQidmUrl3EzMniM9QLuuI7lVPK4RK+u+We1XHzenw h84HBsdjeJpKX474HLJ94RCalFu/BrjMpptFOsEvvhTszZv4qoXklpL6sRFHhjBEU6Dw w+/ow7pVcDXoNDI38b9mLP9OaHrUtv41fGPq+IZCj3aRWA1PHDgXBzsfJamJGlUEbEok vOrGCBRNNhXwfY9UUYD4dF8lMm+M9j17eEvxKJbWmkealGd5UKDVZYn9uyjqEKd6YrPI 0lQQ==
X-Gm-Message-State: AOUpUlHzsAlqCFReFWcZPncqax/4s/2FLJ4YYCrrkMN67Ztbw9d2d8oa SV/M9G8Cm2Bp8PI0tYCsll9Vqjfp8DGlaeig7UU=
X-Google-Smtp-Source: AAOMgpfDZGsUcuTc5DNUGHy577y3otvSb4qtuxRZlPC6ThU4h9JL+dqt4nuXMNxTkCDrvlV28NjGWTQl6Q7nkEuNjvE=
X-Received: by 2002:a65:5641:: with SMTP id m1-v6mr1390499pgs.246.1531386778668; Thu, 12 Jul 2018 02:12:58 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 2002:a17:90a:bd8e:0:0:0:0 with HTTP; Thu, 12 Jul 2018 02:12:58 -0700 (PDT)
In-Reply-To: <89530067-fe75-4301-ad0e-35f3891cbfaa.xiaohu.xxh@alibaba-inc.com>
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>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 12 Jul 2018 11:12:58 +0200
X-Google-Sender-Auth: dQwhlho34RHjM8qFQLAORP7H1Hc
Message-ID: <CA+b+ERn32brH+yqM5XQsu_uiW+Jp_kMeim86j_EDHbFhJogQVA@mail.gmail.com>
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>
Content-Type: multipart/alternative; boundary="000000000000f4d52c0570c9c489"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oDA3R6oKGjLp1xVa6_7dWxPLyqM>
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:13:01 -0000

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