Internet-Draft BIERin6 March 2023
Zhang, et al. Expires 6 September 2023 [Page]
Workgroup:
BIER
Internet-Draft:
draft-ietf-bier-bierin6-06
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Zhang
ZTE Corporation
Z. Zhang, Ed.
Juniper Networks
I. Wijnands
Individual
M. Mishra
Cisco Systems
H. Bidgoli
Nokia
G. Mishra
Verizon

Supporting BIER in IPv6 Networks (BIERin6)

Abstract

BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 6 September 2023.

Table of Contents

1. Introduction

BIER [RFC8279] is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication.

BIER forwarding with MPLS is IPv4/IPv6 agnostic. This document describes how BIER works in a non-MPLS IPv6 [RFC8200] environment using non-MPLS BIER encapsulation [RFC8296], with optional procedures specified for IPv6 specific features.

This document uses terminology defined in [RFC8279] and [RFC8296].

1.1. BIER over L2/Tunnels

[RFC8296] defines the BIER encapsulation format for MPLS and non-MPLS data planes. With a non-MPLS data plane, a BIER packet is the payload of an "outer" encapsulation, which could be a L2 link or a tunnel. The outer encapsulation has a "next header" field that is set to a value for "non-MPLS BIER". This "BIER over L2/Tunnel" model can be used as is in an IPv6 non-mpls environment, and is referred to as BIERin6.

If a BFR needs to tunnel BIER packets to another BFR, e.g. per [RFC8279] Section 6.9, while any type of tunnel will work, for best efficiency native IPv6 encapsulation can be used with the destination address being the downstream BFR and the Next Header field set to a to-be-assigned value for BIER.

                   +---------------+------------------------
                   |  IPv6 header  | BIER header + data
                   |               |
                   | Next Header = |
                   |    BIER       |
                   +---------------+------------------------

Between two directly connected BFRs, a BIER header can directly follow link layer header, e.g., an Ethernet header (with the Ethertype set to 0xAB37). Optionally, IPv6 encapsulation can be used even between directly connected BFRs (i.e. one-hop IPv6 tunneling) in the following two cases:

1.2. Considerations of Requirements for BIER in IPv6 Networks

[I-D.ietf-bier-ipv6-requirements] lists mandatory and optional requirements for BIER in IPv6 Networks. As a solution based on the BIER over L2/tunnel model [RFC8296], BIERin6 satisfies all the mandatory requirements.

For the two optional requirements for fragmentation and Encapsulating Security Payload (ESP), they can be satisfied by one of two ways:

Either way, the fragmentation/ESP is handled by a layer outside of BIER and then the resulting packets are treated as BIER payload. The details are outside the scope of this document.

BIERin6 does support SRv6 based overlay services (e.g. MVPN/EVPN). One of the following methods can be used (relevant overlay signaling will be specified separately):

BIERin6 being a solution based on [RFC8279], [RFC8296], ECMP is inherently supported by BFRs using the the 20-bit entropy field in the BIER header for the load balancing hash. When a BIER packet is transported over an IPv6 tunnel, the entropy value is copied into the 20-bit IPv6 Flow Label so that routers along the tunnel can do ECMP based on Flow Labels (instead of hashing based on 5-tuple of an IP packet). For a router along the tunnel doing deep packet inspection for ECMP purpose, if it understands BIER header it can go past the BIER header to look for the 5-tuple input key to a hash function. Otherwise, it stops at the BIER header. In either case the router will not mistake the BIER header as an IP header so no misordering should happen.

BIER has its own OAM functions independent of those related to the underlying links or tunnels. With BIERin6 following the "BIER over L2/tunnel" model, IPv6 OAM function and BIER OAM functions are used independently for their own purposes.

Specifically, BIERin6 works with all of the following OAM methods, or any future methods that are based on the "BIER over L2/tunnel" model:

2. IPv6 Header

If IPv6 encapsulation is used to tunnel BIER packets (whether to a direct or indirect BIER neighbor), the Next Header field in the IPv6 Header (if there are no extension headers), or the Next Header field in the last extension header is set to TBD, indicating that the payload is a BIER packet.

If the neighbor is directly connected, The destination address in IPv6 header SHOULD be the neighbor's link-local address on this router's outgoing interface. The source destination address SHOULD be this router's link-local address on the outgoing interface, and the TTL MUST be set to 1.

If the neighbor is not directly connected, the destination address SHOULD be the BIER prefix of the BFR neighbor. The source address SHOULD be this router's BIER prefix, and the TTL MUST be large enough to get the packet to the BFR neighbor.

The "Flow label" field in the IPv6 packet SHOULD be copied from the entropy field in the BIER encapsulation.

3. BIER Header

The BIER header MUST be encoded per Section 2.2 of [RFC8296].

The BIFT-id is either encoded per [I-D.ietf-bier-non-mpls-bift-encoding] or per advertised by BFRs, as specified in [I-D.ietf-bier-lsr-non-mpls-extensions].

4. IPv6 Encapsulation Advertisement

When IPv6 encapsulation is not required between directly connected BFRs, no signaling in addition to that specified in [I-D.ietf-bier-lsr-non-mpls-extensions] is needed.

Otherwise, a node that requires IPv6 encapsulation MUST advertise the BIER IPv6 encapsulation sub-sub-sub-TLV/sub-sub-TLV according to local configuration or policy in the BIER domain to request other BFRs to always use IPv6 encapsulation.

4.1. Format

The BIER IPv6 Encapsulation is a new sub-sub-TLV of OSPFv3 BIER non-MPLS Encapsulation sub-TLV, and a new sub-sub-sub-TLV of ISIS BIER non-MPLS Encapsulation sub-sub-TLV as per [I-D.ietf-bier-lsr-non-mpls-extensions].

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Type       |   Length      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2. Inter-area prefix redistribution

When BFR-prefixes are advertised across IGP areas per [I-D.ietf-bier-lsr-non-mpls-extensions] or redistributed across protocol boundaries per [I-D.ietf-bier-prefix-redistribute], the BIER IPv6 encapsulation sub-sub-TLV or sub-sub-sub-TLV MAY be re-advertised/re-distributed as well.

5. IANA Considerations

IANA is requested to assign a "BIER" type for "Next Header" in the "Assigned Internet Protocol Numbers" registry.

IANA is requested to assign a "BIER IPv6 encapsulation Sub-sub-TLV" type in the "OSPFv3 BIER non-MPLS Encapsulation sub-TLV" Registry.

IANA is requested to assign a "BIER IPv6 encapsulation Sub-sub-sub-TLV" type in the "IS-IS BIER non-MPLS Encapsulation sub-sub-TLV" Registry.

IANA is requested to allocate a value "SRv6 Service" from "BIER Next Protocol Identifiers" registry to indicate that BIER payload starts with an SRv6 Service SID.

6. Security Considerations

General IPv6 and BIER security considerations apply.

7. Acknowledgement

The authors would like to thank Tony Przygienda, Nagendra Kumar for their review and valuable comments.

8. References

8.1. Normative References

[I-D.ietf-bier-lsr-non-mpls-extensions]
Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, Z. J., and J. Xie, "LSR Extensions for BIER non-MPLS Encapsulation", Work in Progress, Internet-Draft, draft-ietf-bier-lsr-non-mpls-extensions-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-lsr-non-mpls-extensions-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc8296>.
[RFC9252]
Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, , <https://www.rfc-editor.org/info/rfc9252>.

8.2. Informative References

[I-D.ietf-bier-bfd]
Xiong, Q., Mirsky, G., hu, F., and C. Liu, "BIER BFD", Work in Progress, Internet-Draft, draft-ietf-bier-bfd-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-bfd-02>.
[I-D.ietf-bier-ipv6-requirements]
McBride, M., Xie, J., Geng, X., Dhanaraj, S., Asati, R., Zhu, Y., Mishra, G. S., and Z. J. Zhang, "BIER IPv6 Requirements", Work in Progress, Internet-Draft, draft-ietf-bier-ipv6-requirements-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-ipv6-requirements-09>.
[I-D.ietf-bier-non-mpls-bift-encoding]
Wijnands, I., Mishra, M. P., Xu, X., and H. Bidgoli, "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation", Work in Progress, Internet-Draft, draft-ietf-bier-non-mpls-bift-encoding-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-non-mpls-bift-encoding-04>.
[I-D.ietf-bier-path-mtu-discovery]
Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer", Work in Progress, Internet-Draft, draft-ietf-bier-path-mtu-discovery-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-path-mtu-discovery-13>.
[I-D.ietf-bier-ping]
Nainar, N. K., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", Work in Progress, Internet-Draft, draft-ietf-bier-ping-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-ping-07>.
[I-D.ietf-bier-pmmm-oam]
Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, "Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer", Work in Progress, Internet-Draft, draft-ietf-bier-pmmm-oam-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-pmmm-oam-13>.
[I-D.ietf-bier-prefix-redistribute]
Zhang, Z., Wu, B., Zhang, Z. J., Wijnands, I., Liu, Y., and H. Bidgoli, "BIER Prefix Redistribute", Work in Progress, Internet-Draft, draft-ietf-bier-prefix-redistribute-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-prefix-redistribute-03>.
[I-D.xzlnp-bier-ioam]
Min, X., Zhang, Z., Liu, Y., Nainar, N. K., and C. Pignataro, "BIER Encapsulation for IOAM Data", Work in Progress, Internet-Draft, draft-xzlnp-bier-ioam-05, , <https://datatracker.ietf.org/doc/html/draft-xzlnp-bier-ioam-05>.
[I-D.zzhang-intarea-generic-delivery-functions]
Zhang, Z. J., Bonica, R., Kompella, K., and G. Mirsky, "Generic Delivery Functions", Work in Progress, Internet-Draft, draft-zzhang-intarea-generic-delivery-functions-03, , <https://datatracker.ietf.org/doc/html/draft-zzhang-intarea-generic-delivery-functions-03>.
[RFC7368]
Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, , <https://www.rfc-editor.org/info/rfc7368>.

Authors' Addresses

Zheng(Sandy) Zhang
ZTE Corporation
Zhaohui Zhang (editor)
Juniper Networks
IJsbrand Wijnands
Individual
Mankamana Mishra
Cisco Systems
Hooman Bidgoli
Nokia
Gyan Mishra
Verizon