Hi, Thank you Toerless for your summary on the "core BIER/MSR6 differentiation". I feel no words other than the two you have summarized below, "Operational and Architectural."
Operational: MSR6 is for IPv6 network, and BIER for MPLS network (yes I know BIER has a Non-MPLS BIER encapsulation which is another Layer-2.5 technology parallel to MPLS, and assuming to configure "bier-non-mpls enable" instead of "mpls enable" on every link of a BIER-domain before anything goes). Architectural: BIER multicast is not IP multicast, and MSR6 is. Cheers, Jingrong 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments may 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: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Toerless Eckert Sent: Wednesday, October 26, 2022 12:24 AM To: 6...@ietf.org; m...@ietf.org; p...@ietf.org; spring@ietf.org Subject: [IPv6] Pls comment: On core BIER/MSR6 differentiation Dear colleagues I wanted to explain and get feedback on one of the IMHO core differences between MSR6 and BIER which is so far only in one draft-eckert-msr6-rbs, and we could not present solutions at IETF115, and this proposed architectural difference only got a few seconds during one of the problems slides at the MSR6 BoF, and i also don't think we have agreed on this point in the MSR6 community. So: If i understand BIER, it was designed as a single-forwarding-fits-all network layer stateless source-routing multicast solution. To make it applicable to any network protocol or other traffic, it encapsulates that trafic end-to-end (BFIR-BFER), which it calls flow-overlay. IMHO, on this aspect, BIER is very much designed like MPLS for the flow overlay and SR-MPLS for the source-routing, both of which made that concept popular and successful. Those MPLS network are also the ones where the BIER architecture most reasonate with. But we also have a well established communities in the IETF that did not pick this approach to build networks, but wanted where building contrlled networks based on IPv6. The first community to do this was of course the IoT community, where RFC6554 is the most common source-routing header. And i do not think these communities would be asked to do MPLS instead of IPv6 based designs if they would start today. Then of course there is SRv6 with the SRH source routing header RFC8754 for higher speed IPv6 networks. Those IPv6 networks too where not asked to convert to MPLS when they needed to get the benefit of source routing. Instead, we choose the much more prudent option to build a common source-routing architecture (Segment Routing) and map it to the forwarding/encapsulation paradigm that matches the customers existing network design best (MPLS and IPv6): operational and architectural. [ An aproach actually i think we should also take in stateless multicast: share everything that can be shared across BIER and MSR6, but not force one type of networks to change their overall architecture because the other network design was there earlier. I can not fathom how this is even a reasonable argument in the IETF (do not use IPv6), but thats what i heard repeatedly. ] Now enter the multicast side. The ask i heard at and after MSR6 bof is that its seemingly ok. for the IETF to ask operators of networks with multiple hundred million users who have long ago choosen IPv6 as their network architecture to not standardize in the IETF a network forwarding architecture for multicast that is aligned with their IPv6 unicast network architecture - but insted create a whole new parallel architecture (BIER). This is exactly the opposite of how the IETF has build multicast solutions for 20 years (see point 3.5 of draft-eckert-msr6-problem-statement). Instead, BIER-WG explains how to perfectly tunnel bier over IPv6 links and then IPv6 over BIER, and calls it the best fitting way to do source routing end-to-end in an IPv6 network (see point 3.5.3). This is about as fitting for an IPv6 network as it was to use IPv4 multicast in support of MVPN in MPLS networks. Which indeed the industry asked customer to do. And those of us who worked these solutions back then knew what happened (see point 3.5.1). Anyhow, i digress. In any case: MSR6 is meant to be an end-to-end (obviously stateless) source-routing solutions for multicast in any (controlled) IPv6 network. And like in the unicast solutions, this means that this does not chane the fact that it represents an appropriate end-to-end IPv6 packet. And in the case of a packet that is multicasted, we actually only have one IETF standardized model for that, which is IP multicast. BIER multicast is not IP multicast, IP multicast can just a be a flow-overlay on BIER. Whereas in MSR6 it does of course need to be a supported option even without a separate flow overlay. Whether thats for VMs in DCs ot existing IPv6 network MVPN deployments that want to get rid of tree state in their core without introducing a lot more new network architecture via BIER (and a surplus of tunneling via BIERin6). What iss required to do this is of course, that the common MSR6 extension header to support the source-routing (with replication) does also need to include the IPv6 multicast destination address, because according to RFC8200 source routing (section 4.4), the IPv6 destination address is rewritten on every hop with the next source-routing hop. This key part of the MRS6 IPv6 routing extension header is described in section 4.4 of draft-eckert-msr6-rbs and is called MSR6 exit segment - and this is what makes MSR6 eliminate the need for flow overlay encap as in BIER when its used for source-routing of IPv6 multicast. Of course this approach will also allow us to define new "multipoint" SID semantics for SRv6, when that address is a different address (including any programmability that might come in handy here). Sorry for this gotten so long, hope it is useful. Very much appreciate any feedback. Cheers Toerless -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
