< draft-xie-bier-ipv6-encapsulation-04.txt   draft-xie-bier-ipv6-encapsulation-05.txt >
Network Working Group J. Xie Network Working Group J. Xie
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track L. Geng Intended status: Standards Track L. Geng
Expires: June 13, 2020 China Mobile Expires: July 17, 2020 China Mobile
M. McBride M. McBride
Futurewei Futurewei
R. Asati R. Asati
Cisco Cisco
S. Dhanaraj S. Dhanaraj
Huawei Huawei
December 11, 2019 January 14, 2020
Encapsulation for BIER in Non-MPLS IPv6 Networks Encapsulation for BIER in Non-MPLS IPv6 Networks
draft-xie-bier-ipv6-encapsulation-04 draft-xie-bier-ipv6-encapsulation-05
Abstract Abstract
This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- This document proposes a BIER IPv6 (BIERv6) encapsulation for Non-
MPLS IPv6 Networks using the IPv6 Destination Option extension MPLS IPv6 Networks using the IPv6 Destination Option extension
header. header. This document updates [RFC8296].
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and document are to be interpreted as described in [RFC2119] and
[RFC8174]. [RFC8174].
Status of This Memo Status of This Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 June 13, 2020. This Internet-Draft will expire on July 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12
5.2. Inter Domain Deployment . . . . . . . . . . . . . . . . . 13 5.2. Inter Domain Deployment . . . . . . . . . . . . . . . . . 13
5.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13 5.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13
5.4. Security caused by BIER option . . . . . . . . . . . . . 14 5.4. Security caused by BIER option . . . . . . . . . . . . . 14
5.5. Applicability of IPsec . . . . . . . . . . . . . . . . . 14 5.5. Applicability of IPsec . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15
6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15
6.3. BIER Next Protocol Identifiers . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 any per-flow state by using a intermediate routers to maintain any per-flow state by using a
multicast-specific BIER header. multicast-specific BIER header.
[RFC8296] defines a common BIER Header format for MPLS and Non-MPLS [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS
skipping to change at page 5, line 11 skipping to change at page 5, line 11
BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS
IPv6 encapsulation. See Section 2.2 of RFC 8296. IPv6 encapsulation. See Section 2.2 of RFC 8296.
TC: SHOULD be set to binary value 000 upon transmission and MUST TC: SHOULD be set to binary value 000 upon transmission and MUST
be ignored upon. See Section 2.2 of RFC 8296. be ignored upon. See Section 2.2 of RFC 8296.
S bit: SHOULD be set to 1 upon transmission, and MUST be ignored S bit: SHOULD be set to 1 upon transmission, and MUST be ignored
upon reception. See Section 2.2 of RFC 8296. upon reception. See Section 2.2 of RFC 8296.
TTL: MUST be set to 0 upon transmission, and MUST be ignored TTL: MUST be set to a value larger than 0 upon encapsulation,
upon reception. The function of TTL is replaced by the Hop and SHOULD decrease by 1 by a BFR when forwarding a BIERv6
Limit field in IPv6 header. packet to a BFR adjacency. If the incoming TTL is 0, the packet
is considered to be "expired". See Section 2.1.1.2 of RFC 8296.
Nibble: SHOULD be set to 0000 upon transmission, and MUST be Nibble: SHOULD be set to 0000 upon transmission, and MUST be
ignored upon reception. See Section 2.2 of RFC 8296. ignored upon reception. See Section 2.2 of RFC 8296.
Ver: MUST be set to 0 upon transmission, and MUST be discarded Ver: MUST be set to 0 upon transmission, and MUST be discarded
when it is not 0 upon reception. See Section 2.2 of RFC 8296. when it is not 0 upon reception. See Section 2.2 of RFC 8296.
BSL: See Section 2.1.2 of RFC 8296. BSL: See Section 2.1.2 of RFC 8296.
Entropy: See Section 2.1.2 of RFC 8296. Entropy: See Section 2.1.2 of RFC 8296.
OAM: See Section 2.1.2 of RFC 8296. OAM: See Section 2.1.2 of RFC 8296.
Rsv: See Section 2.1.2 of RFC 8296. Rsv: See Section 2.1.2 of RFC 8296.
DSCP: SHOULD be set to binary value 000000 upon transmission and DSCP: SHOULD be set to binary value 000000 upon transmission and
MUST be ignored upon reception. In IPv6 BIER encapsulation, MUST be ignored upon reception. In IPv6 BIER encapsulation,
uses highest 6-bit of Traffic Class field of IPv6 header to hold uses highest 6-bit of Traffic Class field of IPv6 header to hold
a Differentiated Services Codepoint [RFC2474]. a Differentiated Services Codepoint [RFC2474].
Proto: SHOULD be set to 0 upon transmission and MUST be ignored Proto: This fileld is used for two functions. The first is to
upon reception. In IPv6 BIER encapsulation, the functionality identify the BIER Payload following the BIER header, and the
of this 6-bit Proto field is replaced by the Next Header field second is to deliver the packet to a proper overlay module by
in Destination Options header, which is the last IPv6 extension BIER layer, with VRF lookup in case of BIER data process, or
header, to indicate the BIER payload, which is also IPv6 without VRF lookup in case of BIER OAM process. In BIER IPv6
payload. encapsulation, the first function of Proto is compromised by a
proper Next Header value combination, and the second function of
For BIER Proto 1, indicating a Downstream-assigned MPLS Proto should be kept with the semantic unique and consistent for
payload, use Next Header value 137. BIER demultiplexing. This updates section 2.1.2 of [RFC8296]
about Proto defination. This document support the following
For BIER Proto 2, indicating an Upstream-assigned MPLS combination of BIER Proto and Next Header:
payload, there is no Next Header code currently. An
upstream-assigned MPLS label within the context of special
BFIR router, which in turn is represented by the BFIR-id and
the Sub-domain indirectly indicated by the BIFT-id in a BIER-
MPLS or BIER-ETH packet, can be replaced by an IPv6 source
address in a BIER IPv6 encapsulation packet in a direct
manner. In this case, use Next Header value 4 for IPv4
payload, or value 41 for IPv6 payload.
For BIER Proto 3, indicating an Ethernet payload, use Next Use Next Header value 4, 41 and TBD0 for IPv4 packet, IPv6
Header value 97. packet and Ethernet packet respectively, and use Proto value
TBD1 indicating "Delivering the data packet with VRF lookup
in IPv6 source address".
For BIER Proto 4, indicating an IPv4 payload, use Next Header Use Next Header value 59 for private packet format, and use
value 4. Proto value 5 indicating "Delivering the BIER OAM packet
without VRF lookup". The BIER-PING [I-D.ietf-bier-ping]
works equally in BIER IPv6 encapsulation as well as in BIER
MPLS or BIER Ethernet encapsulation.
For BIER Proto 5, indicating a BIER-OAM payload, use Next Allocation of Next Header value TBD0 for Ethernet packet is
Header value 58. How the BIER-PING is supported with BIER applying in [I-D.ietf-spring-srv6-network-programming] and
IPv6 encapsulation is outside the scope of this document. will not be listed in the IANA considerations section of this
document.
For BIER Proto 6, indicating an IPv6 payload, use Next Header Allocation of BIER Proto value TBD1 is listed in the IANA
value 41. considerations section of this document.
BFIR-id: See Section 2.1.2 of RFC 8296. BFIR-id: See Section 2.1.2 of RFC 8296.
BitString: See Section 2.1.2 of RFC 8296. BitString: See Section 2.1.2 of RFC 8296.
3.2. Multicast and Unicast Destination Address 3.2. Multicast and Unicast Destination Address
BIER is generally a hop-by-hop and one-to-many architecture, and thus BIER is generally a hop-by-hop and one-to-many architecture, and thus
the IPv6 Destination Address (DA) being a Multicast Address is a way the IPv6 Destination Address (DA) being a Multicast Address is a way
one may think of as an approach for both the two paradigms in BIERv6 one may think of as an approach for both the two paradigms in BIERv6
skipping to change at page 6, line 49 skipping to change at page 6, line 48
4. Connecting BIER domains, for example Data Center domains, in an 4. Connecting BIER domains, for example Data Center domains, in an
overlay manner. overlay manner.
Some of the above functions are assumed very basic requirements and Some of the above functions are assumed very basic requirements and
part of BIER architecture as described in [RFC8279]. This document part of BIER architecture as described in [RFC8279]. This document
uses unicast address for both one-hop replication and multi-hop uses unicast address for both one-hop replication and multi-hop
replication. replication.
The unicast address used in BIERv6 packet targeting a BFR SHOULD be The unicast address used in BIERv6 packet targeting a BFR SHOULD be
the IPv6 BFR-Prefix advertised from this BFR. When a BFR advertises advertised as part of the BIER IPv6 Encapsulation. When a BFR
the BIER information with BIERv6 encapsulation capability, the IPv6 advertises the BIER information with BIERv6 encapsulation capability,
BFR-prefix of this BFR MUST be selected specifically for BIERv6 an IPv6 unicast address of this BFR MUST be selected specifically for
packet forwarding. Locally this "BIER Specific" IPv6 address is BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address
initialized in FIB with a flag of "BIER specific handling", is initialized in FIB with a flag of "BIER specific handling",
represented as End.BIER function. For convenience, the indication in represented as End.BIER function.
FIB share the same space as SRv6 Endpoints Behaviors defined in
[I-D.ietf-spring-srv6-network-programming]. Apart from this sharing
of code space, there is nothing dependent on SRv6. The co-existance
of BIERv6 and SRv6 is outside the scope of this document.
BFR Prefix is used only in control plane in BIER MPLS encapsulation If a BFR belongs to more than one sub-domain, it may (though it need
but not used in data plane. While in BIERv6, BFR prefix is used in not) have a different End.BIER in each sub-domain. If different
both control plane and data plane. For the convinence of migration End.BIER is used for each sub-domain, implementation SHOULD support
to BIERv6, it is RECOMMENDED to use an "exclusive" IPv6 address as verifying the DA of a BIERv6 packet is the End.BIER address bound by
BFR prefix when deploying BIER-MPLS in IPv6 networks. The the sub-domain of the packet. See section 5.2 for such use case.
"exclusive" IPv6 address should not be used for general purpose like
BGP session establishment, but for "BIER specific" function. For
Non-BIER IPv6 routers, the IPv6 address is a regular IPv6 prefix
reachable through IPv6 unicast routing.
The following is an example of configuring a BIER specific IPv6 The following is an example of configuring a sub-domain using BIER
address and using this address as BFR prefix: IPv6 encapsualation:
# Config a BIER specific IPv6 address with 128-bit mask on loopback0. # Config an IPv6 block for End.BIER IPv6 address allocation
interface loopback0 ipv6-block blk1 2001:DB8:A1:: 96 static 32
ipv6 address 2001:DB8::AB37 128 End.BIER
# Config the BIER-specific IPv6 address on loopback0 as BFR Prefix. # Config BIER Sub-domain using End.BIER allocated from blk1
bier sub-domain 6 ipv6-underlay bier sub-domain 6 ipv6-underlay
bfr-prefix interface loopback0 bfr-prefix interface loopback0
end-bier ipv6-block blk1 opcode ::1
encapsulation ipv6 bsl 256 max-si 0
The address used as "BIER specific" IPv6 address can be from inside The co-existance of BIERv6 and SRv6 is allowed. The following is an
the scope of an SRv6 Locator or outside the scope of the SRv6 example of configuring a sub-domain using BIERv6 when SRv6 is already
Locator(s) since it is a host prefix (128-bit prefix-length prefix). deployed with a locator 'loc1' configured:
Each "BIER specific" address can be used in one or many sub-domains # Config BIER Sub-domain using End.BIER allocated from loc1
as BFR-prefix, such that it can be associated with one or many Multi- bier sub-domain 6 ipv6-underlay
Topologies (MTs) or algorithms. bfr-prefix interface loopback0
end-bier locator loc1 opcode ::1
encapsulation ipv6 bsl 256 max-si 0
More than one "BIER specific" address are also allowed as different For the convenience of such co-existence of BIERv6 and SRv6, the
BFR-prefix of more than one sub-domain, as described in section 2 of indication of End.BIER or "BIER specific handling" in FIB shares the
[RFC8279]. same space as SRv6 Endpoints Behaviors defined in
[I-D.ietf-spring-srv6-network-programming]. Apart from this sharing
of code space, there is nothing dependent on SRv6.
The following is an example pseudo-code of the End.BIER function: The following is an example pseudo-code of the End.BIER function:
1. IF NH = 60 and HopLimit > 0 ;;Ref1 1. IF NH = 60 and HopLimit > 0 ;;Ref1
2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2
3. Lookup the BIER Header inside the BIER option TLV. 3. Lookup the BIER Header inside the BIER option TLV.
4. Forward via the matched entry. 4. Forward via the matched entry.
5. ELSE ;;Ref3 5. ELSE ;;Ref3
6. Drop the packet and end the process. 6. Drop the packet and end the process.
7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4
skipping to change at page 9, line 46 skipping to change at page 9, line 46
some IPv6-specific processing procedures due to the base and general some IPv6-specific processing procedures due to the base and general
procedures of IPv6. procedures of IPv6.
On the overlay layer, when a multicast packet enters the BIER domain On the overlay layer, when a multicast packet enters the BIER domain
in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the
multicast packet with a BIERv6 Header, transforming it to a BIERv6 multicast packet with a BIERv6 Header, transforming it to a BIERv6
packet. The BIERv6 header includes an IPv6 header and IPv6 packet. The BIERv6 header includes an IPv6 header and IPv6
Destination Options Header within a standard Non-MPLS BIER header. Destination Options Header within a standard Non-MPLS BIER header.
Source Address field in the IPv6 header MUST be set to a routable Source Address field in the IPv6 header MUST be set to a routable
IPv6 unicast address of the BFIR. Destination Address field in the IPv6 unicast address of the BFIR. Destination Address field in the
IPv6 header is set to the BFR prefix of the next-hop BFR the BIERv6 IPv6 header is set to the End.BIER address of the next-hop BFR the
packet replicating to, no matter next-hop BFR is directly connected BIERv6 packet replicating to, no matter next-hop BFR is directly
(one-hop) or not directly connected (multi-hop). connected (one-hop) or not directly connected (multi-hop).
On the BIER layer, upon receiving an BIERv6 packet, the BFR processes On the BIER layer, upon receiving an BIERv6 packet, the BFR processes
the IPv6 header first. This is the general procedure of IPv6. the IPv6 header first. This is the general procedure of IPv6.
If the IPv6 Destination address is an IPv6 BFR-Prefix unicast address If the IPv6 Destination address is an End.BIER IPv6 unicast address
of this BFR, a 'BIER Specific Handling' indication will be obtained of this BFR, a 'BIER Specific Handling' indication will be obtained
by the preceding Unicast DA lookup (FIB lookup). The BIER option, if by the preceding Unicast DA lookup (FIB lookup). The BIER option, if
exists, will be checked to decide which neighbor(s) to replicate the exists, will be checked to decide which neighbor(s) to replicate the
BIERv6 packet to. BIERv6 packet to.
It is a local behavior to handle the combination of extension It is a local behavior to handle the combination of extension
headers, options and the BIER option(s) in destination options header headers, options and the BIER option(s) in destination options header
when a 'BIER Specific Handling' indication is got by the preceding when a 'BIER Specific Handling' indication is got by the preceding
FIB lookup. Early deployment of BIERv6 may require there is only one FIB lookup. Early deployment of BIERv6 may require there is only one
BIER option TLV in the destination options header followed the IPv6 BIER option TLV in the destination options header followed the IPv6
skipping to change at page 10, line 29 skipping to change at page 10, line 29
A packet having a 'BIER Specific Handling' indication but not having A packet having a 'BIER Specific Handling' indication but not having
a BIER option is supposed to be a wrong packet or an ICMPv6 packet, a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
and the process can be refered to the example in section 3.2. and the process can be refered to the example in section 3.2.
A packet not having a 'BIER Specific Handling' indication but having A packet not having a 'BIER Specific Handling' indication but having
a BIER option SHOULD be processed normally as unicast forwarding a BIER option SHOULD be processed normally as unicast forwarding
procedures, which may be a behavior of drop, or send to CPU, or other procedures, which may be a behavior of drop, or send to CPU, or other
behaviors in existing implementations. behaviors in existing implementations.
The Destination Address field in the IPv6 Header MUST change to the The Destination Address field in the IPv6 Header MUST change to the
nexthop BFR's BFR Prefix if Unicast address is used in BIERv6. nexthop BFR's End.BIER Unicast address in BIERv6.
The Hop Limit field of IPv6 header MUST decrease by 1 when sending The Hop Limit field of IPv6 header MUST decrease by 1 when sending
packets to a BFR neighbor, while the TTL in the BIER header MUST be packets to a BFR neighbor, while the TTL in the BIER header MUST be
unchanged. unchanged on a Non-BIER router, or decrease by 1 on a BFR.
The BitString in the BIER header in the Destination Options Header The BitString in the BIER header in the Destination Options Header
may change when sending packets to a neighbor. Such change of may change when sending packets to a neighbor. Such change of
BitString MUST be aligned with the procedure defined in RFC8279. BitString MUST be aligned with the procedure defined in RFC8279.
Because of the requirement to change the content of the option when Because of the requirement to change the content of the option when
forwarding BIERv6 packet, the BIER option type should have chg flag 1 forwarding BIERv6 packet, the BIER option type should have chg flag 1
per section 4.2 of RFC8200. per section 4.2 of RFC8200.
The procedures applies normally if a bit corresponding to the self The procedures applies normally if a bit corresponding to the self
bfr-id is set in the bit-string field of the Non-MPLS BIER header of bfr-id is set in the bit-string field of the Non-MPLS BIER header of
skipping to change at page 16, line 11 skipping to change at page 16, line 11
Allocation is expected from IANA for an End.BIER function codepoint Allocation is expected from IANA for an End.BIER function codepoint
from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is
suggested. suggested.
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
| Value | Hex | Endpoint function | Reference | | Value | Hex | Endpoint function | Reference |
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
| TBD | TBD | End.BIER | This draft | | TBD | TBD | End.BIER | This draft |
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
6.3. BIER Next Protocol Identifiers
Allocation is expected from IANA for a BIER Proto codepoint from the
"BIER Next Protocol Identifiers" sub-registry.
TBD1: Delivering the packet with VRF lookup in IPv6 source address
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Stig Venaas for his valuable The authors would like to thank Stig Venaas for his valuable
comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda,
Toerless Eckert, Jeffrey Zhang for the helpful comments to improve Toerless Eckert, Jeffrey Zhang for the helpful comments to improve
this document. this document.
Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6
encapsulation.
Thanks Mach Chen for review and suggestions about BIER-PING function
in BIER IPv6 encapsulation.
8. Contributors 8. Contributors
Gang Yan Gang Yan
Huawei Technologies Huawei Technologies
China China
Email: yangang@huawei.com Email: yangang@huawei.com
skipping to change at page 17, line 48 skipping to change at page 18, line 17
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>. 2019, <https://www.rfc-editor.org/info/rfc8556>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-bier-ipv6-requirements] [I-D.ietf-bier-ipv6-requirements]
McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER
IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03 IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03
(work in progress), November 2019. (work in progress), November 2019.
[I-D.ietf-bier-ping]
Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier-
ping-06 (work in progress), October 2019.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-05 (work in draft-ietf-spring-srv6-network-programming-07 (work in
progress), October 2019. progress), December 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 30 change blocks. 
84 lines changed or deleted 99 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/