< draft-xie-bier-6man-encapsulation-01.txt   draft-xie-bier-6man-encapsulation-02.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: January 3, 2019 L. Wang Expires: March 5, 2019 L. Wang
China Mobile China Mobile
G. Yan G. Yan
M. McBride M. McBride
Y. Xia Y. Xia
Huawei Huawei
July 2, 2018 September 1, 2018
Encapsulation for BIER in Non-MPLS IPv6 Networks Encapsulation for BIER in Non-MPLS IPv6 Networks
draft-xie-bier-6man-encapsulation-01 draft-xie-bier-6man-encapsulation-02
Abstract Abstract
Bit Index Explicit Replication (BIER) introduces a new multicast- Bit Index Explicit Replication (BIER) introduces a new multicast-
specific BIER Header. Currently BIER has two types of encapsulation specific BIER Header. Currently BIER has two types of encapsulation
formats: one is MPLS encapsulation, the other is Ethernet formats: one is MPLS encapsulation, the other is Ethernet
encapsulation. This document proposes a BIER IPv6 encapsulation for encapsulation. This document proposes a BIER IPv6 encapsulation for
Non-MPLS IPv6 Networks using an IPv6 Destination Option extension Non-MPLS IPv6 Networks using an IPv6 Destination Option extension
header. header.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 January 3, 2019. This Internet-Draft will expire on March 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Requirements . . . . . . . . . . . . . 3 3. Problem Statement and Requirements . . . . . . . . . . . . . 3
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
4. IPv6 BIER Encapsulation . . . . . . . . . . . . . . . . . . . 4 4. IPv6 BIER Encapsulation . . . . . . . . . . . . . . . . . . . 4
4.1. Considerations . . . . . . . . . . . . . . . . . . . . . 4 4.1. Considerations . . . . . . . . . . . . . . . . . . . . . 4
4.2. IPv6 BIER Destination Option . . . . . . . . . . . . . . 4 4.2. IPv6 BIER Destination Option . . . . . . . . . . . . . . 4
4.3. The whole IPv6 header for BIER packets . . . . . . . . . 5 4.3. The whole IPv6 header for BIER packets . . . . . . . . . 5
5. BIER Forwarding in Non-MPLS IPv6 Networks . . . . . . . . . . 7 5. IPv6 BIER Forwarding . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Appendix A - BIER over IPv6 SRH Tunnel . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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. [RFC8296] defines two types of BIER multicast-specific BIER header. [RFC8296] defines two types of BIER
encapsulation formats: one is MPLS encapsulation, the other is non- encapsulation to run on physical links: one is BIER MPLS
MPLS encapsulation. The Non-MPLS encapsulation defined in [RFC8296] encapsulation to run on various physical links that support MPLS, the
is in fact an Ethernet encapsulation with an ethertype 0xAB37, and an other is BIER Ethernet encapsulation to run on ethernet links, with
'Ethernet encapsulation' will be used to refer to such an an ethertype 0xAB37. This document proposes a BIER IPv6
encapsulation in the following text. This document proposes a BIER encapsulation for Non-MPLS IPv6 Networks using an IPv6 Destination
IPv6 encapsulation for Non-MPLS IPv6 Networks using an IPv6 Option extension header.
Destination Option extension header.
2. Terminology 2. Terminology
Readers of this document are assumed to be familiar with the Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative terminology and concepts of the documents listed as Normative
References. References.
3. Problem Statement and Requirements 3. Problem Statement and Requirements
3.1. Problem Statement 3.1. Problem Statement
MPLS is a very popular and successful encapsulation. One of the MPLS is a very popular and successful encapsulation. With MPLS
benefits of MPLS is its ability to easily stack a label onto another, encapsulation, packets forwarding can not only run on various
thus forming a label stack. This same label stacking benefit is also physical links hop-by-hop, but also leverage the MPLS bypass tunnel
available for BIER by using an MPLS encapsulation. For example, an to gain the "fast reroute" capability.
MPLS-encapsulated BIER packet can easily run over an MPLS tunnel,
either a legacy RSVP-TE/LDP LSP, or an MPLS Segment Routing tunnel.
Such a mechanism is the key to obtain the capability of "fast
reroute" or "bypass a Non-capable router". To quote [RFC8279]:
o In the event that unicast traffic to the BFR-NBR is being sent via
a "bypass tunnel" of some sort, the BIER-encapsulated multicast
traffic sent to the BFR-NBR SHOULD also be sent via that tunnel.
This allows any existing "fast reroute" schemes to be applied to
multicast traffic as well as to unicast traffic.
o Unicast tunnels are used to bypass non-BFRs.
Some other scenarios also need BIER to run on a tunnel, such as This same label benefit is also available for BIER by using an MPLS
transferring a BIER packet through a whole Non-BIER network or encapsulation. For example, an MPLS-encapsulated BIER packet can be
domain. forwarding on various physical links hop-by-hop, as well as on any
MPLS bypass tunnels to support "fast reroute".
The capability to run BIER on a tunnel, especially the widely With a BIER Ethernet encapsulation, however, a packet can not be
deployed mpls tunnel, can be obtained by using a BIER MPLS forwarded on any other type of links except for ethernet links in
encapsulation, but cannot be obtained by using a BIER Ethernet hop-by-hop case. It can not run on an MPLS bypass tunnel to support
encapsulation. It is not possible either, to run BIER on other links "fast reroute" either.
such as POS, by using BIER Ethernet encapsulation.
The capability of running BIER on various kinds of links and tunnels, In an IPv6 network, there are considerations of using a non-MPLS
by using an MPLS encapsulation, is beneficial to BIER deployments. encapsulation for unicast as the data-plane, such as SRH defined in
In an IPv6 network, however, there are considerations of using a non- [I-D.ietf-6man-segment-routing-header], where the function of a
MPLS encapsulation for unicast as the data-plane, such as SRH defined
in [I-D.ietf-6man-segment-routing-header], where the function of a
bypass tunnel uses an SRH header, with one or many Segments (or bypass tunnel uses an SRH header, with one or many Segments (or
SIDs), instead of MPLS Labels. SIDs), instead of MPLS Labels. In such case, it is expected to have
a BIER IPv6 encapsulation, which can run on IPv6 to be compliant with
various kind of physical link in hop-by-hop case, as well as on SRH
tunnel to have the significant benefit of "fast reroute" and so on.
3.2. Requirements 3.2. Requirements
This chapter lists the BIER IPv6 encapsulation requirements needed to This chapter lists the BIER IPv6 encapsulation requirements needed to
make the deployment of BIER on IPv6 network with SRH data-plane the make the deployment of BIER on IPv6 network with SRH data-plane the
same as on IPv4/IPv6 network with MPLS data-plane. These BIER IPv6 same as on IPv4/IPv6 network with MPLS data-plane. These BIER IPv6
encapsulation requirements should provide similar benefits to MPLS encapsulation requirements should provide similar benefits to MPLS
encapsulation such as "fast reroute" or "run on any link or encapsulation such as "fast reroute" or "run on any link or
interface". interface".
skipping to change at page 4, line 29 skipping to change at page 4, line 14
3. It SHOULD support BIER on an "SRH tunnel". 3. It SHOULD support BIER on an "SRH tunnel".
4. It SHOULD align with the recommendations of the 6MAN working 4. It SHOULD align with the recommendations of the 6MAN working
group. group.
4. IPv6 BIER Encapsulation 4. IPv6 BIER Encapsulation
4.1. Considerations 4.1. Considerations
BIER is generally a hop-by-hop and one-to-many architecture, while BIER is generally a hop-by-hop and one-to-many architecture, and thus
Segment Routing is a source-routing and one-to-one architecture. One the IPv6 Destination Address (DA) being a Multicast Address is a
of the challenges of an BIER IPv6 Encapsulation is how to allow BIER proper approach for both the two diagrams in BIER IPv6 encapsulation.
to run over a Segment Routing tunnel. A suitable method for such a It is also required for a BIER IPv6 encapsulation to include the BIER
combination is to use a Multicast Address as the Last Segment (or Header ([RFC8296]) as an IPv6 Extension Header, to pilot the hop-by-
SID). After all the source-routing hops have been processed, the hop BIER replication.
remaining Multicast Address becomes the IPv6 Destination Address. A
hop-by-hop replicating diagram begins by using the Destination
Multicast Address.
We then need to decide where to place the BIER header. According to According to [RFC8200], [RFC6564], and [RFC7045], a new defined IPv6
[RFC8200], [RFC6564], and [RFC7045], a suitable place for a well- extention header is not recommended, and an IPv6 Destination Option
known BIER header is an IPv6 Destination Option extension header. extension header is suitable and recommended for such a well-known
Such a Destination Option carrying BIER header is only used for a BIER header as its Option.
hop-by-hop Multicast Address destination, but not for the transit
router along the source-routing path.
4.2. IPv6 BIER Destination Option 4.2. IPv6 BIER Destination Option
The IPv6 BIER Destination Option is carried by the IPv6 Destination The IPv6 BIER Destination Option is carried by the IPv6 Destination
Option Header (indicated by a Next Header value 60). It is used in a Option Header (indicated by a Next Header value 60). It is
packet sent by an IPv6 BFIR router to inform the routers in an IPv6 initialized in a packet sent by an IPv6 BFIR router to inform the
BIER domain to replicate to destination BFER routers. following BFR routers in an IPv6 BIER domain to replicate to
destination BFER routers hop-by-hop.
The IPv6 BIER Destination Option is encoded in type-length-value The IPv6 BIER Destination Option is encoded in type-length-value
(TLV) format as follows: (TLV) format as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option Type | Option Length | | Next Header | Hdr Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 5, line 32 skipping to change at page 5, line 14
Hdr Ext Len 8-bit unsigned integer. Length of the Destination Hdr Ext Len 8-bit unsigned integer. Length of the Destination
Options header in 8-octet units, not including the first 8 octets. Options header in 8-octet units, not including the first 8 octets.
Option Type TBD. Need to be allocated by IANA. Option Type TBD. Need to be allocated by IANA.
Option Length 8-bit unsigned integer. Length of the option, in Option Length 8-bit unsigned integer. Length of the option, in
octets, excluding the Option Type and Option Length fields. octets, excluding the Option Type and Option Length fields.
Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296, Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296,
including the BIFT-id. including the BIFT-id. The function of TTL field is replaced by
the Hop Limit field in IPv6 header and MUST be set to a non-zero
value. The function of Entropy field is replaced by the Flow
Label field in IPv6 header and MUST be set to zero value.
4.3. The whole IPv6 header for BIER packets 4.3. The whole IPv6 header for BIER packets
[RFC8200] specifies that the Destination Option Header can be located [RFC8200] specifies that the Destination Option Header can be located
either before the Routing Header or after the Routing Header. either before the Routing Header or after the Routing Header.
However, this document requires that the Destination Option Header However, this document requires that the Destination Option Header
with a BIER Destination Option TLV is always located after the with a BIER Destination Option TLV is always located after the
Routing Header if the Routing Header is present. Routing Header if the Routing Header is present.
This is because the BIER header is always handled after the tunnels This is because the BIER header is always handled after the tunnels
skipping to change at page 6, line 21 skipping to change at page 6, line 5
field indicate that some IP routers deployed within the global field indicate that some IP routers deployed within the global
Internet are configured either to ignore the presence of headers with Internet are configured either to ignore the presence of headers with
hop-by-hop behavior or to drop packets containing headers with hop- hop-by-hop behavior or to drop packets containing headers with hop-
by-hop behavior." by-hop behavior."
Such IPv6 extension headers will even be more uncommon when a BIER Such IPv6 extension headers will even be more uncommon when a BIER
encapsulation is used in data-plane forwarding. The entire IPv6 encapsulation is used in data-plane forwarding. The entire IPv6
header, with BIER encapsulation and Routing Header, is expected to header, with BIER encapsulation and Routing Header, is expected to
look like this: look like this:
IPv6 header IPv6 header [Multicast Address in DA]
Hop-by-Hop Options header [Not Used] Hop-by-Hop Options header [No use]
Destination Options header [Not Used] Destination Options header [No use]
Routing header [SRH Header with Multicast Address as last SID] Routing header [SRH Header may be used, Appendix A]
Fragment header [Not Used] Fragment header [No use ]
Authentication header [Not Used] Authentication header [No use]
Encapsulating Security Payload header [Not Used] Encapsulating Security Payload header [No use]
Destination Options header [BIER header in BIER Option TLV] Destination Options header [BIER header in BIER Option TLV]
Upper-layer header [Data-plane Data] Upper-layer header [BIER payload]
Once a packet is encapsulated with a BIER Destination Option, it is
basically assumed to be a data-plane multicast packet, so the 'OAM'
or similar functions in the SRH Header Optional TLV Objects field
should not exist.
The last Segment (SID) in the SRH header, or Segment List[0], should In a hop-by-hop BIER IPv6 replication scenario, there is only an IPv6
be a Multicast Address to indicate a hop-by-hop behavior. Such a header with DA being a "BIER specific" Multicast address, and an IPv6
Multicast Address can be reserved or unreserved as the Destination Destination Option header with a BIER destination option TLV.
Option Header can inform the routers to do the address check. A
reserved multicast address should be indicating a 'BIER specific'
address.
BIER header has a 'proto' field to identify the type of BIER packet BIER header has a 'proto' field to identify the type of BIER packet
payload, and the IANA has created a registry called "BIER Next payload, and the IANA has created a registry called "BIER Next
Protocol Identifiers" to assign the value. That means the 'Upper- Protocol Identifiers" to assign the value. That means the 'Upper-
layer header' of a BIER packet have already been identified by the layer header' of a BIER packet have already been identified by the
'proto' field of the BIER header in the Destination Option Header. 'proto' field of the BIER header in the Destination Option Header.
Thus the 'Next Header' in the Destination Option Header is not need Thus the 'Next Header' in the Destination Option Header is not need
to identify the 'Upper-layer header' any more, and is recommended to to identify the 'Upper-layer header' any more, and is recommended to
be set to 'No Next Header (value 59)'. be set to 'No Next Header (value 59)'.
5. BIER Forwarding in Non-MPLS IPv6 Networks Procedures for encapsulating a BIER IPv6 packet in SRH tunnel are
outside the scope of this document.
Procedures for encapsulating a BIER IPv6 packet in other types of
tunnels are outside the scope of this document.
5. IPv6 BIER Forwarding
In an IPv6 BIER domain, the Multicast Address of the IPv6 DA in an
incoming BIER IPv6 packet indicates the BIER information of this
'host', and the packet will be forwarded according to the BIER Header
in the BIER Destination Option TLV in the IPv6 Destination Option
extension header. A router is required to ignore the IPv6 BIER
Destination Option if the IPv6 Destination Address of a packet is not
a multicast address, or is a multicast adddress without indicating
the BIER information of this 'host'.
Below is the procedure that a BFR uses for forwarding a BIER IPv6
encapsulated packet.
1. Read the IPv6 header, get the the IPv6 DA, and get the indication
of the multicast address if the IPv6 DA is a multicast address.
The case when IPv6 DA not being a multicast address is outside
the scope of this document.
2. If the multicast address is interested by this router, and the
'Next Header' of the IPv6 header indicates a IPv6 Destination
Option Header, then read the IPv6 Destination Option Header, and
get the BIER Option (BIER Header). The case when the multicast
address not being interested by this router is outside the scope
of this document.
3. The following steps are the same as step 1 to 9 described in
chapter 6.5 in [RFC8279]. One difference need to point out is
that, the copied packet includes a IPv6 header, a IPv6
Destination Header and its BIER Destination Option Type and
Option Length before the BIER Header. If the copied packet is
forwarded to a BFR-NBR, the 'Hop Limit' field of the IPv6 header
MUST be decremented, whereas the TTL in the BIER header MUST be
unchanged.
Procedures for forwarding a BIER IPv6 packet in SRH tunnel, and hand-
off to a hop-by-hop replication, can refer to Appendix A.
Procedures for forwarding a BIER IPv6 packet in other types of
tunnels, and hand-off to a hop-by-hop replication, are outside the
scope of this document.
6. Security Considerations
An IPv6 BIER Destination Option with Multicast Address Destination
would be used only when an IPv6 BIER state with the specific
Multicast Address Destination has been built by the control-plane.
Otherwise the packet with an IPv6 BIER Destination Option will be
discarded.
7. IANA Considerations
Allocation is expected from IANA for a BIER Destination Option Type
codepoint from the "Destination Options and Hop-by-Hop Options" sub-
registry of the "Internet Protocol Version 6 (IPv6) Parameters"
registry [RFC2780] at <https://www.iana.org/assignments/
ipv6-parameters/>.
Allocation is expected from IANA for a BIER Multicast Address from
the "Variable Scope Multicast Addresses" sub-registry of the "IPv6
Multicast Address Space Registry" registry at
<https://www.iana.org/assignments/ipv6-multicast-addresses/>.
8. Acknowledgements
TBD.
9. Appendix A - BIER over IPv6 SRH Tunnel
In a Non-MPLS IPv6 Network, BIER may be deployed in a hop-by-hop In a Non-MPLS IPv6 Network, BIER may be deployed in a hop-by-hop
manner, or possibly be deployed through an SRH tunnel either for manner, or possibly be deployed through an SRH tunnel either for
"bypassing Non-capable BIER routers" or "fast rerouting". Here is an "bypassing Non-capable BIER routers" or "fast rerouting". Here is an
example where a packet is firstly forwarded through an SRH tunnel and example where a packet is firstly forwarded through an SRH tunnel and
then through a hop-by-hop BIER domain. then through a hop-by-hop BIER domain.
When a router along the Segment Routing path receives an IPv6 BIER When a router along the Segment Routing path receives an IPv6 BIER
packet with an SRH header, and if the IPv6 destination address is not packet with an SRH header, and if the IPv6 destination address is not
one of the router's address, then the packet is forwarded by an IPv6 one of the router's address, then the packet is forwarded by an IPv6
skipping to change at page 8, line 18 skipping to change at page 9, line 22
In the following hop-by-hop forwarding procedure, the IPv6 In the following hop-by-hop forwarding procedure, the IPv6
Destination Address in an incoming packet indicates the BIER Destination Address in an incoming packet indicates the BIER
information of this 'host', and the packet will be forwarded information of this 'host', and the packet will be forwarded
according to the BIER Header in the BIER Destination Option TLV in according to the BIER Header in the BIER Destination Option TLV in
the IPv6 Destination Option extension header. A router is required the IPv6 Destination Option extension header. A router is required
to ignore the IPv6 BIER Destination Option if the IPv6 Destination to ignore the IPv6 BIER Destination Option if the IPv6 Destination
Address of a packet is not a multicast address, or is a multicast Address of a packet is not a multicast address, or is a multicast
adddress without indicating the BIER information of this 'host'. adddress without indicating the BIER information of this 'host'.
6. Security Considerations 10. References
An IPv6 BIER Destination Option with Multicast Address Destination
would be used only when an IPv6 BIER state with the specific
Multicast Address Destination has been built by the control-plane.
Otherwise the packet with an IPv6 BIER Destination Option will be
discarded.
7. IANA Considerations
Allocation is expected from IANA for a Destination Option Type
codepoint from the "Destination Options and Hop-by-Hop Options" sub-
registry of the "Internet Protocol Version 6 (IPv6) Parameters"
registry [RFC2780] at <https://www.iana.org/assignments/
ipv6-parameters/>.
8. Acknowledgements
TBD.
9. References
9.1. Normative References 10.1. Normative References
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Network Programming", draft-filsfils-spring-srv6-network-
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and programming-05 (work in progress), July 2018.
M. Sharif, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-04 (work in progress),
March 2018.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-13 (work in (SRH)", draft-ietf-6man-segment-routing-header-14 (work in
progress), May 2018. progress), June 2018.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012, RFC 6564, DOI 10.17487/RFC6564, April 2012,
<https://www.rfc-editor.org/info/rfc6564>. <https://www.rfc-editor.org/info/rfc6564>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013, DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>. <https://www.rfc-editor.org/info/rfc7045>.
skipping to change at page 9, line 38 skipping to change at page 10, line 17
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
9.2. Informative References 10.2. Informative References
[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>.
Authors' Addresses Authors' Addresses
Jingrong Xie Jingrong Xie
Huawei Technologies Huawei Technologies
 End of changes. 33 change blocks. 
121 lines changed or deleted 151 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/