Re: [Bgp-autoconf] Move forward with bgp autoconf requirements and design principle

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 08 July 2020 18:02 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 D3EA73A059F for <bgp-autoconf@ietfa.amsl.com>; Wed, 8 Jul 2020 11:02:20 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 WMpSM00IexqG for <bgp-autoconf@ietfa.amsl.com>; Wed, 8 Jul 2020 11:02:19 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 45F7E3A0593 for <bgp-autoconf@ietf.org>; Wed, 8 Jul 2020 11:02:19 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id q17so4074762pls.9 for <bgp-autoconf@ietf.org>; Wed, 08 Jul 2020 11:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=JYS5EAmbULDQpdBnZSuQe1li14l+xByrLteMuKH6TKg=; b=hJvaIE2bUNBgkcHV3caJuNhjWY+htRFgS0jwDN+5WDgtPCbi+hqq1frHUk50UsdLbg VAYQOAImHon/hA/GPrvT44IrOi95U8EPXRRGyPFCBQ3lIel6mW6xa82d5gvjA1aVten+ L7De6RKeDZkHvhW+HYkhEuajXAS7BKvtizePUWLExM4dsalW67BiUQ0hs7ubTcAySEIp VP2gP7bwjq3zuXDFoo3AEwAJqkkLqfc1i9UIEX4kziUVsnwvy9TdUhFmuiC2pvM5H8DP F6X56XHCNWVreYlPo3VpHKQM5RAwJyvMUgY1WT9+pQg0VJStQAOPuKctIgCKfZTrD4Pk ZApQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=JYS5EAmbULDQpdBnZSuQe1li14l+xByrLteMuKH6TKg=; b=QOQeIWdbb5kCyLWDkYAShc+b0czcZH61QZKsv7jFN4MHPYwVjkJ24zogdZIF+umN16 RHVXindRnIjwGKOTD45/0cGaHtHNqJAUOGu8rKnIQLmKTvvhju3ADp/siUxuqnRJ+3PA ISYvTgan5wEwC8HazRxXVvL46Z3ZNVLAlljKwrErdmdpVuEuimQvk1nk7IOq/WolbjOc 3L4bFwuQXOR6ZzPT7TjtkwnDdTb8Y0wxQuDVoV2C1SlHqeDMXfavqHNO/sYeJcDiRRWQ LjY8XJJNcacfPb8wxM2Vo5rV6C2ffVA2e7oKkhTeG2/KzH9XR6Ep3CW1aAJTPqZTa80J XjJw==
X-Gm-Message-State: AOAM532oJr0taY+c0L3PzYrSmJG2aJcrej4eTOwMkILNPCSRVG1vx/47 5jgAASvMUGaPLfQFtuZuyMg=
X-Google-Smtp-Source: ABdhPJzwoRz4hZzaUIeRl0kho/Aqpy5jq7+WO2hkxX0CyyCW6ez3KltCqzVJfCtK3vXCs+65EVjRuw==
X-Received: by 2002:a17:90a:71c3:: with SMTP id m3mr11339823pjs.225.1594231338871; Wed, 08 Jul 2020 11:02:18 -0700 (PDT)
Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id q24sm472702pgg.3.2020.07.08.11.02.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 11:02:18 -0700 (PDT)
Date: Wed, 08 Jul 2020 11:02:11 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Randy Bush <randy@psg.com>, Robert Raszuk <robert@raszuk.net>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: "bgp-autoconf@ietf.org" <bgp-autoconf@ietf.org>
Message-ID: <ef565f58-c871-49ef-95c2-66cd5da62164@Spark>
In-Reply-To: <d5303a4df7834cbb9ed3c09831332b65@huawei.com>
References: <0d8841f4daf143439a237c91333744e4@huawei.com> <m2tv0172cl.wl-randy@psg.com> <6e6dca9ffe9b41839419715e1608ddef@huawei.com> <8d21cc950f784675a0f52fdf22f546e5@huawei.com> <CAOj+MME75tzRUm2PasSWfxSvEcO3tUix2fPHT=jm8wOjgXa0Hw@mail.gmail.com> <m2pn98ej2e.wl-randy@psg.com> <d5303a4df7834cbb9ed3c09831332b65@huawei.com>
X-Readdle-Message-ID: ef565f58-c871-49ef-95c2-66cd5da62164@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5f060a28_14d53685_11d67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/4ObjLS7-v8CcfIPStUVTD7dBLNg>
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 <bgp-autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bgp-autoconf/>
List-Post: <mailto:bgp-autoconf@ietf.org>
List-Help: <mailto:bgp-autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 18:02:21 -0000

Jie,

Sounds good, I don’t really see any convergence yet, so unbiased summary would be a great start

Cheers,
Jeff
On Jul 8, 2020, 8:47 AM -0700, Dongjie (Jimmy) <jie.dong@huawei.com>, wrote:
> Hi Randy and all,
>
> It is good we agreed on the scope of this document is DC. Certainly in the design team we can analyze and discuss the difference between the design for DC and WAN, my understanding is the details about it does not belong to this document.
>
> Coming back to the preparation of the draft deliverable, in addition to revising the existing text in the draft, my suggestion is to also add some brief description about each candidate solution regarding the functions, extensibility, etc., this may be similar to what was presented in the slides to the WG in last IETF meeting. I will work on some text and provide an update tomorrow. Any contribution to this is welcome.
>
> As for the design principle (including which layer the protocol should be based on and the interaction with BGP), if we cannot reach agreement before the meeting, probably we could provide a summary of the considerations first, and ask for some feedbacks from the WG. Thoughts?
>
> Best regards,
> Jie
>
> > -----Original Message-----
> > From: Randy Bush [mailto:randy@psg.com]
> > Sent: Monday, July 6, 2020 11:53 PM
> > To: Robert Raszuk <robert@raszuk.net>
> > Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; bgp-autoconf@ietf.org
> > Subject: Re: [Bgp-autoconf] Move forward with bgp autoconf requirements
> > and design principle
> >
> > > The draft in question specifically adds WAN auto conf.
> >
> > that was certainly not the intent; and it's not really there in the words. on
> > the other hand, if we should keep an eye on the WAN as we design the LAN,
> > we should be aware of choices which might unnecessarily restriict ourselves
> > next year.
> >
> > > Then the L3 peer auto discovery is just deferred to
> > > draft-ietf-lsvr-l3dl
> >
> > also not intended. i did ask for your help stitching multicast in, and you
> > declined. perhaps you have time now.
> >
> > > However reading thorough draft-ietf-lsvr-l3dl it is clear that it is
> > > not applicable to WAN.
> >
> > it is not applicable to many things :)
> >
> > as i said at the beginning, i do not think l3dl is really a serious candidate here.
> > otoh, we would be silly if we did not keep an eye to see if there are lessons to
> > be learned from it.
> >
> > [ fwiw, i think the scalability added to lsoe to become l3dl was not
> > worth the complexity. but that is a discussion for another universe ]
> >
> > randy
>
> --
> Bgp-autoconf mailing list
> Bgp-autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/bgp-autoconf