Subject: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation

From: [email-masked]
Date: Wed, 9 Feb 2022 20:18:44 +0100

Dear BIER-TE WG:

Robin did add a section (6.3) describing an initial performance gain analysis
of CGM2/RBS to the github source (https://github.com/toerless/bier-cgm2-rbs), and
i just did a bit of editorial fixup and posted it as -01 of the draft. 

This actually is the first time i actually like the HTML'ized version of a
draft, because the topology picture is so large it doesn't fit a single page:

https://www.ietf.org/archive/id/draft-eckert-bier-cgm2-rbs-01.html

The interesting piece about the comparison is that it is actually comparing
CGM2/RBS to BIER, and not BIER-TE. Because BIER itself should be requiring less
copies than BIER-TE, so the gain of CGM2/RBS over BIER-TE should be even higher,
but the fact alone that you get away with fewer packet copies to large
receiver sets even though the bitstring also needs to encode the path/tree
towards the receivers is really cool.

Robin, two Q:

1. The new text mentions "in our graphs", but the text does not include any such graphs (yet).
I guess such a graph would be even worse to convert to ASCII than the topology.
Maybe post whatever format you have those results in to github (PDF, png...) 
and then we actually may want to see if/how a PDF version of the draft could include
better than just ASCII art. Certainly a good reason to finally try it out.
And short term we can just add references to such visuals to the draft.

2; Is it correct to assume that the hops through the topology that you simulated
are "just" shortest-path, maybe with some ECMP choice - aka: the same paths that
also BIER would choose given some "default" IGP routing setup ?

Cheers
    Toerless

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 9 Feb 2022 20:49:26 +0000

Hi Toerless,

Not sure if my understanding is correct, but it seems that RBS does not reduce the number of bits that are needed to encode the tree. Rather, it increases the number of bits (to encode the recursive structure).
I agree that it reduces the size of BIFTs, but even current BIER-TE can reduce the number of copies if you use a longer bitstring?

Jeffrey

Juniper Business Use Only

-----Original Message-----
From: BIER <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, February 9, 2022 2:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation

[External Email. Be cautious of content]

Dear BIER-TE WG:

Robin did add a section (6.3) describing an initial performance gain analysis of CGM2/RBS to the github source (https://urldefense.com/v3/__https://github.com/toerless/bier-cgm2-rbs__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQZyfK9En$ ), and i just did a bit of editorial fixup and posted it as -01 of the draft.

This actually is the first time i actually like the HTML'ized version of a draft, because the topology picture is so large it doesn't fit a single page:

https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-eckert-bier-cgm2-rbs-01.html__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQaBIgBPC$

The interesting piece about the comparison is that it is actually comparing CGM2/RBS to BIER, and not BIER-TE. Because BIER itself should be requiring less copies than BIER-TE, so the gain of CGM2/RBS over BIER-TE should be even higher, but the fact alone that you get away with fewer packet copies to large receiver sets even though the bitstring also needs to encode the path/tree towards the receivers is really cool.

Robin, two Q:

1. The new text mentions "in our graphs", but the text does not include any such graphs (yet).
I guess such a graph would be even worse to convert to ASCII than the topology.
Maybe post whatever format you have those results in to github (PDF, png...) and then we actually may want to see if/how a PDF version of the draft could include better than just ASCII art. Certainly a good reason to finally try it out.
And short term we can just add references to such visuals to the draft.

2; Is it correct to assume that the hops through the topology that you simulated are "just" shortest-path, maybe with some ECMP choice - aka: the same paths that also BIER would choose given some "default" IGP routing setup ?

Cheers
    Toerless

_______________________________________________
BIER mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQZXGUd9P$

---

From: <[email-masked]>
Date: Thu, 10 Feb 2022 09:16:28 +0800 (CST)

Hi Toerless, 
Haven't read the new version of CGM2/RBS, just have the same question with Jeffrey. 
If I understand BIER-TE and CGM2/RBS solutions right, the forwarding tables of the two methods are only focus on the local links. 
So the table's scale for the two solutions is almost same. 
The commen issue of the two solution is the BSL limitation. 
BIER-TE solution has an exclusive issue that the BP needs to be assigned globally. 
But in CGM2/RBS solution, the BP needs not to be assigned globally. 
So the main difference of the two solutions is: is it necessary to assign the BP globally, right?
Best regards,
Sandy

------------------原始邮件------------------
发件人：Jeffrey(Zhaohui)Zhang
收件人：[email-masked];[email-masked];
抄送人：[email-masked];
日 期 ：2022年02月10日 04:50
主 题 ：Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation
Hi Toerless,
Not sure if my understanding is correct, but it seems that RBS does not reduce the number of bits that are needed to encode the tree. Rather, it increases the number of bits (to encode the recursive structure).
I agree that it reduces the size of BIFTs, but even current BIER-TE can reduce the number of copies if you use a longer bitstring?
Jeffrey
Juniper Business Use Only
-----Original Message-----
From: BIER <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, February 9, 2022 2:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation
https://www.ietf.org/mailman/listinfo/bier

---

From: "Xubing (Robin)" <[email-masked]>
Date: Thu, 10 Feb 2022 09:05:48 +0000

Dear Toerless,

>And short term we can just add references to such visuals to the draft.

Xubing: The graph has been uploaded to github with PNG type. It is hard to convert it to ASCII art. (https://github.com/toerless/bier-cgm2-rbs)

>2; Is it correct to assume that the hops through the topology that you simulated are "just" shortest-path, maybe with some ECMP choice - aka: the same paths that also BIER would choose given some "d…

Xubing: Actually, the path of CGM2 is determined by the controller/algorithm, not depend on IGP or BGP protocol. And in the multiple paths scenario, CGM2 can choose the path hop-by-hop, and the shortest-path is 'just' one of the choices..

Best Regards

Bing Xu
Network Laboratory, 2012Labs, Huawei Technologies Co.,Ltd.
Tel : +86 13811353690 / Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Thursday, February 10, 2022 3:19 AM
To: [email-masked]
Cc: Xubing (Robin) <[email-masked]>
Subject: BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation

Dear BIER-TE WG:

Robin did add a section (6.3) describing an initial performance gain analysis of CGM2/RBS to the github source (https://github.com/toerless/bier-cgm2-rbs), and i just did a bit of editorial fixup and posted it as -01 of the draft.

Robin, two Q:

Cheers
    Toerless

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Feb 2022 17:39:33 +0100

Jeff,

It is indeed initially somewhat counterintuitive to think that the CGM2/RBS 
bitstring encoding could be more efficient (less copies) than BIER - given how BIER
does not even need to encode the tree but just the leaves. Whereas CGM2/RBS does
encode the tree.

The reason becomes IMHO more obvious, when one considers that BIER needs to send a
separate packet copy even if just ONE BFER in the bitstring needs a copy. If we have
a BSL of 256 bits, it means we encoded 255 "dead-weight" bits. And if we want to
replicate a packet to N% out of a large number of BFER one can imagine how we 
get to the points where where the bitstring of every packet copy will have only a
few bits set.

With the compressed tree model, the length of each bitstring of interest is just
the total number of direct adjacencies (BFER or BFR), so the efficiency of each
such bitstring is never as low as 1/256, but maybe just 1/20 - if the BFR has
20 neighbors (other BFR or BFER). So within a max of 256 bits of "variable length
encoded tree", there is maybe better than 10% of bits to which a copy is made.

Meaning: I wouldn't want to bet a large amount of money on how exactly 
the comparison would play out when we increase the BSL size for both BIER and
CGM2/RBS (as you suggested), because then the efficiency of a BSL=512 bitstring
in BIER could be as low as 1/512 if only one bit is set there. Whereas the
percentace "replication efficiency per bit of addressing" in CGM2/RBS would probably
stay the same.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 10 Feb 2022 17:51:11 +0100

> So the table's scale for the two solutions is almost same. 

Jeffrey wasn't asking about BIER-TE (i think).

> So the main difference of the two solutions is: is it necessary to assign the BP globally, right?

That is one core difference, yes. And it eliminates IMHO all the scaling
challenges we have with BIER-TE (that we try to compensate for to some degree with
controller based bit optimizations). But as discussed in the answer to Jeffs message,
the fact that the encoding in CGM2/RBS is a tree means that we also eliminate
the BIER/BIER-TE issue that a bitstring can carry a lot of unnecessary (zero) bits
and need to make multiple copies just because some BFER or adjacencies have their
bits in different SI (in larger topologies).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 10 Feb 2022 20:29:11 +0000

Hi Toerless,

I was indeed comparing RBS with BIER-TE, where both encode the tree.

Here is my understanding:

- To reach N BFERs, you'll need at N bits for sure; to encode K replication points, you need K bits for sure. This does not change with RBS - that's what I meant in the previous email.
- I do realize that RBS has this advantage: If a packet does not need to go through some replication points that some other packets need to, then this packet does not need all the bits that BIER-TE would need to allocate (but not necessarily set in bitstring). All bits have local significance.

So, depending on how granular the TE path needs to be, RBS indeed could be very efficient. Is that correct?

Jeffrey

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Thursday, February 10, 2022 11:40 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation

Jeff,

It is indeed initially somewhat counterintuitive to think that the CGM2/RBS bitstring encoding could be more efficient (less copies) than BIER - given how BIER does not even need to encode the tree but just the leaves. Whereas CGM2/RBS does encode the tree.

The reason becomes IMHO more obvious, when one considers that BIER needs to send a separate packet copy even if just ONE BFER in the bitstring needs a copy. If we have a BSL of 256 bits, it means we encoded 255 "dead-weight" bits. And if we want to replicate a packet to N% out of a large number of BFER one can imagine how we get to the points where where the bitstring of every packet copy will have only a few bits set.

With the compressed tree model, the length of each bitstring of interest is just the total number of direct adjacencies (BFER or BFR), so the efficiency of each such bitstring is never as low as 1/256, but maybe just 1/20 - if the BFR has
20 neighbors (other BFR or BFER). So within a max of 256 bits of "variable length encoded tree", there is maybe better than 10% of bits to which a copy is made.

Meaning: I wouldn't want to bet a large amount of money on how exactly the comparison would play out when we increase the BSL size for both BIER and CGM2/RBS (as you suggested), because then the efficiency of a BSL=512 bitstring in BIER could be as low as 1/512 if only one bit is set there. Whereas the percentace "replication efficiency per bit of addressing" in CGM2/RBS would probably stay the same.

Cheers
    Toerless

On Wed, Feb 09, 2022 at 08:49:26PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ecke
> rt-bier-cgm2-rbs-01.html__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP
> 00KEiAWpH592AuDXmrOOJH_bgVzQaBIgBPC$
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_b
> gVzQZXGUd9P$

--
---
[email-masked]

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 14 Feb 2022 15:54:12 +0800

I think another benefit of the CGM2/RBS is the flexible/independent
assignment of BP for each adjacency on the BFR/BFER in large network. 
But the drawback is that it can't coexist with the existing BIER forwarding
behavior.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of
[email-masked]
Sent: Friday, February 11, 2022 12:40 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance
analysis simulation

Jeff,

It is indeed initially somewhat counterintuitive to think that the CGM2/RBS
bitstring encoding could be more efficient (less copies) than BIER - given
how BIER does not even need to encode the tree but just the leaves. Whereas
CGM2/RBS does encode the tree.

The reason becomes IMHO more obvious, when one considers that BIER needs to
send a separate packet copy even if just ONE BFER in the bitstring needs a
copy. If we have a BSL of 256 bits, it means we encoded 255 "dead-weight"
bits. And if we want to replicate a packet to N% out of a large number of
BFER one can imagine how we get to the points where where the bitstring of
every packet copy will have only a few bits set.

With the compressed tree model, the length of each bitstring of interest is
just the total number of direct adjacencies (BFER or BFR), so the efficiency
of each such bitstring is never as low as 1/256, but maybe just 1/20 - if
the BFR has
20 neighbors (other BFR or BFER). So within a max of 256 bits of "variable
length encoded tree", there is maybe better than 10% of bits to which a copy
is made.

Meaning: I wouldn't want to bet a large amount of money on how exactly the
comparison would play out when we increase the BSL size for both BIER and
CGM2/RBS (as you suggested), because then the efficiency of a BSL=512
bitstring in BIER could be as low as 1/512 if only one bit is set there.
Whereas the percentace "replication efficiency per bit of addressing" in
CGM2/RBS would probably stay the same.

Cheers
    Toerless

On Wed, Feb 09, 2022 at 08:49:26PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> Hi Toerless,
> 
> Not sure if my understanding is correct, but it seems that RBS does not
reduce the number of bits that are needed to encode the tree. Rather, it
increases the number of bits (to encode the recursive structure).
> I agree that it reduces the size of BIFTs, but even current BIER-TE can
reduce the number of copies if you use a longer bitstring?
> Robin did add a section (6.3) describing an initial performance gain
analysis of CGM2/RBS to the github source
(https://urldefense.com/v3/__https://github.com/toerless/bier-cgm2-rbs__;!!N
Et6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQZyfK9En$
), and i just did a bit of editorial fixup and posted it as -01 of the
draft.
> This actually is the first time i actually like the HTML'ized version of a
draft, because the topology picture is so large it doesn't fit a single
page:
> The interesting piece about the comparison is that it is actually
comparing CGM2/RBS to BIER, and not BIER-TE. Because BIER itself should be
requiring less copies than BIER-TE, so the gain of CGM2/RBS over BIER-TE
should be even higher, but the fact alone that you get away with fewer
packet copies to large receiver sets even though the bitstring also needs to
encode the path/tree towards the receivers is really cool.
> Maybe post whatever format you have those results in to github (PDF,
png...) and then we actually may want to see if/how a PDF version of the
draft could include better than just ASCII art. Certainly a good reason to
finally try it out.
> 2; Is it correct to assume that the hops through the topology that you
simulated are "just" shortest-path, maybe with some ECMP choice - aka: the
same paths that also BIER would choose given some "default" IGP routing
setup ?

--
---
[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 14 Feb 2022 15:50:39 +0100

> I was indeed comparing RBS with BIER-TE, where both encode the tree.

;-) Sorry that i didn't read that from your email.

> So, depending on how granular the TE path needs to be, RBS indeed could be very efficient. Is that correct?

Yes. But the efficiency does not only come from not having to have in the bitstring
bits you don't need as you said. That is just one side of the coin.

IMHO the mayor savings come from actually being able to have all the bits you do
want to have (up to the max structured bitstring length supported by HW), and not
being forced to figure out during network configuration:

a) how to split up bitstring space into SI (BIER, BIER-TE), 
b) how to optimize bits (use advanced bits, leacve out "unneded" bits) (BIER-TE).

That's what my thought example was about: What if you want to replicate to N (small)
BFER (whether BIER or BIER-TE), and each bit is in a different SI ?

Of course, if the bitstring would become too large to fit all desired bits into
one packet, you still need to send multiple packets, and there is an interesting
optimization calculation to be done:

  Given a tree described by a set of replication nodes and leaves:
  Determine a minimum number N of sub-trees such that:
  1) Each sub-tree includes a disjoint subset of leave.
  2) The sum of leaves of the sub-trees is the set of leaves of the tree.
  3) The encoded bitstring of each sub-tree fits some max-bitstring limit
  4) The sum of duplicate edges across sub-trees is minimal
     (if an edge occurs N times, it is counted N-1 times as a duplicate edge).

I think this type of "efficiency" metric applies to all of BIER,BIER-TE,CGM2/RBS

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 14 Feb 2022 16:08:32 +0100

> assignment of BP for each adjacency on the BFR/BFER in large network. 

Yes, i think thats a restatement of what my second point to Jeffrey was.

> But the drawback is that it can't coexist with the existing BIER forwarding behavior.

Hmm...

- CGM2/RBS could use the existing RFC8296 header, we'd just have
  unused bitstring bits up to the next valid bitstring size of RFC8296
  (64/128/256/...4096). If we optimize the algorithm to break a large
  tree into multiple packets, we should be able to minimize this unused
  bit overhead. But of course, only legacy concerns stop us from also
  defining a newer header and let the market slowly move to that.

- The CGM2/RBS forwarding behavior is really just the most simple
  bit behavior of BIER-TE plus the additional coding to extract the
  bitstring from the header and then for every copy to rewrite the bitstring
  (see pseudocode).  But of course, those two new operations have to be checked
   vs. available vendor NPU coding abilities.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: <[email-masked]>
Date: Tue, 15 Feb 2022 09:59:40 +0800 (CST)

Hi Toerless, 
Thank you very much for your response! 
I have one more question, let we consider CGM2/RBS solution only. 
Since all the bits have local significance in CGM2/RBS,  what if we want to send one flow to multiple BFERs but we don't want to indicate any path?
In this case we can't reach the BFERs because we don't put any path bits in the BitString and there is no global BIFT in the intermediate nodes, right?
Best regards,
Sandy

------------------原始邮件------------------
发件人：ToerlessEckert
收件人：张征00007940;
抄送人：[email-masked];[email-masked];zzhang=[email-masked];
日 期 ：2022年02月11日 00:51
主 题 ：Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation
--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 15 Feb 2022 14:41:33 +0100

> In this case we can't reach the BFERs because we don't put any path bits in the BitString and there is no global BIFT in the intermediate nodes, right?

Right. This is how we've introduced CGM2/RBS and it makes it very simple and IMHO elegant.
And seemingly from the first simulations also quite competitive versus the "flat bitstring" BIER/TE
approach in terms of replications required with same address size. More simulations would be great.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Xubing (Robin)" <[email-masked]>
Date: Wed, 16 Feb 2022 02:46:51 +0000

>And seemingly from the first simulations also quite competitive versus the "flat bitstring" BIER/TE approach in terms of replications required with same address size. More simulations would be great.

Let me introduce some detail about the simulation as follow:

We divide the overall topology into 160 domains, each of which includes 180 egress points, providing the total of 28000 egress points.

We randomly select egress points as group members, with the total number ranging from 10 to 28800. And total samples is 60.

In order to compare the encoding mechanism more fairly, we limit the size of the bitString to 256 bits (the typical size of BIER ) in both BIER and CGM2.

Conclusion:

  1.  BIER reaches its 160 packet replication limit at about 500 users, while CGM2 encoding reaching its limit of 125 replications at about 12000 users.
  2.  The decreasing of replications above12000 users about CGM2 is caused by the use of node-local broadcast as a further optimization.
  3.  CGM2 can completely break the 256-bit encapsulation limit, which cannot be easily broken by BIER, thus allowing the source to send fewer multicast streams.
  4.  CGM2 encoding performs is significantly better than BIER in sparse scenario.

Sincerely,

Bing Xu

-----Original Message-----
From: Toerless Eckert <[email-masked]>
Sent: Tuesday, February 15, 2022 9:42 PM
To: [email-masked]
Cc: [email-masked]; Xubing (Robin) <[email-masked]>; zzhang=[email-masked]
Subject: Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance analysis simulation

And seemingly from the first simulations also quite competitive versus the "flat bitstring" BIER/TE approach in terms of replications required with same address size. More simulations would be great.

Cheers

    Toerless

> 抄送人：[email-masked];[email-masked];zzhang=[email-masked]<mailto:[email-masked];[email-masked];zzhang=[email-masked]>

> rg;

> 主 题 ：Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance

> analysis simulation On Thu, Feb 10, 2022 at 09:16:28AM +0800, [email-masked]<mailto:[email-masked]> wrote:

> That is one core difference, yes. And it eliminates IMHO all the

> scaling challenges we have with BIER-TE (that we try to compensate for

> to some degree with controller based bit optimizations). But as

> discussed in the answer to Jeffs message, the fact that the encoding

> in CGM2/RBS is a tree means that we also eliminate the BIER/BIER-TE

> issue that a bitstring can carry a lot of unnecessary (zero) bits and

> need to make multiple copies just because some BFER or adjacencies have their bits in different SI (in larger topologies).

> > 收件人：[email-masked];[email-masked]<mailto:[email-masked];[email-masked]>;

> > 抄送人：[email-masked]<mailto:[email-masked]>;

> > 主 题 ：Re: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance

> > analysis simulation Hi Toerless, Not sure if my understanding is

> > correct, but it seems that RBS does not reduce the number of bits that are needed to encode the tree. Rather, it increases the number of bits (to encode the recursive structure).

> > From: BIER <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>

> > To: [email-masked]<mailto:[email-masked]>

> > Cc: [email-masked]<mailto:[email-masked]>

> > Subject: [Bier] BIER: draft-eckert-bier-cgm2-rbs-01 with performance

> > analysis simulation [External Email. Be cautious of content] Dear

> > BIER-TE WG:

> > Robin did add a section (6.3) describing an initial performance gain analysis of CGM2/RBS to the github source (https://urldefense.com/v3/__https://github.com/toerless/bier-cgm2-rbs__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQZyfK9En$<https://urldefense.com/v3/__https:/github.com/toerless/bier-cgm2-rbs__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOOJH_bgVzQZyfK9En$> ), and i just did a bit of editorial fixup and posted it as -01 of the draft.

> > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ec<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ec>

> > kert-bier-cgm2-rbs-01.html__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQ

> > ARYP00KEiAWpH592AuDXmrOOJH_bgVzQaBIgBPC$

> > [email-masked]<mailto:[email-masked]>

> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bi<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bi>

> > er__;!!NEt6yMaO-gk!WS49OT72vlonSWP3yLtLcW_RQARYP00KEiAWpH592AuDXmrOO

> > JH_bgVzQZXGUd9P$ _______________________________________________

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

--

---

[email-masked]<mailto:[email-masked]>