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

Greg Mirsky <gregimirsky@gmail.com> Mon, 22 March 2021 15:13 UTC

Return-Path: <gregimirsky@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 E4F233A043A; Mon, 22 Mar 2021 08:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 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, 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 JCVHnay3UCzC; Mon, 22 Mar 2021 08:13:46 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 1FC123A03FB; Mon, 22 Mar 2021 08:13:29 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id u4so21498447ljo.6; Mon, 22 Mar 2021 08:13:29 -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=lazNNKhZVFI7uirQXs7cL3Lha7v97rEqTO8GUed/9Q4=; b=di91R7jNgkYPpvbUH67iXJm6gU2XgpSqhXNoIE9lF/02llNRM/XyuRYHbBThfnTR+l FLZF5Yj2LcY49jwqexTOLVkyaBNYK7K8fnBUOQOKiurDSN5B7rlj1RZ5t+vxw4CGnrpa qdI3Wco/W4HwwlGMNKOj6pvWG00JEsJZQ9i6xMhIm7OQCLp6bIp+B7enI3IKq/RiXwxH Gkz1qXKuPLB/XhaUYyxv8PPWuYZYlCzbelMThw8jzcKOI4udMeD39+fh/E1vo4mRv3n3 Kty0xmJ4x90LiU7ECN4CvnBlVg2TPRCdgr+tOFv2SlPob79Kenfw+ItRP/DOv23h0Dy7 3I3A==
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=lazNNKhZVFI7uirQXs7cL3Lha7v97rEqTO8GUed/9Q4=; b=nxbuiZtdU/72bu/O268xdAUF/cf4fWv41Pg4xO4oNzjaIXuVYZ8xDPwMMQTp0s6J8b 51ImAj7O+NL4nZpUbC3V1NtCC7L08xXOT7SBdbUzWYyDlFgB1GO+mkxZXDwxjH6dAJRM +pT/F0XijbDimKZuSueL1gxREJWXdhdkhqOPq6xS3R64ddA8V5ssY9A/PtSeVC3C69JY eSDZ+sovgkUcvGKTsEbpxGyeCQ6mxkXZYu28gYUi3O2cQN8HbjxzAMOv3zyJEM/m3iuV cV+FT8/zznZXvp8rlb4rj6ThhPvsaqWM3W7xNUrPU7htl92EVveaElCgHUvQwqODnXUN jywA==
X-Gm-Message-State: AOAM530U8aIakElQNNg82eEsOGbyiM3Z0qJ0rR87XHO5qdfizbSUrvgI yQskVqCVbe328P72b4LFb+4tuXsDjdZ62HqJMAs=
X-Google-Smtp-Source: ABdhPJyXaH/j3gWg0z+QzPLTYk5/2nMluAndN/XahM3oUU6WPzcYTdmqCUMT7452Frbmy30w9oWKNlBGyjr+q9bT+pM=
X-Received: by 2002:a2e:9151:: with SMTP id q17mr56692ljg.107.1616426001977; Mon, 22 Mar 2021 08:13:21 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmUgd8JS_r7UBP6LzvMy_KWRF1NuKU9O9bcEk8W9=6A88w@mail.gmail.com> <FB5AB481-FD33-418B-A602-9EFBFDA9680E@gmail.com> <CA+wi2hN0Y=kb8+6aLNqB-wuhEmryKgONzEfxDeXtGfPK0Aas_g@mail.gmail.com> <1e5153db-8eb1-0329-38bd-a71bd7456ad4@uni-tuebingen.de> <MN2PR05MB5981A45D668A35E71D2DC397D4659@MN2PR05MB5981.namprd05.prod.outlook.com> <8910b8db-1ba1-0959-3391-2b0ffbc5aef5@uni-tuebingen.de>
In-Reply-To: <8910b8db-1ba1-0959-3391-2b0ffbc5aef5@uni-tuebingen.de>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 22 Mar 2021 08:13:10 -0700
Message-ID: <CA+RyBmW6hzmcpowrE0-e6n7_yVc6x3Si5x8k8fwchFtECjbtiw@mail.gmail.com>
To: Michael Menth <menth@uni-tuebingen.de>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Tony Przygienda <tonysietf@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, BIER WG <bier@ietf.org>, Huaimo Chen <huaimo.chen@futurewei.com>, BIER WG Chairs <bier-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a7533a05be2181ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/kbZnVd4MRMJtwFxwkX3yjmfaQbQ>
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 15:13:51 -0000

Hi Michael,
I have a question to what you see BIER-specific in detecting a failure in
the network for the local protection:

We still need some BIER-FRR in this case:
1) Recognize the failure

I think that the ability of OAM to exercise the specific path in the end
nodes is limited and might not be generally expected. As noted in RFC 5880
for BFD:

   ... a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves ...

I think that detecting BIER failure between BIER neighbors is no different
from detecting the failure between these nodes in the underlay network.

Regards,
Greg

On Mon, Mar 22, 2021 at 6:40 AM Michael Menth <menth@uni-tuebingen.de>
wrote:

> Hi Jeffrey, all,
>
> Am 22.03.2021 um 14:21 schrieb Jeffrey (Zhaohui) Zhang:
> > Whether it is IP FRR, MPLS FRR, or BIER FRR, the key is that
> alternative/backup paths are pre-installed. Upon the detection of failure,
> the PLR uses alternative/backup path before global repair finishes.
> >
> > The determination of alternative/backup path can be SPF based (e.g. LFA)
> which involves IGP, or controller based, or any other way (e.g. static
> configuration or pre-signaling in case of MPLS). That is not BIER specific.
> >
> > Specifically for BIER FRR, when we say "BIER can take advantage of
> unicast FRR", there are two scenarios/aspects about that:
> >
> > 1. BIER does not do any FRR by itself at all (i.e. no primary/backup
> branches for BIFT entries), but rely on unicast FRR to each BFR neighbor.
>
> We still need some BIER-FRR in this case:
> 1) Recognize the failure
> 2) Reroute the packet over the underlay (encapsulation in underlay) as
> the direct link no longer works. However, it not sending to another
> neighbor.
>
> This only provide link protection not node protection (for the BFR
> neighbor), though.
>
> There is also node protection with tunnel-based BIER-FRR that leverages
> the protection of the underlay.
>
> > 2. BIER does have its own FRR constructs (i.e., ECMP/primary/backup
> branches for BIFT entries), but these are still determined based on
> "unicast" FRR, because we're using the alternative/backup paths to the
> BFERs. This is not "simply using unicast FRR" - because we do need to
> create BIER specific forwarding state for those alternative/backup paths
> (BIER label, F-BM, etc.). It either uses the unicast FRR state (when BIER
> does follow exact unicast paths) or uses unicast FRR mechanisms (but does
> not follow exact unicast paths - i.e. unicast and BIER are using
> incongruent topology or algorithm) - whether it is IGP based or not. This
> does provide node protection as well as link protection.
>
> Here some caveats
> - If the BIER topology does not contain all the nodes of the underlay,
> LFAs on the BIER layer may be different.
> - 100% failure coverage is not possible
> - If rLFAs/TI-LFA are needed to complete failure coverage on the BIER
> layer, we've got tunneling again with all its disadvantages, e.g.,
> possibly redundant packets.
>
> Best wishes,
>
> Michael
>
> >
> > Jeffrey
> >
> > -----Original Message-----
> > From: BIER <bier-bounces@ietf.org> On Behalf Of Michael Menth
> > Sent: Monday, March 22, 2021 2:39 AM
> > To: Tony Przygienda <tonysietf@gmail.com>om>; Jeff Tantsura <
> jefftant.ietf@gmail.com>
> > Cc: Greg Mirsky <gregimirsky@gmail.com>om>; BIER WG <bier@ietf.org>rg>;
> Huaimo Chen <huaimo.chen@futurewei.com>om>; 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]
> >
> >
> > BIER-FRR is also needed if a BFR-NBR is down. Here, the IGP cannot help.
> >
> > BR, Michael
> >
> > Am 22.03.2021 um 07:32 schrieb Tony Przygienda:
> >> 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
> >> <mailto: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
> >>>     <mailto: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 <mailto:huaimo.chen@futurewei.com>>
> wrote:
> >>>
> >>>         Hi Greg,
> >>>
> >>>             Thanks for your comments/questions.
> >>>             My responses to another email below should address/answer
> >>>         them.
> >>>
> >>>
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bier/VsTPRmUi-26VSWrBPzdnLXzPvT0/__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD2kESs5M$
> >>>         <
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bier/VsTPRmUi-26VSWrBPzdnLXzPvT0/__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD2kESs5M$
> >
> >>>
> >>>
> >>>         Best Regards,
> >>>         Huaimo
> >>>
>  ------------------------------------------------------------------------
> >>>         *From:* Greg Mirsky <gregimirsky@gmail.com
> >>>         <mailto:gregimirsky@gmail.com>>
> >>>         *Sent:* Wednesday, March 17, 2021 12:45 PM
> >>>         *To:* Huaimo Chen <huaimo.chen@futurewei.com
> >>>         <mailto:huaimo.chen@futurewei.com>>
> >>>         *Cc:* bier@ietf.org <mailto:bier@ietf.org> <bier@ietf.org
> >>>         <mailto:bier@ietf.org>>; BIER WG Chairs <bier-chairs@ietf.org
> >>>         <mailto: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 <mailto: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
> >>>             <mailto:tonysietf@gmail.com>>
> >>>             *Sent:* Tuesday, March 16, 2021 12:58 PM
> >>>             *To:* Huaimo Chen <huaimo.chen@futurewei.com
> >>>             <mailto:huaimo.chen@futurewei.com>>
> >>>             *Cc:* Michael Menth <menth@uni-tuebingen.de
> >>>             <mailto:menth@uni-tuebingen.de>>; bier@ietf.org
> >>>             <mailto:bier@ietf.org> <bier@ietf.org <mailto:
> 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
> >>>             <mailto: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
> >>>                 <mailto:bier-bounces@ietf.org>> on behalf of Michael
> >>>                 Menth <menth@uni-tuebingen.de
> >>>                 <mailto:menth@uni-tuebingen.de>>
> >>>                 *Sent:* Tuesday, March 16, 2021 7:11 AM
> >>>                 *To:* bier@ietf.org <mailto:bier@ietf.org>
> >>>                 <bier@ietf.org <mailto: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://urldefense.com/v3/__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__;JSUlfiUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD5dsMDr-$
> >>>                 <
> https://urldefense.com/v3/__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__;JSUlfiUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD0qZVOwV$
> >
> >>>                 (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>
> >>>                 > <mailto:zhang.zheng@zte.com.cn
> >>>                 <mailto:zhang.zheng@zte.com.cn>>> wrote:
> >>>                 >
> >>>                 >     A 2-week WG adoption call begins for the
> following draft:
> >>>                 >
> >>>                 >
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD4kCzIbt$
> >>>                 <
> 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*7C3d527e94172b4e7234fb08d8e96422e4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515963615778703*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=8wxBypO3zOln7rLaSaXO446xFFfpJfOx4Lr6bKO15z4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-2jc53f$
> >
> >>>                 >     <
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD4kCzIbt$
> >>>                 <
> 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*7C3d527e94172b4e7234fb08d8e96422e4*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637515963615788657*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=evcnoZLl57g4rLoio0gj2Q4XOa26a2cnX4Jt7*2B3Dogg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVDy4GOze3$
> >>
> >>>                 >
> >>>                 >     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 <mailto:BIER@ietf.org>
> >>>                 >
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD6mgG2AP$
> >>>                 <
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD3ncbA_Y$
> >
> >>>                 >
> >>>
> >>>                 --
> >>>                 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
> >>>                 <mailto:menth@uni-tuebingen.de>
> >>>
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-zyaVuE$
> >>>                 <
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD1u5f6WA$
> >
> >>>
> >>>                 _______________________________________________
> >>>                 BIER mailing list
> >>>                 BIER@ietf.org <mailto:BIER@ietf.org>
> >>>
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD6mgG2AP$
> >>>                 <
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD5IrBvov$
> >
> >>>                 _______________________________________________
> >>>                 BIER mailing list
> >>>                 BIER@ietf.org <mailto:BIER@ietf.org>
> >>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-s1zfRz$
> >>>                 <
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD3LYsVdN$
> >
> >>>
> >>>             _______________________________________________
> >>>             BIER mailing list
> >>>             BIER@ietf.org <mailto:BIER@ietf.org>
> >>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-s1zfRz$
> >>>             <
> https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD3LYsVdN$
> >
> >>>
> >>>     _______________________________________________
> >>>     BIER mailing list
> >>>     BIER@ietf.org <mailto:BIER@ietf.org>
> >>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-s1zfRz$
> >>>     <
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-s1zfRz$
> >
> >>
> >>
> >> _______________________________________________
> >> BIER mailing list
> >> BIER@ietf.org
> >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-s1zfRz$
> >>
> >
> > --
> > 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
> >
> https://urldefense.com/v3/__http://kn.inf.uni-tuebingen.de__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD8ejpIeg$
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!TaBu9R1NIxg6A2oUJwvqyklynKAhxVhSWyMJeXlLJF3k1QaTOWKRs_GVD-s1zfRz$
> >
> > Juniper Business Use Only
> >
>
> --
> 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
> http://kn.inf.uni-tuebingen.de
>