< draft-ietf-bier-ipv6-requirements-02.txt   draft-ietf-bier-ipv6-requirements-03.txt >
Network Working Group M. McBride Network Working Group M. McBride
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track J. Xie Intended status: Standards Track J. Xie
Expires: May 4, 2020 S. Dhanaraj Expires: May 5, 2020 S. Dhanaraj
Huawei Huawei
R. Asati R. Asati
Cisco Cisco
November 1, 2019 November 2, 2019
BIER IPv6 Requirements BIER IPv6 Requirements
draft-ietf-bier-ipv6-requirements-02 draft-ietf-bier-ipv6-requirements-03
Abstract Abstract
The BIER WG includes, in it's charter, work on developing mechanisms The BIER WG includes, in its charter, work on developing mechanisms
to transport BIER natively in IPv6. This document is intended to to transport BIER natively in IPv6. This document is intended to
help the WG with this effort by specifying requirements for help the WG with this effort by specifying requirements for
transporting packets, with Bit Index Explicit Replication (BIER) transporting packets, with Bit Index Explicit Replication (BIER)
headers, in an IPv6 environment. There will be a need to send IPv6 headers, in an IPv6 environment. There will be a need to send IPv6
payloads, to multiple IPv6 destinations, using BIER. There have been payloads, to multiple IPv6 destinations, using BIER. There have been
several proposed solutions in this area. But there hasn't been a several proposed solutions in this area. But there hasn't been a
document which describes the problem and lists the requirements. The document which describes the problem and lists the requirements. The
goal of this document is to describe the BIER IPv6 requirements, goal of this document is to describe the BIER IPv6 requirements,
summarize the proposed solutions, and guide the working group in summarize the proposed solutions, and guide the working group in
understanding the benefits, and drawbacks, of the various solutions understanding the benefits, and drawbacks, of the various solutions
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2020. This Internet-Draft will expire on May 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4 3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4
3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4 3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4
3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4 3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4
3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5 3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5
3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5 3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Hop by hop SA modification . . . . . . . . . . . . . . . 5 4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5
4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6 4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Multicast address in SA field . . . . . . . . . . . . . . 6 4.4. Multicast address in SA field . . . . . . . . . . . . . . 7
4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 7 4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 7
4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7 4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7
4.7. BIER architecture support . . . . . . . . . . . . . . . . 7 4.7. BIER architecture support . . . . . . . . . . . . . . . . 7
4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 7 4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 8
4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7 4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 8
4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 8 4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 8
4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8 4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8
4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8 4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8
5. Solutions Evaluation . . . . . . . . . . . . . . . . . . . . 8 5. Solutions Evaluation . . . . . . . . . . . . . . . . . . . . 8
5.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 8 5.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 9
5.2. Encode Bitstring in IPv6 destination address . . . . . . 10 5.2. Encode Bitstring in IPv6 destination address . . . . . . 10
5.3. Add BIER header into IPv6 Extension Header . . . . . . . 10 5.3. Add BIER header into IPv6 Extension Header . . . . . . . 10
5.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 11 5.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 11
5.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 12 5.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
that provides optimal multicast forwarding, without requiring that provides optimal multicast forwarding, without requiring
intermediate routers to maintain per-flow state, through the use of a intermediate routers to maintain per-flow state, through the use of a
multicast-specific BIER header. [RFC8296] defines two types of BIER multicast-specific BIER header. [RFC8296] defines two types of BIER
skipping to change at page 5, line 38 skipping to change at page 5, line 38
There have been several suggested requirements, on the BIER email There have been several suggested requirements, on the BIER email
list and in meetings, which have been used to form BIER IPv6 list and in meetings, which have been used to form BIER IPv6
requirements used to help the wg evaluate against the proposed requirements used to help the wg evaluate against the proposed
solutions: solutions:
4.1. L2 Agnostic 4.1. L2 Agnostic
The solution should be agnostic to the underlying L2 data link type. The solution should be agnostic to the underlying L2 data link type.
4.2. Hop by hop SA modification 4.2. Hop by hop SA or DA modification
The solution should not require hop-by-hop modification of the IP The solution should not require hop-by-hop modification of the IP
source address field. source address field.
Solutions that do not require Hop-by-hop SA modification are Solutions that do not require Hop-by-hop SA modification are
preferred. Solutions which maintain the SA will help fast-path preferred. Solutions which maintain the SA will help fast-path
forwarding (req 4.9 in this doc), are beneficial for receiving forwarding (req 4.9 in this doc), are beneficial for receiving
notices from the BFIR for functions like BIER PING, TRACE and MTU notices from the BFIR for functions like BIER PING, TRACE and MTU
notification, are beneficial for identifying an MVPN instance to help notification, are beneficial for identifying an MVPN instance to help
remove more encapsulation such as Service Label (such as MPLS VPN remove more encapsulation such as Service Label (such as MPLS VPN
Label or VNI in the SRv6 network), and are beneficial for SA Label or VNI in the SRv6 network), are beneficial for SA filtering
filtering (req 4.6 in this doc). (req 4.6 in this doc), and are beneficial for data origin
authentication if IPSEC is desired (req 4.12 in this doc).
The solution should use a IPv6 unicast address in the DA to satisfy
the BIER architecture without introducing additional tunnel
encapsulation, and thus may require DA modification by each BFR hop.
It is commonly thought that BIERv6 could use a multicast address, as It is commonly thought that BIERv6 could use a multicast address, as
BIER is one-hop replication on each BFR in normal cases. However, as BIER is one-hop replication on each BFR in normal cases. However, as
described in section 6.9 of [RFC8279], it is useful to support non- described in section 6.9 of [RFC8279], it is useful to support non-
BIER routers within a BIER domain. From the wg discussion about this BIER routers within a BIER domain. From the wg discussion about this
document, focus is on the advantages of using unicast addresses that document, focus is on the advantages of using unicast addresses that
otherwise could not be possible by using a multicast address or otherwise could not be possible by using a multicast address or
anycast address for two cases: replication from a BFR to other BFR(s) anycast address for two cases: replication from a BFR to other BFR(s)
connected by Layer-3 Non-BFR router(s) without using tunneling connected by Layer-3 Non-BFR router(s) without using tunneling
techniques, and replication from a BFR to other BFR(s) connected by techniques, and replication from a BFR to other BFR(s) connected by
Layer-2 switch(es) without broadcasting or snooping on Layer-2 Layer-2 switch(es) without broadcasting or snooping on Layer-2
switch(es) in between. Based on the natural reachability of an IPv6 switch(es) in between. Based on the natural reachability of an IPv6
unicast address, it can support the multi-hop replication cases as unicast address, it can support the multi-hop replication cases as
well as the one-hop replication case. well as the one-hop replication case using one encapsulation.
This requirement may be deprecated if unicast address is prefered as
a solution for both multi-hop replication and one-hop replication
without using two different encapsulations.
4.3. L4 Inspection 4.3. L4 Inspection
The solution should not require the BFRs to inspect layer 4 or The solution should not require the BFRs to inspect layer 4 or
require any changes to layer 4. require any changes to layer 4.
In fragmentation events, BIER is payload and will be fragmented. For The proposals requiring BIER header encapsulated as part of the
instance (BIER-header + payload-1-to-1xxx bytes) in one packet, and payload may conflict with the layers of IP protocol stack. On the
(payload-1xxx-to-2xxx) in another packet. Thus, when BFR B receives one hand, fast-path BIER forwarding has to be based on the L4
a packet from BFR A, BFR B has to assemble the fragmented packets inspection of the BIER header within the payload, and on the other
before sending to BFR C and BFR D. hand, the BIER forwarding needs to change the BitString in the BIER
header of the payload, which in turn conflicts with other L3
functions. Following are some examples.
In IPSEC, the BIER header is part of the payload for confidentiality One example is in IP fragmentation case, where a packet may need to
or integrity. The need to change the BitString in the BIER Header, be fragmented by a BFIR, according to the BIER-MTU defined in
when forwarding BIER packets, makes it incompatible with IPSEC. RFC8296, into one packet with BIER header and 1500 bytes of payload,
and another packet with the remaining 500 bytes of payload. When BFR
B receives the second fragmentation packet from BFR A, BFR B can't
forward this packet because BFR B doesn't have the BIER header in the
second fragmentation packet. Section 4.11 describes the
fragmentation requirements.
In SRH, BIER is the payload, and will be reached only after the SRH The second example is in IPSEC case, where the BIER header is part of
is processed. Thus, when BFR B receive a packet with SRH from BFR A, the payload for confidentiality or integrity. The need to change the
BFR B has to process the SRH first, and then the Upper-layer BIER BitString in the BIER Header, when forwarding BIER packets, makes it
header last. SRH needs to be integrated for two reasons, first is incompatible with IPSEC. Section 4.12 describes the IPSEC
that the solution is targetted to work well in SRv6 networks as a use requirements.
case in section 3.4 of this doc, second reason is that a few of the
proposed solutions agree to consider SRH integration. The third example is in the case of working in SRv6 networks, as
described in section 3.4 of this document, BIERv6 may be used with
SRH. As BIER header is part of the payload, it will be reached only
after the SRH is processed. That is to say, when BFR B receives a
packet with SRH from BFR A, BFR B has to process the SRH first, and
then the Upper-layer BIER header last. The SRH can work well based
on the indication of the preceding IPv6 DA lookup in FIB, but for
BIER forwarding, the BIER header part of the payload has to be deeply
inspected on each BFR.
4.4. Multicast address in SA field 4.4. Multicast address in SA field
The solution should not allow a multicast address to be put in the IP The solution should not allow a multicast address to be put in the IP
source address field. According to [RFC1112] "A host group address source address field. According to [RFC1112] "A host group address
must never be placed in the source address field or anywhere in a must never be placed in the source address field or anywhere in a
source route or record route option of an outgoing IP datagram." source route or record route option of an outgoing IP datagram."
4.5. Incorrect bits 4.5. Incorrect bits
skipping to change at page 7, line 32 skipping to change at page 7, line 46
vector that can create 64 responses to a single probe. vector that can create 64 responses to a single probe.
4.7. BIER architecture support 4.7. BIER architecture support
It should be possible to use the solution to support the entire BIER It should be possible to use the solution to support the entire BIER
architecture. The ability to bypass Non-BIER routers and L2 switches architecture. The ability to bypass Non-BIER routers and L2 switches
is part of the BIER architecture and having this ability is a is part of the BIER architecture and having this ability is a
mandatory requirement. mandatory requirement.
Multiple sub-domains bound to one or many topologies or algorithms, Multiple sub-domains bound to one or many topologies or algorithms,
multiple sets for more BFERs, BS multiple BIFTs for ECMP should be multiple sets for more BFERs, multiple Bit String Length for
supported. different forwarding capability, and multiple BIFTs for ECMP should
be supported.
4.8. Simple Encapsulation 4.8. Simple Encapsulation
The solution should avoid requiring different encapsulation types, or The solution should avoid requiring different encapsulation types, or
complex tunneling techniques, to support BIER as an E2E multicast complex tunneling techniques, to support BIER as an E2E multicast
transport. transport.
A single encapsulation should support Layer-2 switches within BFRs, A single encapsulation should support Layer-2 switches within BFRs,
or non-BFR within a BIER domain, or inter-domain deployment of BIER. or non-BFR within a BIER domain, or inter-domain deployment of BIER.
 End of changes. 17 change blocks. 
37 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/