Inter-Domain Multicast Deployment
using BIERv6China MobileBeijing 10053gengliang@chinamobile.comHuawei Technologiesxiejingrong@huawei.comFutureweimmcbride7@gmail.comHuawei Technologiesyangang@huawei.comBit Index Explicit Replication IPv6 encapsulation (BIERv6) introduces
an approach to use IPv6 extension header to carry BIER header with IPv6
unicast address as destination address. It provides the ability to
replicate a packet from one router to another router in a different
domain as well as in the same domain. This document introduces the
techniques for multicast deployment across multiple domains using
BIERv6, and demonstrate how BIERv6 is beneficial for such
deployment.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
and .Bit Index Explicit Replication [RFC8296] IPv6 encapsulation (BIERv6)
described in introduces
an approach to use IPv6 extension header to carry BIER header. One
BIERv6 option, using IPv6 unicast address as destination address
provides the ability to replicate a packet from one router to another
router in a different domain as well as in the same domain. This
document introduces the techniques for multicast deployment across
multiple domains using BIERv6, and demonstrates how BIERv6 is beneficial
for such deployment.Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative
References.It is common to deploy multicast services across multiple
domains.One typical scenario for this type of deployment is in a service-
provider network for MVPN service as described in . Service provider network
tends to be very heterogeneous with full-mesh backbone network, and
metro networks with fabric for dense area coverage or ring-shaped for
sparse area coverage. The backbone network and metro networks are
autonomous systems interconnected by border routers (BRs).
Multicast-based delivery of video need to be set up from a source router
on the backbone to each of the boundary routers of each metro
network.This scenario may have some variant. For example, multicast source
router is a Top of Rack (TOR) switch in a service provider data
center(SPDC) connected to backbone with data center gateway(s) (DC-GW),
and multicast receiver is the home broadband subscribers connected to
boundary routers (e.g. BNG) of each metro network. Operators may want to
set up multicast-based delivery from TOR to BNGs seamlessly without
segmentation or stitching on DC-GW(s) or BR(s).It is described as hierachical multicast in this document.Another typical scenario for inter-domain multicast deployment is in
peering network as described in to set up
multicast-based delivery of content across inter-domain peering
points.This scenario may have some variant. For example, interconnected
content delivery networks (CDNs) (described in )
owned by Network Service Providers (NSPs) or Enterprise Service
Providers may need to deliver multicast from one to others.It is described as peering multicast in this document.Following is an example of hierarchical deployment of
multicast.Multicast source is connected to PE1x, and multicast receivers are
connected to PE2x and PE3x.PE1x, PE2x, PE3x is located in Backbone (AS 64001), Metro 2 (AS
64002), and Metro 3 (AS 64003) respectively, and BR1, BR2, BR3 is
boarder of these three domains. They belong to a single administrative
domain.IGP underlay for BIERv6 is deployed in Metro2, Metro3 respectively.
The bfr-ids in Metro2 and Metro 3 should be divided rationally.PE1x, PE2x, PE3x uses 2001::E1, 2001::E2, 2001::E3 as IPv6
BFR-prefix (and End.BIER function) respectively.BR1, BR2, BR3 uses 2001::B1, 2001::B2, 2001::B3 as IPv6 BFR-prefix
(and End.BIER function) respectively.All of them use the Non-MPLS static BSL-SD-SI BIFT encoding method
described in as
the auto-generation method.On BR1, static configuration can be used to construct inter-domain
BIERv6 forwarding table.Accordingly, the following BIFTs will be constructed:On PE1x, static configuration can be used to construct inter-domain
BIERv6 forwarding table.Accordingly, the following BIFTs will be constructed:Use of BGP as inter-domain underlay protocol to advertise the BIER
information from BR2 or BR2 to BR1, or from BR1 to PE1x is outside the
scope of this document.On each domain, two redundant border routers may be deployed, and
anycase IPv6 address can be used on each pair of BRs as
BFR-prefix.Inter-Domain BIER will converge normally when unicast converge and
the BIFT will be reconstructed accordingly.For multicast overlay layer, there are no extensions needed. MVPN
is deployed on PE1x, PE2x and PE3x using sub-domain 6 and bsl 256
without segmentation on border router(s).Note: Use of the IPv6 address configured on PE1 to identify an MVPN
instance can eliminate the need for BFR-id configuration on PE1x,
which otherwise has to be configured from the space of a
sub-domain.Following is an example of peering deployment of multicast.Each Administrative Domain AD-1, AD-2 or AD-3 is configured a
unique color. Color 1, 2, 3 are used in this example.For routing underlay layer, the ingress router uses IGP protocol
(IS-IS as example in this document) for the domain it belongs to, and
uses static configuration for the domain it doesn't belong to.Below is an example of routing underlay configuration on PE1x:The following lists the BIFT that will be constructed on PE1x:Ref1: BIFT constructed using IGP.Ref2: BIFT constructed using static configuration, with BR2 a
multi-hop BFR neighbor of PE1x.Ref3: BIFT constructed using static configuration, with BR2 a
multi-hop BFR neighbor of PE1x.Ref3: BIFT constructed using static configuration, with BR3 a
multi-hop BFR neighbor of PE1x.For multicast overlay layer, the color extended community defined
in [RFC5512] is carried in Leaf A-D route together with the PTA
attribute.(1) PE in each domain gets the color it belongs to. This can be
done by configuration on each PE in each domain.(2) PE carries a color attribute in BGP-MVPN Leaf A-D route when
advertising to Ingress PE as response to explicit-tracking initiated
by the Ingress PE. This can be done by configuration on MVPN
deployment. Refer to for other
attributes needed to be used.(3) The Ingress PE gets the Leaf A-D route, learns the BFERs of a
color (representing a domain) interested in a multicast flow, and
constructs the overlay forwarding table. Below is an example of the
overlay forwarding table on PE1x:Ref1: packet will be replicated according to the
BitString<0001> and the BIFT constructed using the IGP for
SD<6>/BSL<256>/SI<0> for color 1.Ref2: packet will be replicated according to the
BitString<0001> and the BIFT constructed using the static-bift
configuration for SD<6>/BSL<256>/SI<0> for color
2.Ref3: packet will be replicated according to the
BitString<0001> and the BIFT constructed using the static-bift
configuration for SD<6>/BSL<256>/SI<1> for color
2.Ref3: packet will be replicated according to the
BitString<0001> and the BIFT constructed using the static-bift
configuration for SD<6>/BSL<256>/SI<1> for color
3.Note: BFR-id configuration on PE1x is only necessary when PE1x will
act as BFER, for example, there is multicast packet from PE2x to PE1x.
The BFR-ids in color 1, 2, 3 is independent on each other.The procedures of this document do not, in themselves, provide
privacy, integrity, or authentication for the control plane or the data
plane.No IANA Allocation is required in this document.TBD.