BIER Z. Zhang
Internet-Draft E. Rosen
Intended status: Standards Track Juniper Networks
Expires: April 25, 2019 L. Geng
China Mobile
October 22, 2018
Multicast/BIER As A Service
draft-zzhang-bier-multicast-as-a-service-00
Abstract
This document describes a framework for providing multicast as a
service via Bit Index Explicit Replication (BIER) [RFC7279], and
specifies a few enhancements to [draft-ietf-bier-idr-extensions]
[RFC8279] [draft-ietf-bier-ospf-bier-extensions] to enable multicast/
BIER as a service.
Requirements Language
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 RFC2119.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires April 25, 2019 [Page 1]
Internet-Draft bier-maas October 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3
1.2. A CDN of A Single Provider . . . . . . . . . . . . . . . 4
1.2.1. IGP/BGP Interworking . . . . . . . . . . . . . . . . 5
1.3. A CDN That Involves Another Providers . . . . . . . . . . 6
1.3.1. Providing Independent BAAS To Multiple Customers . . 6
1.3.2. Control and Accounting . . . . . . . . . . . . . . . 7
1.4. Sets and Segmentation . . . . . . . . . . . . . . . . . . 8
1.4.1. Multiple Sets . . . . . . . . . . . . . . . . . . . . 8
1.4.2. Segmentation . . . . . . . . . . . . . . . . . . . . 8
2. Specifications for Enhancements to BIER Signaling with
BGP/IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. BGP Procedures . . . . . . . . . . . . . . . . . . . . . 9
2.2. ISIS/OSPF Procedures . . . . . . . . . . . . . . . . . . 10
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Currently multicast is primarily used in the following scenarios:
o Enterprise Applications. For example, large scale financial data
publishing.
o Provider/underlay tunnels for MVPN and for EVPN BUM.
o Real-time IPTV offered by a service provider to its customers.
Besides the above, large scale multicast services, especially transit
multicast transport provided by large Internet Service Providers is
Zhang, et al. Expires April 25, 2019 [Page 2]
Internet-Draft bier-maas October 2018
virtually non-existent. This is mainly because of the following
chicken and egg dilemma:
o Traditional multicast technologies are complicated and lack
scalability. The revenue that multicast services bring in cannot
offset the Capex and Opex that an operator has to invest, so
provider networks typically do not enable multicast even though
the deployed equipment does support multicast.
o As a result, Content Providers cannot take advantage of multicast
and instead use less efficient methods like Ingress Replication,
Peer2Peer, or multicast at application layer.
A recent multicast technology breakthrough, BIER, provides a simple
and scalable solution for large scale multicast deployment,
independent of number of multicast flows. In the meantime, large
scale distribution of ultra high definition video content has become
more and more popular and important. Service providers simply cannot
keep on increasing their network capacity even if they could shift
cost to Content Providers. With these developments, service
providers now have both the need and means to provide scalable
multicast service, potentially across multiple providers.
This document describes a framework for Multicast As A Service (MAAS)
enabled by BIER. We use Content Delivery Network (CDN) as example,
though it applies to any large scale multicast delivery service.
1.1. Terminologies
Readers are assumed to be familiar with multicast, BIER, BGP and
ISIS/OSPF concepts and procedures. Some terminologies are listed
here for convenience.
o BFR: BIER Forwarding Router.
o BFIR: BIER Forwarding Ingress Router.
o BFER: BIER Forwarding Egress Router.
o EBFR: Edge BFR. Including BFIR and BFER.
o BSL: BitStrengLength. Number of bits in the BitString of a BIER
header.
Zhang, et al. Expires April 25, 2019 [Page 3]
Internet-Draft bier-maas October 2018
1.2. A CDN of A Single Provider
To make it easier to understand, we first consider a simple example:
a CDN owned by a single operator, which could be a Content Provider
itself. The network spans multiple ASes as shown in the following
figure:
++++ ++++
EBFR11+ +EBFR12 EBFR21+ + EBFR22
+ + + +
+ + + +
+ AS100 + + AS200 +
+ + + +
+ + + +
+ ASBR132 +++++++++ ASBR231+ +EBFR23
EBFR13 + \ + + / ++++
+ + ASBR312 ASBR321
+++ ASBR131 + +
\ + AS300 +
ASBR311 (BFR) +
ASBR341 ASBR351 (BFR)
/ + + \
++++ / ++++++++++++ \ +++++*
EBFR43 ASBR431 ASBR531 EBFR53
+ + + +
+ AS400 + + AS500 +
+ + + +
EBFR41 EBFR42 EBFR51 EBFR52
+ + + +
++++++ +++++++
The CDN uses BIER for multicast transport and Edge BIER Forwarding
Routers (EBFRs) are located throughout the network. Some of them are
connected towards multicast content sources and are referred to as
BIER Forwarding Ingress Routers (BFIRs) in BIER architecture. Most
of them are connected towards multicast content receivers and are
referred to as BIER Forwarding Egress Routers (BFERs). Notice that
between content sources and BFIRs there may be Protocol Independent
Multicast (PIM) in use, while between content receivers and BFERs
there may be PIM and/or IGMP in use.
At the initial deployment stage, there might be only a few transit
BIER Forwarding Routers (BFRs) at strategic points in the network
(e.g. ASBR311 and ASBR351). BGP sessions are established among the
EBFRs and BFRs, and BGP extensions as defined in
Zhang, et al. Expires April 25, 2019 [Page 4]
Internet-Draft bier-maas October 2018
[I-D.ietf-bier-idr-extensions] are used to signal BIER information.
All these are in a single BIER sub-domain.
In the example of initial stage with only ASBR311 and ASBR351 as
BFRs, multicast traffic arriving at EBFR11 will be imposed with a
BIER header and replicated to EBFR12/EBFR13/ASBR311 over tunnels.
ASBR311 will further replicate traffic to
ASBR351/EBFR41/EBFR42/EBFR43/EBFR21/EBFR22/EBFR23 over tunnels, and
ASBR351 will further replicate traffic to EBFR51/EBFR52/EBFR53 over
tunnels.
The BGP signaling and a necessary enhancement can be explained using
the following example. EBFR43 advertises its BIER prefix (a loopback
address) as /32 IPv4 or /128 IPv6 prefix in BGP with a BIER Path
Attribute (BPA) [RFC8279] [I-D.ietf-bier-idr-extensions]. ASBR431
receives it and re-advertises it (with BGP Next Hop changed to
itself) but does not do anything wrt BIER because it does not support
BIER. Same happens on ASBR341. When ASBR311 and ASBR351 receive it
from ASBR341, they create a BIFT entry corresponding to EBFR43's BFR-
ID. The entry causes a BIER packet with corresponding bit set in its
BitString to be tunneled to EBFR43. This cannot be based on BGP Next
Hop in the advertisement because the BGP Next Hop is ASBR341. When
eventually EBFR11 receives the re-advertised route, it creates a BIFT
entry that causes corresponding packets to be tunneled to ASBR311
(but not to EBFR43 directly). Now it is clear that this cannot be
based on either the BIER prefix itself or the BGP Next Hop. The
solution is that the originating EBFR attaches a Tunnel Encap
Attribute [I-D.ietf-idr-tunnel-encaps] with the tunnel destination
set to itself, and whenever a BFR re-advertises the route it changes
the tunnel destination to itself. When a BFR creates the BIFT entry,
it uses the tunnels destination in the Tunnel Encapsulation Attribute
to find out where to tunnel packets.
Over time, more routers in network may be upgraded to support BIER
and become a BFR. For example, once ASBR431 is upgraded to a BFR,
ASBR311 no longer needs to tunnel traffic to EBFR41/EBFR42/EBFR43 but
only need to tunnel one copy to ASBR431, who will then replicate to
EBFR41/EBFR42/EBFR43.
1.2.1. IGP/BGP Interworking
Additionally, if enough routers in an AS (or just one of its IGP
area) can be upgraded to run BIER, then hop-by-hop BIER forwarding
can be utilized there, using IGP extensions for BIER signaling
[RFC8401] [I-D.ietf-bier-ospf-bier-extensions].
Notice that even with this there is still only one BIER sub-domain,
with mixed IGP and BGP signaling for BIER. To redistribute BIER
Zhang, et al. Expires April 25, 2019 [Page 5]
Internet-Draft bier-maas October 2018
information between IGP and BGP, procedures specified in
[I-D.zwzw-bier-prefix-redistribute] and detailed in Section 2.2 are
followed.
1.3. A CDN That Involves Another Providers
In the above example, the CDN is providing multicast transport
service, with simplicity and scalability provided by BIER (the per-
flow state is confined to the edges). Going one step further and
consider that AS300 belong to a different Internet Service Provider.
Now the ISP is providing BIER As A Service (BAAS) to the CDN, by
being part of the CDN's BIER sub-domain. Notice that, no only does
the ISP not have per-tree state (it does not have EBFRs), but also
its BFRs do not need BFR-ID assigned. The ISP does need to learn
about all the EBFRs and their corresponding BFR-IDs (through
signaling).
1.3.1. Providing Independent BAAS To Multiple Customers
Now consider that the ISP also provides BAAS for another CDN. Each
of the two CDNs has its own BIER domain, with their own BFR-ID or
even sub-domain ID assignment that could conflict. For example, both
have BFR-ID 100 and sub-domain ID 0 assigned but they are totally
independent of each other. For an BFR in the ISP to support this,
with BGP signaling it needs to advertise its own BFR prefix multiple
times, each time with a different RD that is mapped to the
corresponding CDN. A new SAFI BIER (to be allocated by IANA) is
used.
In the above example, there are two paths between AS100 and AS300.
It is possible that while ASBR311 is the BFR, ASBR312 is the unicast
best path into AS300 and beyond from AS100. Advertising BIER
prefixes using a different SAFI with a RD also has the side benefit
of allowing incongruent topologies for unicast and BIER.
In the existing BIER architecture and IGP extensions for BIER a sub-
domain is tied to a single topology (either the one and only topology
if Multi-topology ISIS/OSPF is not used, or a topology as defined in
Multi-topology ISIS/OSPF). In the BIER sub-TLV that ISIS/OSPF
attaches to a BIER prefix, a Sub-domain-ID value can only appear once
for a particular topology. In this document, a BFR in the BAAS
provider may belong to different and independent BIER domains, and
the same sub-domain ID needs to be signaled multiple times, once for
each BIER domain (notice that the same sub-domain-ID actually
identifies different sub-domains in different BIER domains, so this
does not really change the architectural requirement that a sub-
domain is tied to a single topology). To do so, a new "BIER Domain"
sub-TLV is introduced, and its value field includes a RD (as in the
Zhang, et al. Expires April 25, 2019 [Page 6]
Internet-Draft bier-maas October 2018
BGP signaling) and a BIER sub-sub-TLV that is the same as currently
specified in ISIS/OSPF extensions for BIER.
This works very well because of the flexible BIER architecture - a
BIER packet is forwarded based on a Bit Index Forwarding Table (BIFT)
that is determined by a 20-bit BIFT ID in front of the BIER header,
and each (subdomain, BSL, set) tuple has its own BIFT.
Traditionally, a subdomain is identified by a sub-domain ID but in
this document a subdomain is now identified by a (RD, sub-domain ID)
tuple in the control plane.
With this, the scaling aspect on a BFR comes to how many BAAS
customer the provider needs to support. For example, if it needs to
support 16 BAAS customers, one BSL, and four sets Section 1.4.1 for
each customer, then the provider needs to support 64 BIFTs (16 x 1 x
4). If the BSL is 256, then each BIFT has 256 entries in it and the
total number of BIFT entries (routes) is 4k (256 x 64). Notice that
this 4k number is not related to the number of customers' multicast
flows, but only related to the number of customers and number of
customer EBFRs. The number of customers with their own independent
BIER domains are likely not very large initially, but if multicast as
a service gets more widely used. the protocol and procedures defined
in this document can scale up to the extent of how many BIFTs (and
BIFT entries) a BFR can support (notice that there is no real
difference between a BIFT entry and a unicast RIB/FIB entry).
1.3.2. Control and Accounting
With BGP based signaling, internal routers of a BAAS provider does
not need explicit configuration for the BIER transport services that
it support. In the above example, the ASBRs (ASBR311, ASBR312,
ASBR321, ASBR341, ASBR351) in AS300 only need to have BGP policy
configured to allow certain received BIER prefix advertisements to
trigger necessary BIER state and additional signaling of their own.
For example, when ASBR351 receives the BIER prefix advertisement, if
its local configuration allows it may create corresponding BIFTs and
BIFT entries, and additionally originates or updates its own BIER
prefix advertisement. An internal BFR inside AS300, upon receiving
the BGP advertisements, may or may not need to go through the same
policy check again (based on the providers operation model).
When the ASBRs (re-)advertise BIER prefixes toward their external
peers, they could enable statistics counters for the corresponding
BIER labels so that they can count incoming BIER packets from
external peers specifically for this BAAS. Similarly, the ASBRs can
enable statistics counters for BIER labels they receive from external
peers, so that they can count outgoing BIER packets delivered to the
Zhang, et al. Expires April 25, 2019 [Page 7]
Internet-Draft bier-maas October 2018
external peers. These incoming and outgoing counters can be used for
accounting and billing purposes.
1.4. Sets and Segmentation
The number of EBFRs could very well be larger than the BSL. There
are two ways to handle that - multiple sets or segmentation.
1.4.1. Multiple Sets
With this method the set of EBFRs are grouped into multiple sets, and
the number of EBFRs in a set is smaller than the BSL. A BFIR may
need to send multiple copies of a multicast packet to reach all
BFERs, one copy for each set that covers one or more expecting BFERs.
A separate BIFT is needed for each set (because the same bit in the
BitString of packets for different sets maps to different BFERs).
This not only leads to multiple copies to be sent over the same link,
but also requires additional BIFTs. In the earlier example, 64 BIFTs
are needed for 16 BAAS customers because each customer needs 4 BIFTs
for the multiple sets.
1.4.2. Segmentation
With this method, a BIER network is segmented into multiple regions,
each with its own BIER sub-domain. In the earlier example, each AS
could be an independent sub-domain. A BIER packet from EBFR11 will
be decapsulated by the segmentation border router ASBR311, and then
sent into next sub-domain in AS300 with a new BIER header. The
segmentation [RFC7524] involves Multicast Flow Overlay [RFC8279]
[I-D.ietf-bier-mvpn] so that the segmentation border routers know
what BitString to use when sending onto the next segment. The
advantage of segmentation is that only a single copy needs to be
sent, and the number of BIFTs is also reduced on all BFRs. The
disadvantage is that the segmentation points need to run multicast
flow overlay protocol and maintain related state in control plane and
data plane.
A deployment may start without the need for either multiple sets or
segmentation when the number of EBFRs is small. When the number of
EBFRs grows, segmentation can be introduced incrementally. A new BFR
can be added as, or an existing BFR could be converted to, a
segmentation point, splitting the original sub-domain into two
independent sub-domains. The segmentation point does not re-
advertise BIER information from one sub-domain to another. Other
BFRs/EBFRs do not need any configuration changes except to make sure
that all BIER information exchange is restricted to a single sub-
domain (for example, two BFRs were BGP peers before and were
exchanging BIER information but now they belong to two sub-domains
Zhang, et al. Expires April 25, 2019 [Page 8]
Internet-Draft bier-maas October 2018
and only exchange BIER information with the segmentation point and
other BFRs in the same sub-domain).
In the earlier example of a CDN of a single provider, using
segmentation may be acceptable, even though the overlay state needs
to be kept by the segmentation points. A BAAS provider may need to
carefully consider if it wants to keep a customer's overlay state on
those segmentation points. On the other hand, the provider may
consider hosting per-customer segmentation points. For example,
tethering small or virtual BFRs to an ASBR and have those BFRs be the
segmentation points [I-D.zzhang-bier-tether].
2. Specifications for Enhancements to BIER Signaling with BGP/IGP
2.1. BGP Procedures
When an EBFR advertises a BIER prefix with a BIER Path Attribute
(BPA), it SHOULD attach a Tunnel Encap Attribute (TEA) with the
tunnel destination set to itself.
A BFR receiving the advertisement MUST use the tunnel destination in
the TEA to determine where to forward a BIER packet whose BitString
has a set bit corresponding to the BIER prefix, unless the TEA does
not exist, in which case the BIER prefix itself is used for the
determination. When the BFR re-advertises the BIER prefixes, it MUST
change the tunnel destination in the TEA to itself, or add a TEA with
the tunnel destination set to itself if there was no TEA in the
received advertisement.
The TEA SHOULD have a Protocol Sub-TLV with protocol type BIER
(0xAB37).
A transit BFR that is allowed (by provisioning or based on policy) to
participate in a BIER sub-domain MUST advertise its own BIER prefix
with a BPA. The BFR-id in the BPA SHOULD be 0. Depending on the
operational model of the operator, the advertisement MAY be based on
received BIER prefixes (subject to certain BGP policy verification),
or MAY do so only with explicit configuration.
If a provider provides independent BAAS services to multiple
customers, when its BFR receives BIER prefixes from a customer it
MUST re-advetise with a new BIER SAFI. For simplicity, all BFRs of
the provider use the same RD that is specifically assigned for the
customer. When a BFR re-advertises BIER prefixes to a customer, it
MUST re-advertise with SAFI 1 or 2.
If multiple providers together provide BAAS to a customer, then the
two providers may assign the same RD for the customer or do RD
Zhang, et al. Expires April 25, 2019 [Page 9]
Internet-Draft bier-maas October 2018
rewriting when re-advertising BIER prefixes from one provider to
another.
2.2. ISIS/OSPF Procedures
This document defines a new BIER Domain Sub-TLV of ISIS TLVs 135,
235, 236, and 237. The sub-TLV type is to be allocated.
This document also defines a new BIER Domain Sub-TLV of OSPF Extended
Prefix TLV. The sub-TLV type is to be allocated.
The value part of the BIER Domain Sub-TLV includes a 64-bit Route
Distinguisher followed by one or more BIER Info Sub-TLV (as defined
in [RFC8401] and [I-D.ietf-bier-ospf-bier-extensions] respectively)
as its sub-sub-TLVs .
When a BFR redistribute a BIER prefix from BGP into ISIS/OSPF, if the
BGP advertisement is of BIER SAFI, a BIER Domain sub-TLV is attached,
with the RD part of the sub-TLV copied from the BGP advertisement.
For each BIER TLV in the BPA, a BIER Info sub-sub-TLV is added in the
BIER Domain sub-TLV, with the subdomain-id and BFR-id copied from the
corresponding BIER TLV in the BPA, and the Encapsulation sub-sub-sub-
TLV omitted because it is not needed.
If the BGP advertisement is of SAFI 1 or 2, BIER Info Sub-TLVs are
constructed as above directly, without using a BIER Domain sub-TLV.
When a BFR redistribute a BIER prefix from ISIS/OSPF into BGP, if
there is a BIER Domain sub-TLV in the corresponding ISIS LSP or OSPF
LSA, the BGP advertisement is of BIER SAFI and the RD part of the
NLRI is set to the RD from the BIER Domain sub-TLV. For each BIER
Info sub-sub-TLV in the BIER Domain sub-TLV, a BIER TLV is included
in the BPA, with the subdomain-id and BFR-id copied from the
corresponding BIER Info sub-sub-TLV. The MPLS Encapsulation sub-TLV
is omitted. The tunnel destination in the TEA is set to the BFR's
BIER prefix.
If there is no BIER Domain sub-TLV in the corresponding ISIS LSP or
OSPF LSA for the BIER Prefix, the BGP advertisement is of SAFI 1 or
2, and the BPA is constructed similar to the above (the only
difference is that in this case BIER Info sub-TLVs are not part of a
BIER Domain sub-TLV).
3. IANA Considerations
This document requests the following IANA assignments:
Zhang, et al. Expires April 25, 2019 [Page 10]
Internet-Draft bier-maas October 2018
o A sub-TLV type for BIER Domain Sub-TLV from ISIS "Sub-TLVs for
TLVs 135, 235, 236, and 237" registry.
o A sub-TLV type for BIER Domain Sub-TLV from OSPFv2 Extended Prefix
Sub-TLV registry.
o A BIER SAFI from Subsequent Address Family Identifiers (SAFI)
registry.
4. Security Considerations
To be provided.
5. Acknowledgements
The authors thank Lenny Giuliano and Antoni Przygenda for their
review and suggestions.
6. References
6.1. Normative References
[I-D.ietf-bier-idr-extensions]
Xu, X., Chen, M., Patel, K., Wijnands, I., and T.
Przygienda, "BGP Extensions for BIER", draft-ietf-bier-
idr-extensions-05 (work in progress), March 2018.
[I-D.ietf-bier-mvpn]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", draft-ietf-bier-
mvpn-11 (work in progress), March 2018.
[I-D.ietf-bier-ospf-bier-extensions]
Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2
Extensions for BIER", draft-ietf-bier-ospf-bier-
extensions-18 (work in progress), June 2018.
[I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-10
(work in progress), August 2018.
[I-D.zwzw-bier-prefix-redistribute]
Zhang, Z., Bo, W., Zhang, Z., and I. Wijnands, "BIER
Prefix Redistribute", draft-zwzw-bier-prefix-
redistribute-01 (work in progress), September 2018.
Zhang, et al. Expires April 25, 2019 [Page 11]
Internet-Draft bier-maas October 2018
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
Zhang, "Bit Index Explicit Replication (BIER) Support via
IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
<https://www.rfc-editor.org/info/rfc8401>.
6.2. Informative References
[I-D.zzhang-bier-tether]
Zhang, Z., Warnke, N., and I. Wijnands, "Tethering A BIER
Router To A BIER-incapable Router", draft-zzhang-bier-
tether-00 (work in progress), October 2018.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
EMail: zzhang@juniper.net
Eric Rosen
Juniper Networks
EMail: erosen@juniper.net
Liang Geng
China Mobile
EMail: gengliang@chinamobile.com
Zhang, et al. Expires April 25, 2019 [Page 12]