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"
<t...@cs.fau.de>;
Date: Wed, Oct 26, 2022 00:24 AM
To: "6man"<6...@ietf.org>;"msr6"<m...@ietf.org>;"pim"<p...@ietf.org>;"spring"<spring@ietf.org>;
Subject: [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. 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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
