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

Hi Michael

Please see zzh> below.

-----Original Message-----
From: Michael Menth <menth@uni-tuebingen.de>
Sent: Monday, March 22, 2021 9:41 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Tony Przygienda <tonysietf@gmail.com>; Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>; BIER WG <bier@ietf.org>; Huaimo Chen <huaimo.chen@futurewei.com>; 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 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.

Zzh> Depending on implementation, the above can be done transparent to BIER.

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.

Zzh> If you're talking about tunneling to the failed BFR neighbor's children (on the SPF tree), that needs backup paths and I consider that as part of the scenario #2.

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

Zzh> That is what I mean by "uses FRR mechanisms (but does not follow exact unicast paths - i.e. unicast and BIER are using incongruent topology or algorithm)", compared to "uses the unicast FRR state".

- 100% failure coverage is not possible

Zzh> This is not BIER specific. It's just like unicast case.

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

zzh> This is not BIER specific. It's just like unicast case.

possibly redundant packets.

Zzh> I think this ok (not that a BFER is going to get duplicates). The key is that BIER-FRR based on alternative/backup paths provides link/node protection by using the same unicast FRR mechanism.
Zzh> Jeffrey

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>; Jeff Tantsura <jefftant.ietf@gmail.com>
> Cc: Greg Mirsky <gregimirsky@gmail.com>; BIER WG <bier@ietf.org>; Huaimo Chen <huaimo.chen@futurewei.com>; 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
https://urldefense.com/v3/__http://kn.inf.uni-tuebingen.de__;!!NEt6yMaO-gk!Wj1e9px9Ce8Xcz9rcHmfXeU8TVvbU8Lw3zyD4PcERboj1UQ2wJWv15ZrZm1PWGuf$

Juniper Business Use Only