Network Working Group Z. Li
Internet-Draft Huawei Technologies
Intended status: Informational G. Mishra
Expires: January 13, 2022 Verizon Inc.
Z. Qin
China Unicom
July 12, 2021
Gap Analysis of IPv6 Multicast Source Routing (MSR6)
draft-li-spring-ipv6-msr-gap-analysis-00
Abstract
This document analyses the gaps of the existing IPv6 multicast
solutions under discussion in IETF based on the requirements.
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 RFC 2119 [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 January 13, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Li, et al. Expires January 13, 2022 [Page 1]
Internet-Draft Gap Analysis of MSR6 July 2021
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
2. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. BIERin6 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. BIERv6 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Historical Review . . . . . . . . . . . . . . . . . . . . 5
3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Multicast could provide efficient P2MP service without bandwidth
waste. The increasing amount of live video traffic in the network
bring new requirements for multicast solutions. The existing
multicast solutions request multicast tree-building on control plane
and maintaining end-to-end tree state per flow, which impacts router
state capacity and network convergence time. There has been a lot of
work in IETF to simplify service deployment, in which Source Routing
is a very important technology, including SRv6, BIER, etc. Source
routing is able to reduce the state of intermediate nodes and
indicate multicast forwarding in the ingress nodes, which could
simplify multicast deployment. Source routing requires sufficient
flexibility on the forwarding plane and IPv6 has the advantage with
good scalability. Therefore, it is important to simplify multicast
deployment and meet high quality service requirements with IPv6
Source Routing based multicast.
Based on the design consideration defined in
[I-D.cheng-spring-ipv6-msr-design-consideration], this document
analyses the gaps of the existing IPv6 multicast solutions under
discussion in IETF. The definition of the new IPv6 multicast source
routing solution is out of the scope of this document.
Li, et al. Expires January 13, 2022 [Page 2]
Internet-Draft Gap Analysis of MSR6 July 2021
2. Gap Analysis
2.1. BIERin6
ipThe solution described in [I-D.zhang-bier-bierin6] is called
BIERin6. The encapsulation of BIERin6 is as follows:
+---------------+------------------+----------------------+
| IPv6 header | BIER Header | X type of |
| | defined in | C-multicast packet |
| Ethertype= | RFC8296 | |
| 0xAB37 | Protocol = X | (IPv4/IPv6/Ethernet) |
+---------------+------------------+----------------------+
| | | |
|<-IPv6 header->|<--BIER Header--->|<--BIERin6 Payload---->|
BIERin6 proposes to encapsulate the IPv6 header before the BIER
header in order to transit the BIER header through IPv6 nodes by
adding IPv6 header between BIER forwarding nodes. The "next header"
codepoint of the IPv6 header is set to the value that means that "the
next header is non-MPLS BIER".
BIERin6 implements P2MP forwarding follows the BIER architecture
defined in [RFC8279].
There are some issues to be considered with the classic Layered
architecture of BIER used by BIERin6 in supporting IPv6 Multicast
Source Routing:
1. Support non-native IPv6 scenarios : In BIERin6, IPv6 is only used
as the transport tunnel to transit the IPv4 domain. In fact this
method can also be used in the IPv4 to traverse the IPv4 domain.
Moreover the service layer above the transport tunnel can be non-
IPv6. For example, in BIERin6 MVPN could use MPLS label for VPN
identification. Unlike BIERin6, IPv6 Multicast Source Routing is
supposed to be a native IPv6 solution.
2. Architecture Considerations:
1) When the BIER layer is treated as an independent layer to support
features mentioned in section 2, the new encapsulation for fragment,
security, network slicing, DetNet, IOAM has to be defined in the BIER
layer. Moreover, this will also cause redundancy and conflicts when
BIER is used with IPv6 layer or MPLS layer since the encapsulations
for these functionalities are also defined for the IPv6 layer and
MPLS layer;
Li, et al. Expires January 13, 2022 [Page 3]
Internet-Draft Gap Analysis of MSR6 July 2021
2) When the BIER encapsulation is treated as a separate layer and the
rest of the functionalities are realized in the IPv6 layer, it also
causes problems. For example, if encryption is supported in the IPv6
data plane, it makes the contents of the BIER layer encrypted and
unprocessable; if IOAM and RH are supported in the IPv6 data plane
which cause the more overhead, it would make it difficult to get
information on the BIER layer and has much effect on the forwarding
performance. In addition, if IOAM is engaged, this leads to
information loss when IPv6 encapsulation is switched in the middle
nodes and cannot be implemented end-to-end.
3. BIERin6 is hard to complete end-to-end service to support host
initiating source routing. If BIERin6 is used in the host, the
source address information can be lost in the middle nodes.
Moreover, the BIER layer as an independent network layer above IPv6,
just as TCP or UDP, will cause conflictions with the transport layer,
and have more impact on the Internet architecture.
4. Maintenance of tunnel state: BIERin6 needs to maintain the state
of the tunnel in the middle nodes when traversing IPv6 domains, which
adds complexity to service deployment. When new functionalities
mentioned in the sectioned such as network slicing, Detnet,IOAM,etc.
are applied when traverse the IPv6 domains, it will cause more
complexity in service provisioning and more network state
maintenance.
5. Based on existing functionalities, MPVPN/TE/Fragmentation/ESP
need be supported by BIERin6.
2.2. BIERv6
The solution described in [I-D.xie-bier-ipv6-encapsulation] is called
BIERv6. The encapsulation of BIERv6 is as follows:
+---------------+------------------+----------------------+
| IPv6 header | IPv6 DO Header | X type of |
| | with BIER Option | C-multicast packet |
| | | |
| Next Hdr = 60 | Nxt Hdr = X | (IPv4/IPv6/Ethernet) |
+---------------+------------------+----------------------+
| | |
|<----------BIERv6 header--------->|<---BIERv6 payload--->|
BIERv6 proposes to define a new type of destination options header
for BIER. The destination address of the IPv6 header indicates the
BIER forwarding nodes and changed to the next BIER forwarding nodes
based on the result of BIER forwarding table lookup.
Li, et al. Expires January 13, 2022 [Page 4]
Internet-Draft Gap Analysis of MSR6 July 2021
BIERv6 implements P2MP forwarding follows the BIER architecture
defined in [RFC8279].
BIERv6 uses Native IPv6 extention header to carry BIER info. And
BIERv6 could support MVPN by defining MVPN indication in source
address of the outer IPv6 header, which doesn't change along the P2MP
tunnel. The MVPN mechanism for BIERv6 is defined in
[I-D.xie-bier-ipv6-mvpn]. BIERv6 is able to directly reuse the new
functionalities supported by IPv6 and SRv6 without the problems
associated with Layered Architecture. In addition, BIERv6 uses
Native IPv6 and can be started directly at the Host without conflicts
with the transport layer.
BIERv6 has the following challenges:
1. Non-MPLS BIER header defined in [RFC8296] is used, but the BIER
header is designed as a separate layer, leaving some fields unused
and redundant in IPv6.
2. BIERv6 needs to support MVPN and Traffic Engineering.
2.3. Historical Review
In the field of IPv6 unicast source routing, there has been SR over
IP([RFC8663]) and SRv6. SR over IP takes the layered architecture
while SRv6 adopts native IPv6 design. Both solutions has different
application scenarios though there is the common functionality to
traverse IPv6 domain. SR over IP controls the scope to support more
new functionalities in the IPv6 data plane. SRv6 is being developed
combing with the new functionalities based on the IPv6 extension.
3. Summary
MSR6 is supposed to have:
o Native IPv6 design to reduce header layers and enable unified
processing
o Reuse existing IPv6 capabilities and SRv6 capabilities for
multicast
o BIER is able to implement network programming at the ingress nodes
in Best Effort scenarios. MSR6 needs to take advantage of the
capabilities in the existing BIER mechanism
o MVPN and Traffic Engineering support are requested
Li, et al. Expires January 13, 2022 [Page 5]
Internet-Draft Gap Analysis of MSR6 July 2021
The existing multicast solutions have their own limitations which
constrains the deployment and development of multicast. New
multicast solution is expected in IETF.
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
TBD
6. Acknowledgements
TBD
7. Normative References
[I-D.cheng-spring-ipv6-msr-design-consideration]
Cheng, W., Mishra, G., Li, Z., Wang, A., Qin, Z., and C.
Fan, "Design Consideration of IPv6 Multicast Source
Routing (MSR6)", draft-cheng-spring-ipv6-msr-design-
consideration-00 (work in progress), July 2021.
[I-D.xie-bier-ipv6-encapsulation]
Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,
"Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-
xie-bier-ipv6-encapsulation-10 (work in progress),
February 2021.
[I-D.xie-bier-ipv6-mvpn]
Xie, J., McBride, M., Dhanaraj, S., Geng, L., and G.
Mishra, "Use of BIER IPv6 Encapsulation (BIERv6) for
Multicast VPN in IPv6 networks", draft-xie-bier-
ipv6-mvpn-03 (work in progress), October 2020.
[I-D.zhang-bier-bierin6]
Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli,
H., and G. Mishra, "Supporting BIER in IPv6 Networks
(BIERin6)", draft-zhang-bier-bierin6-09 (work in
progress), February 2021.
[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>.
Li, et al. Expires January 13, 2022 [Page 6]
Internet-Draft Gap Analysis of MSR6 July 2021
[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>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
DOI 10.17487/RFC8663, December 2019,
<https://www.rfc-editor.org/info/rfc8663>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Zhuangzhuang Qin
China Unicom
Email: qinzhuangzhuang@chinaunicom.cn
Li, et al. Expires January 13, 2022 [Page 7]