Re: [Bier] WG adoption call for draft-chen-bier-frr-02

Greg Shepherd <gjshep@gmail.com> Thu, 01 April 2021 17:38 UTC

Return-Path: <gjshep@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13563A1CC4; Thu, 1 Apr 2021 10:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, 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 PUT1CCvBJ9zX; Thu, 1 Apr 2021 10:38:42 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 976073A1CC0; Thu, 1 Apr 2021 10:38:41 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id jy13so4088704ejc.2; Thu, 01 Apr 2021 10:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=gT+Ee7t/TK68oFZTIT+uIv3lDyJmmXvu0sID5ENTyCM=; b=qJq/zjg6bOhh6lbH/b8Pa5OasyLxuG9KfmuyRtybJqN8IOQW0avZle9h2BbJVr+dfc nICjHCPoFtzfT23Les1dmSoEYF4pm1tK6rAxAYw4PWc8JbCO2SY5HBXFno2NCqR0S9Y2 ssT+3e8YnYZrGdaF01xMrkOLPgpuSrjalwqQ1vGWcaYfVUA9aB7FNHiyB8dCilKVAKJU AzfDXelZ0yQUTrtPsf0Xg7+c8ST6wKQSoYcIEZ2wOX3aZo5w9QVs8wv03ae/wR2DVgKl fvftxCZ+jZ9NLPhlvVPWxLrnC/P94QZqFjbxMVFuz9F0fzMBu/XnsDWYrEfKD0cNIRQo 43Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=gT+Ee7t/TK68oFZTIT+uIv3lDyJmmXvu0sID5ENTyCM=; b=Y62tWpIHBueNJzW+PCTiEtnfZ/gWC7knw/ChC3nB95TGl4+bz3w6p87HqEYu763Jrj 8cNEO5f3at9RHpGUMeqQVhwJWnZ6+aHfjqJ5ohLHo0tMcAQ/WA2T5oEYyFZ1MrmTwCCF 6vfgphbIF9NIJsOMN9mwDSaSAHoJx8z60jwLeBn3TOJa8HSvuPxKqSa9NTShsfMJlUqE mEmte4KsT0iyIAVJE0rANpbeccB28XPun8Px4YjysHdlCH7vLOWIENYYP/+0YGfRSB8K jwNva20aiLvksGcgCxj0qO84FIaFkhnTkn9VGOIDBO9eNMpYp5Fsxp7fqNS/VpYPPm/W wUXQ==
X-Gm-Message-State: AOAM531XlR7LKneBySVA0+p0E7FZaKYSnpfyxKsySel4oWQlCBLWXM8G gz1QMLHit+YOqwLJ57+7vh1HHcNYGDQwQ6ntOk2O30XAQbxszw==
X-Google-Smtp-Source: ABdhPJydLQGt4bRPHlpwBrr14Ls3yftcXEO9TdBdus829ZyVK82SA6BAZeFv43CrXWTl5OVxwgF0GbVGOMRtB66jhrQ=
X-Received: by 2002:a17:906:5597:: with SMTP id y23mr10419289ejp.165.1617298718007; Thu, 01 Apr 2021 10:38:38 -0700 (PDT)
MIME-Version: 1.0
References: <202103161440487606255@zte.com.cn> <CA+wi2hPLG_Og=rDerVqK7hMjkjUGxzjpQnZMSFMf965UVLCxNA@mail.gmail.com> <MN2PR13MB408751B2E8ACDF05AC9C34B3F2629@MN2PR13MB4087.namprd13.prod.outlook.com> <MN2PR05MB59811BDE5E469F7C39E253DAD47D9@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBqyAEtW=SmkbU_ub2CEOq+wDADmDyBuUz8Um_-oqKw93g@mail.gmail.com>
In-Reply-To: <CABFReBqyAEtW=SmkbU_ub2CEOq+wDADmDyBuUz8Um_-oqKw93g@mail.gmail.com>
Reply-To: gjshep@gmail.com
From: Greg Shepherd <gjshep@gmail.com>
Date: Thu, 1 Apr 2021 10:38:26 -0700
Message-ID: <CABFReBqEVTXu_u_STxemaoB6vRm0KpZA-hoeDcjiQyyXjxOd8g@mail.gmail.com>
To: BIER WG <bier@ietf.org>
Cc: BIER WG Chairs <bier-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000095235005beecb309"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/lILxBzTgl7nyNL49odNwSozpWKc>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 17:38:47 -0000

BIER WG,

>From my chair, there is clear WG consensus to merge the two drafts:

https://tools.ietf.org/html/draft-merling-bier-frr-00
https://datatracker.ietf.org/doc/draft-chen-bier-frr

We will have an adoption call on the new draft once published. The name of
the new draft isn't all that important, other than it should
accurately reflect the content of the draft. The author's name gets dropped
once adopted anyway, so I'm not certain why there would be concern for
who's 'taking' who's work. Especially since the discussion and
documentation of the described mechanisms have a history in the WG:

   1. When draft-chen was first presented, it was pointed out that
   draft-merling was already there:
   http://www.youtube.com/watch?v=AuzdpgePomA&t=33m51s and it was suggested
   to have a combined draft.
   2. While draft-merling does not talk about LFA based, the authors and
   some vendors/operators discussed  LFA based FRR back in 2019.  Michael
   mentioned it in this email
   https://mailarchive.ietf.org/arch/msg/bier/VRYfB7S7g7xuooIwV9XQDAW56hU/,
   and it was already covered in their paper
   https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth20c.pdf
   (the link was in that email as well).

Considering this history, the honest approach would be to submit the
combined draft as a new submission.

This new draft should be as all inclusive as possible of the FRR mechanisms
for BIER. If there is nothing documented on the wire then the draft should
be Informational. And as an Informational draft on FRR for BIER, there
needs to be a section on how the BIER architecture relies on unicast
reachability; ie, BFIB is built from the UFIB, and any FRR mechanism for
unicast will be inherited by BIER. Then the case, and mechanisms described
for non-IGP based BFIB will have context, and the draft will be a one-stop,
comprehensive Informational document on BIER-FRR.

The recommendation to have Jeffrey hold the pen as Editor, was rooted in
this expectation of a comprehensive draft. And to date, only Jeffrey Zhang
and Greg Mirsky have constantly expressed this same goal of including a
section documenting current IGP-based FRR mechanisms inherited by BIER. I
have not discussed this with Greg, but I'm putting his name out there as
another potential Editor/Author to assist in meeting the WG goals of a
comprehensive draft. Pick one or not (if they are willing to help..), the
WG goals for the draft remain.

Eventually the Authors' list will need to be edited, but that is not
required for adoption, of course. Again, pick now, or pick later. It will
be up to the list of combined Authors to decide who stays at the top. The
recommendation to keep the Authors' names at the top from filling the page
should be nothing new to anyone who has gone through the draft->publish
process in the IETF.

I hope this clarifies the recommended direction for this work and these
drafts. Thank you all for staying engaged and contributing to the process.

Cheers,
Shep
(Chairs)



On Tue, Mar 30, 2021 at 9:10 AM Greg Shepherd <gjshep@gmail.com> wrote:

> I agree with Jeffrey. The two drafts should be merged into a new draft,
> which we will then call to adopt. I suggest that the authors of each of the
> two docs:
>
> https://tools.ietf.org/html/draft-merling-bier-frr-00
> https://datatracker.ietf.org/doc/draft-chen-bier-frr
>
> ..contribute two authors to the merged doc effort, and have Jeffrey
> hold the pen as editor/author.
>
> All agreed?
>
> Thanks,
> Greg
> (Chairs)
>
> On Mon, Mar 29, 2021 at 7:26 PM Jeffrey (Zhaohui) Zhang <
> zzhang@juniper.net> wrote:
>
>> Shouldn’t it be the other way around – expand/merge first and then adopt?
>>
>>
>>
>> In fact, the essence of draft-chen is the multiple per-nbr FRR BIFTs,
>> which I don’t think should be included in the merged draft at all, for the
>> following problems:
>>
>>
>>
>>    1. Scaling – we need one extra BIFT for each <neighbor, BIFT>. This
>>    not only means extra memory, but also additional processing overhead
>>    including downloading the tables to the forwarding plane.
>>    2. If two neighbors fail simultaneously yet both can be protected by
>>    a 3rd neighbor, per-nbr FRR BIFTs can only give protection for one of
>>    the first two neighbors. This is not an unusual situation – you could have
>>    two neighbors reached by the same link or the same line card, and the
>>    link/card fails.
>>    3. Exactly when to switch back from a per-nbr FRR BIFT to the regular
>>    BIFT?
>>
>>
>>
>> The draft says the following about #3:
>>
>>
>>
>>    In general, when the routing protocol has re-converged on the new
>>
>>    topology taking into account the failure of X, the BIRT is re-
>>
>>    computed using the updated LSDB and the BIFT is re-derived from the
>>
>>    BIRT.  Once the BIFT is installed ready for activation, it is
>>
>>    activated to forward packets with BIER headers and the FRR-BIFT for X
>>
>>    is de-activated.
>>
>>
>>
>> Does that mean for each computation, you need to know and mark which
>> failed neighbor that it takes care of, so that when the BIFT is sent down
>> to forwarding plane you can decide if currently used FRR-BIFT can be
>> switched back to the main BIFT?
>>
>>
>>
>> Also consider the following:
>>
>>
>>
>>    1. At moment T you switch to FRR BIFT for nbr X
>>    2. At moment T+1ms a new BIFT is calculated, which takes care of a
>>    remote failure but not nbr X (nbr X is still considered up in this
>>    calculation) – would you switch FRR BIFT to the newly calculated main BIFT?
>>    If you don’t, the remote failure could lead to packet losses until the new
>>    main BIFT is used. If you do, you only get FRR protection for nbr X for 1ms.
>>
>>
>>
>> Jeffrey
>>
>>
>>
>> *From:* BIER <bier-bounces@ietf.org> *On Behalf Of * Huaimo Chen
>> *Sent:* Thursday, March 25, 2021 5:06 PM
>> *To:* Tony Przygienda <tonysietf@gmail.com>om>; EXT-zhang.zheng@zte.com.cn <
>> zhang.zheng@zte.com.cn>
>> *Cc:* BIER WG <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org>
>> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi Everyone,
>>
>>
>>
>>     Michael, Steffan, Huaimo and Mike met to discuss the merge and we are
>> in agreement that if draft-chen-bier-frr is adopted we will expand it to
>> include a framework along with the tunnel and LFA based solutions.
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>> ------------------------------
>>
>> *From:* BIER <bier-bounces@ietf.org> on behalf of Tony Przygienda <
>> tonysietf@gmail.com>
>> *Sent:* Tuesday, March 16, 2021 6:08 AM
>> *To:* zhang.zheng <zhang.zheng@zte.com.cn>
>> *Cc:* BIER WG <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org>
>> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>
>>
>>
>> +1
>>
>>
>>
>> I think it's a good addition within the architecture for the case IGP is
>> not used for signalling, e.g. when controller or static programming.
>>
>>
>>
>> The draft must however explain in what scenarios it is used and quote the
>> according IGP drafts to guarantee loop-free behavior (well, BIER will
>> tie-break loops but we'll have 1x microloop & possibly not deliver payload
>> if BIER FRR is not properly computed/intsalled). With that the draft should
>> also pay attention to how the function is deployed/updated network-wide if
>> IGP is not present
>>
>>
>>
>> thanks
>>
>>
>>
>> -- tony
>>
>>
>>
>> On Tue, Mar 16, 2021 at 7:41 AM <zhang.zheng@zte.com.cn> wrote:
>>
>> A 2-week WG adoption call begins for the following draft:
>>
>> https://datatracker.ietf.org/doc/draft-chen-bier-frr/
>> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-chen-bier-frr*2F&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C79ac63710b47427a558d08d8e8638df2*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637514861570555970*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=DiHvux0ZUYEJru10lVQ4mXvpYx3l8ujGInm7uEjjxTw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TtAnkZJhg9BEJjANzO6CusX7i7eQqvTJHdhaH0qrrPdtcykRPrUybhZeavPA3X4F$>
>>
>> Please indicate your support or objection by March 30th, 2021.
>>
>> Authors, please respond to the list indicating whether you are aware of
>> any IPR that applies to this draft.
>>
>> Thanks,
>>
>> Sandy (As WG secretary, on behalf of Greg/Tony)
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>