Re: [MBONED] [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

Hi Jeffery,

I think this is an interesting topic which is related to one of the core motivation for proposing MSR6.

Please find some comments inline.

Best

Xuesong

> -----Original Message-----

> From: Msr6 [mailto:msr6-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui)

> Zhang

> Sent: Sunday, October 30, 2022 12:31 AM

> To: Dino Farinacci <farinacci@gmail.com>; Michael McBride

> <michael.mcbride@futurewei.com>

> Cc: Xiejingrong (Jingrong) <xiejingrong=40huawei.com@dmarc.ietf.org>;

> Toerless Eckert <tte@cs.fau.de>; BIER WG <bier@ietf.org>; msr6@ietf.org;

> mboned@ietf.org; pim@ietf.org

> Subject: Re: [Msr6] [MBONED] MSR6 BOF 3rd Issue Category: More details are

> requested about the large scale use cases, including issue 8-11

>

> Please see zzh> below.

>

>

> Juniper Business Use Only

>

> -----Original Message-----

> From: Dino Farinacci <farinacci@gmail.com>

> Sent: Friday, October 28, 2022 2:27 PM

> To: Michael McBride <michael.mcbride@futurewei.com>

> Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Xiejingrong (Jingrong)

> <xiejingrong=40huawei.com@dmarc.ietf.org>; Toerless Eckert

> <tte@cs.fau.de>; BIER WG <bier@ietf.org>; msr6@ietf.org; mboned@ietf.org;

> pim@ietf.org

> Subject: Re: [MBONED] [Msr6] MSR6 BOF 3rd Issue Category: More details are

> requested about the large scale use cases, including issue 8-11

>

> [External Email. Be cautious of content]

>

>

> >> It sounds like a compromise could be to use the bitfield concept introduced

> by BIER and put those in an IPv6 packet. But the bits describe the oif-list like

> BIER does and not the receiver hosts. Then you bring the scale down to "the

> number of interfaces that lead to the edges of this domain".

> >

> > Bingo. You just described msr6.

>

> Zzh> These are the proposals that I have seen about MSR6 (stateless since it is

> source routing):

> Zzh> 1) Encode replication branches as SIDs in SRH.

> Zzh> 2) Encode replication branches as bits (BIER-TE and CGM2).

> Zzh> 3) Encode edge routers (who have downstream receivers) as bits (BIER).

> Zzh> 2) and 3) are BIER related. In an IPv6 network, the question is where to

> put the BIER header.

[Xuesong] From the view of hardware process and encoding approach in the data plane, I think the following the classification may help to understand why we think the existing BIER charter/architecture/encapsulation can't cover the work of MSR6:

<TYPE 1> Global Bitstring/Flat Bitstring defined BIER WG (BIER & BIER-TE)

The bitposition is distributed for each egress or adjacency in the BIER sub-domain and the meaning is globally valid, which determines that:

1)       The bistring as a whole will be used as the key when looking up BIFT

2)       The requested number of bitposition depends on the number of egress nodes/adjacencies in the domain

This is an efficient stateless multicast solution when the the network scale is relatively small and the multicast tree is dense.

<TYPE 2> Multicast Source Routing with or without bitstring (MSR)

MSR6 TE methods propose to encode the multicast tree in the packet. Take RBS/CGM2 as an example, which uses bitstring as the basic unit of multicast tree encoding

The bitposition is distributed by each node contained in the multicast tree and the meaning is locally valid, which determines that:

1)       Only the bitstring for the existing node is parsed. So the key of looking up FIB(different from BIFT) is part of the bitstring.

2)       There will be other field requested in the encoding unit besides bitstring, for example "length", to represent a recursive sub-tree.

3)       The requested number of bitposition depends on the number of output port along the multicast tree.

This is an efficient stateless multicast solution when the the network scale is large and the multicast tree is relatively small.

The other MSR6 TE methods are similar.

> Zzh> One option is that IPv6 is nothing special. Multicast traffic, be it

> IPv4/IPv6/Ethernet/whatever, is treated as BIER payload, and BIER header

> comes after a L2 header or tunnel header, whether the tunnel is MPLS, IPv6 or

> whatever. This is referred to as BIERin6 (BIER in IPv6 network - though it is

> more accurate to say "Generic, IPv6-agnostic BIER used for IPv6 network").

> Zzh> The other option is that BIER header is put into an IPv6 extension header

> (referred to as BIERv6) - tightly tied to SRv6 (especially when it comes to using

> BIER to transport overlay/service traffic).

[Xuesong] As I have mentioned. Even RBS/CGM2 uses bitstring, it can't be supported by the existing BIER architecture or encapsulation defined in RFC8279 and RFC8296. The hardware process and encoding approach are quite different.

So I think the existing BIER MPLS/BIERin6 or BIER Ethernet can't support this.

>

> msr6 appears to want to track receivers. And if someone comments "that is

> one mode but not all modes", then my response is "having too many solution

> options is an architectural bug".

>

> Zzh> So there is this cleanly-layered BIERin6 mode that is not IPv6 specific and

> works well for IPv6. Another mode that is intimately tied to IPv6/SRv6.

> Zzh> Jeffrey

>

> Zzh>

>

> ;-)

>

> Dino

>

> --

> Msr6 mailing list

> Msr6@ietf.org

> https://www.ietf.org/mailman/listinfo/msr6