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

Tony Przygienda <tonysietf@gmail.com> Mon, 22 March 2021 06:33 UTC

Return-Path: <tonysietf@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 6D2203A14E6; Sun, 21 Mar 2021 23:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level:
X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[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 vrEGtkk51nW1; Sun, 21 Mar 2021 23:33:08 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 309F03A14E0; Sun, 21 Mar 2021 23:33:08 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id b10so12735800iot.4; Sun, 21 Mar 2021 23:33:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i7uEtT4+puCpUqAMWjJERoEzJuCrtOcUGcqyXG5FVL0=; b=By6l6f6Qgaxp+qD5KIubRP1EgAYsdoEvSrHsPVZxDwjPqXhs0KeSy1QhcYBEeBYAOF W6Y3zVqhreLgd3wOSCibmCqhQoZ3EZWja9SpGwge9KbAXN/jBUODZwztpsoicksZ+yNE ObWbuuDmB+mKMXcyYuUvR2tl/d4RcvAWGEBZ6//UKddnSYeH70H3X53gLxJkmJF1uK6o kvRBgv9XnnYe7vZt4mQNB+bDSV9Wmg2XwdgdG++niOUHHpvnSnMRBTAb47myOq1iN4st kvTi4YbuH1c9bHJA8S8B6BdIqUiJYzke8ve01NXNMRjqWU82BlRJQb3qBZQAKt4rPjZV iEoA==
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:from:date :message-id:subject:to:cc; bh=i7uEtT4+puCpUqAMWjJERoEzJuCrtOcUGcqyXG5FVL0=; b=bUeu+99By7Inf6gHnMhzTIkI4tEcx0OdSLUYimIyyD8L0Khwq8yoOiDNZZwWo7rRNS P239EllNOGQxTxc+ThmrCokGToelf4kEr+JYjBwOEFczvB04KGd+Czi7KwftujgTelXR +pXJUXCsbvJSv68qJEMfESchA2T/binlUnMQVobJEcxoYM1NpAUTdbuKxmyU9bm51rnl 6kydVso/5BIikSS5ohfOfQ78ZuFYwnFg/x7IMa2ua6e+crzEXI54juXJXd1nqyPZ3tfD AMF39FK5j28qkB1NUnHZ5AK6dkD0dkTbvTqbsN5o3VgJrlGTcgEGHdpR6Q2BGYuqKI2R 3T8g==
X-Gm-Message-State: AOAM533Avp9bc3nLo7mpOSslODdTqb+49xyl0ItWDX6xmawAY+pNmRGc cZXOiRl6TWwjlqHV17wsxzWFf+FtuC2IwsJHTAU=
X-Google-Smtp-Source: ABdhPJytlYrcSLYEALfTaKWMDeI0dg96EHn61MUBv1Qh4JRHOSvBDKOiWgfOnDsmT6dz5GI3D9XKubk/pEnbs14LjjQ=
X-Received: by 2002:a05:6638:2bb:: with SMTP id d27mr9694536jaq.98.1616394784850; Sun, 21 Mar 2021 23:33:04 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmUgd8JS_r7UBP6LzvMy_KWRF1NuKU9O9bcEk8W9=6A88w@mail.gmail.com> <FB5AB481-FD33-418B-A602-9EFBFDA9680E@gmail.com>
In-Reply-To: <FB5AB481-FD33-418B-A602-9EFBFDA9680E@gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Mon, 22 Mar 2021 07:32:28 +0100
Message-ID: <CA+wi2hN0Y=kb8+6aLNqB-wuhEmryKgONzEfxDeXtGfPK0Aas_g@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, Huaimo Chen <huaimo.chen@futurewei.com>, BIER WG <bier@ietf.org>, BIER WG Chairs <bier-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f7c67705be1a3cc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/vk3-Fs6EItBQlUIfBKqZFcfyLfk>
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: Mon, 22 Mar 2021 06:33:14 -0000

AFAIS couple parties pointed out that most useful are considerations for
BIER FRR in case there is no IGP with LFA in the network and for BIER-TE
where IGP protection doesn't latch on AFAIS. which I agree with ...

-- tony

On Sun, Mar 21, 2021 at 9:20 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> I have exactly same comment.
> In the past we have witnessed complex and often quite harmful interactions
> of different protection schemes in multi-layer networking.
> Think IPFRR on top of SDH/Optical protection. Unless properly coordinated,
> race conditions and unnecessary service degradation would often be observed.
> Please spend some time on thinking how different surfaces interact and
> what would be required to make it work.
>
>
> Regards,
> Jeff
>
> On Mar 21, 2021, at 10:06, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> 
> Hi Huaimo,
> perhaps my question was not clearly stated. Let me re-phrase it and add
> more detail to the scenario.
> As understand the discussion about using IP FRR and BIER FRR concurrently
> in the same BIER domain, you are of the opinion that such a combination is
> useful while others have expressed some reservation of its practicality. Do
> I understand that part of the discussion correctly?
> If we consider multi-layer protection schemes, using IP FRR and BIER FRR
> is one of its examples, we should consider operational issues that a
> multi-layer scenario introduces. Particularly, coordination of timers that
> determine detection of the network failure and trigger the protection
> switchover. Such coordination of OAM parameters and the expected switchover
> intervals intended to avoid unnecessary loss of data packets caused by the
> excessive of protection switchover in an overlay network.
> I missed finding that being discussed in the e-mail you've pointed out.
> Perhaps you can quote the part that you believe addressed my question.
>
> Regards,
> Greg
>
> On Fri, Mar 19, 2021 at 9:47 PM Huaimo Chen <huaimo.chen@futurewei.com>
> wrote:
>
>> Hi Greg,
>>
>>     Thanks for your comments/questions.
>>     My responses to another email below should address/answer them.
>>
>> https://mailarchive.ietf.org/arch/msg/bier/VsTPRmUi-26VSWrBPzdnLXzPvT0/
>>
>>
>> Best Regards,
>> Huaimo
>> ------------------------------
>> *From:* Greg Mirsky <gregimirsky@gmail.com>
>> *Sent:* Wednesday, March 17, 2021 12:45 PM
>> *To:* Huaimo Chen <huaimo.chen@futurewei.com>
>> *Cc:* bier@ietf.org <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org
>> >
>> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>
>> Hi Huaimo,
>> it seems that you are suggesting using IP FRR and BIER FRR in the same
>> domain. Is my understanding correct? Multi-layer protection in a network
>> may work but, in my opinion, overcomplicated network management and
>> operation. Would you expect that BIER FRR is more responsive to a network
>> failure than IP FRR? What benefits could be in such a scenario? Which
>> parameters, in your opinion, need to be coordinated between IP and BIER
>> layers? I think that if the document includes the concurrent use of IP FRR
>> and BIER FRR it should provide more detail on how such a scenario could be
>> realized.
>>
>> Regards,
>> Greg
>>
>> On Tue, Mar 16, 2021 at 10:27 AM Huaimo Chen <huaimo.chen@futurewei.com>
>> wrote:
>>
>> Hi Tony,
>>
>>     Even though there is IGP running in the network and the underlay IP
>> FRR is provided, the BIER FRR seems still needed. All the BIER packets are
>> forwarded using the BIFTs. They are not forwarded using the normal FIBs
>> with IP FRR support.  When a failure happens in the network, the BIER
>> packets will still be forwarded using the old BIFTs without considering the
>> failure until the old BIFT is recomputed and updated based on the new
>> network topology after the failure. During this period (from the time of
>> the failure to the time at which the BIFTs are updated), the BIER packets
>> may be lost.
>>
>> Best Regards,
>> Huaimo
>> ------------------------------
>> *From:* Tony Przygienda <tonysietf@gmail.com>
>> *Sent:* Tuesday, March 16, 2021 12:58 PM
>> *To:* Huaimo Chen <huaimo.chen@futurewei.com>
>> *Cc:* Michael Menth <menth@uni-tuebingen.de>de>; bier@ietf.org <
>> bier@ietf.org>
>> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>
>> we need a framework here ;-)
>>
>> when IGP calculates the underlying FRR it's always a better solution.
>> Nothing is faster than IGP and anything calculated as "better FRR" or
>> "backup FRR" will not have the topology to do a better job/faster than IGP
>> can. So AFAIS the only real use case here is BIER without IGP signalling
>> but correct me if I'm wrong
>>
>> -- tony
>>
>>
>> On Tue, Mar 16, 2021 at 5:02 PM Huaimo Chen <huaimo.chen@futurewei.com>
>> wrote:
>>
>> Hi Michael,
>>
>>     Thanks much for your valuable comments.
>>     My responses are inline below with prefix [HC].
>>
>> Best Regards,
>> Huaimo
>> ------------------------------
>> *From:* BIER <bier-bounces@ietf.org> on behalf of Michael Menth <
>> menth@uni-tuebingen.de>
>> *Sent:* Tuesday, March 16, 2021 7:11 AM
>> *To:* bier@ietf.org <bier@ietf.org>
>> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>>
>> Hi Tony, all,
>>
>> Am 16.03.2021 um 11:08 schrieb Tony Przygienda:
>>
>> > 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.
>>
>> Right. The solution may make sense if the routing underlay does not
>> offer FRR capabilities.
>>
>> [HC]: When the routing underlay supports IP FRR, the BIER should also
>> provide BIER FRR since the BIER packets are forwarded using the BIFTs.
>> When failures happen in the network, the BIER packets are still forwarded
>> using the old BIFTs until the old BIFTs are updated according to the
>> updated network topology after the failures.
>>
>> >
>> > 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
>>
>> I agree. in the absence of an IGP, the "native BIER-FRR on bier layer"
>> must be set by a controller.
>>
>> [HC]: I agree too.
>>
>> So, below the line, an applicability statement would be helpful. What
>> are those cases?
>> - IGP running but without FRR on the routing underlay?
>> - No IGP and no FRR on the routing underlay?
>>
>> [HC]: When IGP is running in the network, each BFR in the network
>> calculates,
>> installs and/or updates its BIER FRR BIFTs. The BIER FRR in the draft is
>> independent of the underlay IP FRR.
>> When no IGP is running in the network, the BIER controller for the
>> network
>> calculates, installs and/or updates the BIER FRR BIFTs into BFRs in the
>> network,
>> regardless of whether the routing underlay FRR is provided.
>>
>>
>> However, if the controller takes care of BIER-FRR, what could be reasons
>> for missing FRR on the routing underlay? If there is a FRR on the
>> routing underlay (also provided through a controller), tunnel-based
>> bier-frr solves the problem in a transparent way.
>>
>> [HC]: The BIER FRR in the draft is independent of the underlay IP FRR.
>> Regardless of whether the routing underlay FRR is provided, the
>> BIER FRR BIFTs are computed in the same way.
>>
>> BTW, we studied protection variants for controller-based infrastructures
>> (for routing underlays, not for BIER). Challenge is to keep state low.
>> LFA-based solutions help a lot and outperform others. 100% protection is
>> possible with only little additions. Results are available:
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fatlas.informatik.uni-tuebingen.de%2F~menth%2Fpapers%2FMenth20-Sub-6.pdf&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=03cc%2BIvdV%2BCg%2F0PCFulWzuCa0h4I5sBqn8K5QPT5BR8%3D&amp;reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=https:%2F%2Fatlas.informatik.uni-tuebingen.de%2F~menth%2Fpapers%2FMenth20-Sub-6.pdf&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615768749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oSLGnBnwcsrY2gaRZqG%2FLSMOYLNQcG0Mjm9NNVc6TUU%3D&reserved=0>
>> (under
>> revision)
>>
>> [HC]: Thanks much for your information.
>>
>>
>> Regards,
>>
>> Michael
>>
>> >
>> > thanks
>> >
>> > -- tony
>> >
>> > On Tue, Mar 16, 2021 at 7:41 AM <zhang.zheng@zte.com.cn
>> > <mailto:zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>>> wrote:
>> >
>> >     A 2-week WG adoption call begins for the following draft:
>> >
>> >
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=797z0ndM2IahVL2y9xPoY%2BOU5x4%2F3w1FaSWfoF%2BC6pQ%3D&amp;reserved=0
>> <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%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615778703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8wxBypO3zOln7rLaSaXO446xFFfpJfOx4Lr6bKO15z4%3D&reserved=0>
>> >     <
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-bier-frr%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=797z0ndM2IahVL2y9xPoY%2BOU5x4%2F3w1FaSWfoF%2BC6pQ%3D&amp;reserved=0
>> <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%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615788657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=evcnoZLl57g4rLoio0gj2Q4XOa26a2cnX4Jt7%2B3Dogg%3D&reserved=0>
>> >
>> >
>> >     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)
>> >
>> >
>> >
>> > _______________________________________________
>> > BIER mailing list
>> > BIER@ietf.org
>> >
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=aZ6%2BjQBpo7k81fqf%2FnYdfer7mS45RlhB0lPT7%2B%2BVm6I%3D&amp;reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615788657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7kv2BUZk34Y7k9amlOAcHzacQ5ZlDqjGzb4mZWm%2FCXw%3D&reserved=0>
>> >
>>
>> --
>> Prof. Dr. habil. Michael Menth
>> University of Tuebingen
>> Faculty of Science
>> Department of Computer Science
>> Chair of Communication Networks
>> Sand 13, 72076 Tuebingen, Germany
>> phone: (+49)-7071/29-70505
>> fax: (+49)-7071/29-5220
>> mailto:menth@uni-tuebingen.de <menth@uni-tuebingen.de>
>>
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkn.inf.uni-tuebingen.de%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2gozTq4XIXnxQu2P62mtFSGOEID93679cjqQeAQOPbo%3D&amp;reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkn.inf.uni-tuebingen.de%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615798609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dwQXPxovW3YS99oeGr3%2FdrYKfMFPSR94Xz1ihTfE2l4%3D&reserved=0>
>>
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C5d3cb8163c7f4a1557e608d8e86c408f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637514898966623524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=aZ6%2BjQBpo7k81fqf%2FnYdfer7mS45RlhB0lPT7%2B%2BVm6I%3D&amp;reserved=0
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615798609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w5ocCaRoOrDQ%2BVSeW1%2Bl7MUnqp3TN6InBTmzXx00blc%3D&reserved=0>
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://www.ietf.org/mailman/listinfo/bier
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615808573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CibFkXbi9yOCwGTwn8k8tIrMoZvvZgi8DL9EGHE%2Fzys%3D&reserved=0>
>>
>> _______________________________________________
>> BIER mailing list
>> BIER@ietf.org
>> https://www.ietf.org/mailman/listinfo/bier
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbier&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C3d527e94172b4e7234fb08d8e96422e4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637515963615808573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CibFkXbi9yOCwGTwn8k8tIrMoZvvZgi8DL9EGHE%2Fzys%3D&reserved=0>
>>
>> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>