Re: [spring] Pls comment: On core BIER/MSR6 differentiation

[Wei Wang <[e-mail]>]

Hi Toerless,


    I have revised your draft (draft-eckert-msr6-problem-statement) and I think it hits our point. As SRv6 is being deployed on a large scale in our network, we prefer a SRv6/native IPv6-based multicast solution, which bring less changes to our network architecture and existing technologies in the network. 
    Your draft very accurately describes the reason why we prefer the SRv6/IPv6-based solution (even lists more factors that we have not considered). Thanks for your proposal!
    We also think it is necessary to use IPv6 multicast destination address to distinguish the traffic of different VPN customers, so we proposed a draft (https://datatracker.ietf.org/doc/draft-wang-spring-multicast-vpn-segment/) to define a new segment, which contains the information of VPN customer(RD, multicast group information) and can be used to perform customer-level traffic statistics, detection and other operations. Since we have similar views, we hope to receive your comments and suggestions for our draft, Thanks!

 
Best Regards,
Wei
------------------ Original ------------------
From:                                                                                                                        "Toerless Eckert"                                                                                    <[e-mail]&gt;;
Date:&nbsp;Wed, Oct 26, 2022 00:24 AM
To:&nbsp;"6man"<[e-mail]&gt;;"msr6"<[e-mail]&gt;;"pim"<[e-mail]&gt;;"spring"<[e-mail]&gt;;

Subject:&nbsp;[spring] 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.&nbsp; 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
&nbsp; &nbsp; Toerless

_______________________________________________
spring mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spring