draft-ietf-bier-ipv6-requirements-07.txt   draft-ietf-bier-ipv6-requirements-08.txt 
Network Working Group M. McBride Network Working Group M. McBride
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Informational J. Xie Intended status: Informational J. Xie
Expires: March 20, 2021 X. Geng Expires: March 28, 2021 X. Geng
S. Dhanaraj S. Dhanaraj
Huawei Huawei
R. Asati R. Asati
Cisco Cisco
Y. Zhu Y. Zhu
China Telecom China Telecom
G. Mishra G. Mishra
Verizon Inc. Verizon Inc.
Z. Zhang Z. Zhang
Juniper Juniper
September 16, 2020 September 24, 2020
BIER IPv6 Requirements BIER IPv6 Requirements
draft-ietf-bier-ipv6-requirements-07 draft-ietf-bier-ipv6-requirements-08
Abstract Abstract
There have been several proposed solutions with BIER being used in There have been several proposed solutions with BIER being used in
IPv6. But there hasn't been a document which describes the problem IPv6. But there hasn't been a document which describes the problem
and lists the requirements. The goal of this document is to describe and lists the requirements. The goal of this document is to describe
the general BIER IPv6 encapsulation problem, summarize the the general BIER IPv6 encapsulation problem, summarize the
encapsulation modes of the proposed solutions, detail solution encapsulation modes of the proposed solutions, detail solution
requirements, and assist the working group in the development of requirements, and assist the working group in the development of
acceptable solutions. acceptable solutions.
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 March 20, 2021. This Internet-Draft will expire on March 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
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
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. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Independent Model . . . . . . . . . . . . . . . . . . . . 4 3.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 4
3.2. Integrated Model . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Support various L2 link types . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Support BIER architecture . . . . . . . . . . . . . . 4
4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 6 3.1.3. Support deployment with Non-BFR routers . . . . . . . 5
4.1.1. Support various L2 link types . . . . . . . . . . . . 6 3.1.4. Support OAM . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Support BIER architecture . . . . . . . . . . . . . . 6 3.2. Optional Requirements . . . . . . . . . . . . . . . . . . 5
4.1.3. Support deployment with Non-BFR routers . . . . . . . 6 3.2.1. Support Fragmentation . . . . . . . . . . . . . . . . 5
4.1.4. Support OAM . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. Support IPSEC ESP . . . . . . . . . . . . . . . . . . 5
4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Support Fragmentation . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4.2.2. Support IPSEC ESP . . . . . . . . . . . . . . . . . . 7 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 Appendix A. Conceptual Models For BIER IPv6 Encapsulation and
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 Forwarding . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 A.1. Independent Model . . . . . . . . . . . . . . . . . . . . 7
Appendix A. List of Solutions . . . . . . . . . . . . . . . . . 9 A.2. Integrated Model . . . . . . . . . . . . . . . . . . . . 8
A.1. Integrated mode approach . . . . . . . . . . . . . . . . 9 Appendix B. List of Solutions . . . . . . . . . . . . . . . . . 9
A.2. Independent model approach . . . . . . . . . . . . . . . 10 B.1. Integrated mode approach . . . . . . . . . . . . . . . . 9
B.2. Independent model approach . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
encapsulation: one is BIER MPLS encapsulation for MPLS environments, encapsulation: one is BIER MPLS encapsulation for MPLS environments,
the other is non-MPLS BIER encapsulation to run without MPLS. This the other is non-MPLS BIER encapsulation to run without MPLS. This
skipping to change at page 4, line 13 skipping to change at page 4, line 16
to BFERs across an IPv6 Service Provider core. Inside the IPv6 to BFERs across an IPv6 Service Provider core. Inside the IPv6
network, the BIER header is used to direct the packet from one BFR to network, the BIER header is used to direct the packet from one BFR to
the next BFRs, and either a IPv6 header or an L2/tunnel header is the next BFRs, and either a IPv6 header or an L2/tunnel header is
used to provide reachability between BFRs. The IPv6 environment may used to provide reachability between BFRs. The IPv6 environment may
include a variety of link types, may be entirely IPv6, or may be dual include a variety of link types, may be entirely IPv6, or may be dual
stack. There may be cases where not all routers are BFR capable in stack. There may be cases where not all routers are BFR capable in
the IPv6 environment but still want to deploy BIER. Regardless of the IPv6 environment but still want to deploy BIER. Regardless of
the environment, the problem is to deploy BIER, with non-MPLS BIER the environment, the problem is to deploy BIER, with non-MPLS BIER
encapsulation, in an IPv6 network. encapsulation, in an IPv6 network.
3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 3. Requirements
This analysis introduces two conceptual models for BIER in IPv6
networks based on the experience and solutions discussed in the IETF
community.
3.1. Independent Model
The first conceptual model is an Independent Model, where IPv6 is
nothing special to BIER but a transportation means that may be used
just like other transportation means, and BIER is nothing special to
IPv6 but a payload type just like other payload types.
|<<-----(BIER-based multicast overlay)----->>|
| |
|<---------(L2.5 BIER(P2MP) Tunnel)--------->|
| |
| TEP TEP TEP TEP |
| +~~~~~~~~~~~~~~~~~~+ +BIER+ |
| / \ / \ |
+------+ +-------+ +-----+ or +------+
| BFIR |-------|Non-BFR|-------| BFR |--BIER--| BFER |
+------+ +-------+ +-----+ +------+
------- L2 link
~~~~~~~ IPv6(P2P) tunnel (TEP = Tunnel EndPoint)
<-----> BIER(P2MP) tunnel
In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER
works as a layer-2.5 over tunnels or L2 links. Between two BFRs,
either a L2 link can be used directly or any tunnel (IPv6 or not) can
be used for BIER transport. In the tunnel case, the transmitting BFR
adds tunnel encapsulation (e.g. IPv6 header) and the receiving BFR
removes the tunnel encapsulation.
General consideration of this model is to keep BIER and IPv6
independent of each other. The BIER header is not part of the IPv6
header but comes after the transport header (L2 or tunnel header) and
before BIER payload.
3.2. Integrated Model
The second conceptual model is an Integrated Model that integrates
BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
approach.
|<<-----(BIER-based multicast overlay)----->>|
| |
|<----------(L3 BIER(P2MP) tunnel)---------->|
| |
| SEP SEP SEP SEP |
| +~~~~~~~~~~~~~~~~~~+ +~~~~+ |
| / \ / \ |
+------+ +-------+ +-----+ +------+
| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
+------+ +-------+ +-----+ +------+
------- L2 link
~~~~~~~ IPv6(P2P) segment (SEP = Segment EndPoint)
<-----> BIER(P2MP) tunnel
In this model, BIER works as part of the IPv6 data plane. The BFIR
and BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
segment endpoints. The BIER header is processed on each segment
endpoint and there is no decapsulation, or re-encapsulation, on the
segment endpoints.
This model typically needs an IPv6 extension header to carry the BIER
header. and processing of the BIER header (e.g., the BitString) will
be implemented as part of the IPv6 extension header processing. The
IPv6 source address is the BIER packet source-origin identifier, and
is unchanged through the BIER domain from BFIR to BFERs.
General consideration of this model is to use the IPv6 capabilities
integrated, in addition to normal BIER function, to facilitate new
requirements that may emerge in an IPv6 network.
4. Requirements
There are several suggested requirements for BIER IPv6 solutions. There are several suggested requirements for BIER IPv6 solutions.
In this document, the requirements are divided into two levels: In this document, the requirements are divided into two levels:
Mandatory and Optional. The requirement levels are determined based Mandatory and Optional. The requirement levels are determined based
on the following factors: on the following factors:
If the requirement is required for a feature that is likely to be If the requirement is required for a feature that is likely to be
a potential deployment, the requirement level will be considered a potential deployment, the requirement level will be considered
mandatory. mandatory.
If the impact of not implementing the requirement may block BIER If the impact of not implementing the requirement may block BIER
from been deployed, the requirement level will be considered from been deployed, the requirement level will be considered
mandatory. mandatory.
4.1. Mandatory Requirements 3.1. Mandatory Requirements
Considering that these mandatory requirements are all well-known to Considering that these mandatory requirements are all well-known to
the working group, and practical in normal deployment, they will be the working group, and practical in normal deployment, they will be
listed without a detailed description. listed without a detailed description.
4.1.1. Support various L2 link types 3.1.1. Support various L2 link types
The solution should support various kinds of L2 data link types. The solution should support various kinds of L2 data link types.
4.1.2. Support BIER architecture 3.1.2. Support BIER architecture
The solution must support the BIER architecture. The solution must support the BIER architecture.
Supporting different multicast flow overlays, multiple sub-domains, Supporting different multicast flow overlays, multiple sub-domains,
multi-topologies, multiple sets, multiple Bit String Lengths, and multi-topologies, multiple sets, multiple Bit String Lengths, and
deterministic ECMP are considered essential functions of BIER and deterministic ECMP are considered essential functions of BIER and
need to be supported. need to be supported.
4.1.3. Support deployment with Non-BFR routers 3.1.3. Support deployment with Non-BFR routers
The solution must support deployments with BIER-incapable routers. The solution must support deployments with BIER-incapable routers.
This is beneficial to the deployment of BIER, especially in early This is beneficial to the deployment of BIER, especially in early
deployments when some routers do not support BIER forwarding but deployments when some routers do not support BIER forwarding but
support IPv6 forwarding. support IPv6 forwarding.
4.1.4. Support OAM 3.1.4. Support OAM
BIER OAM should be supported, either directly using existing methods, BIER OAM should be supported, either directly using existing methods,
or by specifying a new method for the same functionality. It may be or by specifying a new method for the same functionality. It may be
considered essential as part of the BIER architecture in some cases. considered essential as part of the BIER architecture in some cases.
4.2. Optional Requirements 3.2. Optional Requirements
The requirements in this section are listed as optional, and each The requirements in this section are listed as optional, and each
requirement is explained with a detailed scenario. Note that requirement is explained with a detailed scenario. Note that
fragmentation and IPSEC ESP are not BIER functions, they are provided fragmentation and IPSEC ESP are not BIER functions, they are provided
by the upper IP layer. by the upper IP layer.
4.2.1. Support Fragmentation 3.2.1. Support Fragmentation
There are some cases where the Fragmentation/Assembly function is There are some cases where the Fragmentation/Assembly function is
needed for BIER to work in an IPv6 network. needed for BIER to work in an IPv6 network.
For example, a customer IPv6 multicast packet may be 1280 bytes and For example, a customer IPv6 multicast packet may be 1280 bytes and
is required to be transported through an IPv6 network using BIER. is required to be transported through an IPv6 network using BIER.
Every link of the IPv6 network is no less than the requisite 1280 Every link of the IPv6 network is no less than the requisite 1280
bytes [RFC8200], but the size of the payload that can be encapsulated bytes [RFC8200], but the size of the payload that can be encapsulated
in BIER (BIER-MTU) is less than 1280 bytes. In this case, it is not in BIER (BIER-MTU) is less than 1280 bytes. In this case, it is not
the appropriate action for a BFIR to drop the packet and advertise an the appropriate action for a BFIR to drop the packet and advertise an
MTU to the source [RFC8296]. Instead, the IPv6 transport mechanism, MTU to the source [RFC8296]. Instead, the IPv6 transport mechanism,
either integrated with or independent to BIER, need to provide the either integrated with or independent to BIER, need to provide the
fragmentation and assembly function. fragmentation and assembly function.
4.2.2. Support IPSEC ESP 3.2.2. Support IPSEC ESP
There are some cases where the IPSEC ESP function may be needed to There are some cases where the IPSEC ESP function may be needed to
transport c-multicast packets through an IPv6 network with transport c-multicast packets through an IPv6 network with
confidentiality using BIER technology. confidentiality using BIER technology.
A service provider may want to provide additional security SLA to its A service provider may want to provide additional security SLA to its
customer to ensure that the unencrypted c-multicast packet is not customer to ensure that the unencrypted c-multicast packet is not
altered in the service provider's network. In this case, if the BIER altered in the service provider's network. In this case, if the BIER
technology is preferred for the multicast service, BIER with IPSEC technology is preferred for the multicast service, BIER with IPSEC
ESP support may be a candidate solution. On the other hand, the ESP support may be a candidate solution. On the other hand, the
traffic protection may be better provided via IPSEC or MACSEC at traffic protection may be better provided via IPSEC or MACSEC at
multicast flow overlay over and beyond the BIER domain. multicast flow overlay over and beyond the BIER domain.
5. IANA Considerations 4. IANA Considerations
Some BIER IPv6 encapsulation proposals do not require any action from Some BIER IPv6 encapsulation proposals do not require any action from
IANA while other proposals require new IPv6 Option codepoints from IANA while other proposals require new IPv6 Option codepoints from
IPv6 sub-registries, new "Next header" values, or require new IP IPv6 sub-registries, new "Next header" values, or require new IP
Protocol codes. This document, however, does not require anything Protocol codes. This document, however, does not require anything
from IANA. from IANA.
6. Security Considerations 5. Security Considerations
There are no security issues introduced by this draft. There are no security issues introduced by this draft.
7. Acknowledgement 6. Acknowledgement
Thanks to Eric Rosen for his listed set of initial requirements on Thanks to Eric Rosen for his listed set of initial requirements on
the BIER WG mailing list. the BIER WG mailing list.
8. Normative References 7. Normative References
[I-D.pfister-bier-over-ipv6] [I-D.pfister-bier-over-ipv6]
Pfister, P. and I. Wijnands, "An IPv6 based BIER Pfister, P. and I. Wijnands, "An IPv6 based BIER
Encapsulation and Encoding", draft-pfister-bier-over- Encapsulation and Encoding", draft-pfister-bier-over-
ipv6-01 (work in progress), October 2016. ipv6-01 (work in progress), October 2016.
[I-D.xie-bier-ipv6-encapsulation] [I-D.xie-bier-ipv6-encapsulation]
Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,
"Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-
skipping to change at page 9, line 11 skipping to change at page 7, line 22
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>.
Appendix A. List of Solutions Appendix A. Conceptual Models For BIER IPv6 Encapsulation and
Forwarding
This analysis introduces two conceptual models for BIER in IPv6
networks based on the experience and solutions discussed in the IETF
community.
A.1. Independent Model
The first conceptual model is an Independent Model, where IPv6 is
nothing special to BIER but a transportation means that may be used
just like other transportation means, and BIER is nothing special to
IPv6 but a payload type just like other payload types.
|<<-----(BIER-based multicast overlay)----->>|
| |
|<---------(L2.5 BIER(P2MP) Tunnel)--------->|
| |
| TEP TEP TEP TEP |
| +~~~~~~~~~~~~~~~~~~+ +BIER+ |
| / \ / \ |
+------+ +-------+ +-----+ or +------+
| BFIR |-------|Non-BFR|-------| BFR |--BIER--| BFER |
+------+ +-------+ +-----+ +------+
------- L2 link
~~~~~~~ IPv6(P2P) tunnel (TEP = Tunnel EndPoint)
<-----> BIER(P2MP) tunnel
In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER
works as a layer-2.5 over tunnels or L2 links. Between two BFRs,
either a L2 link can be used directly or any tunnel (IPv6 or not) can
be used for BIER transport. In the tunnel case, the transmitting BFR
adds tunnel encapsulation (e.g. IPv6 header) and the receiving BFR
removes the tunnel encapsulation.
General consideration of this model is to keep BIER and IPv6
independent of each other. The BIER header is not part of the IPv6
header but comes after the transport header (L2 or tunnel header) and
before BIER payload.
A.2. Integrated Model
The second conceptual model is an Integrated Model that integrates
BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
approach.
|<<-----(BIER-based multicast overlay)----->>|
| |
|<----------(L3 BIER(P2MP) tunnel)---------->|
| |
| SEP SEP SEP SEP |
| +~~~~~~~~~~~~~~~~~~+ +~~~~+ |
| / \ / \ |
+------+ +-------+ +-----+ +------+
| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
+------+ +-------+ +-----+ +------+
------- L2 link
~~~~~~~ IPv6(P2P) segment (SEP = Segment EndPoint)
<-----> BIER(P2MP) tunnel
In this model, BIER works as part of the IPv6 data plane. The BFIR
and BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
segment endpoints. The BIER header is processed on each segment
endpoint and there is no decapsulation, or re-encapsulation, on the
segment endpoints.
This model typically needs an IPv6 extension header to carry the BIER
header. and processing of the BIER header (e.g., the BitString) will
be implemented as part of the IPv6 extension header processing. The
IPv6 source address is the BIER packet source-origin identifier, and
is unchanged through the BIER domain from BFIR to BFERs.
General consideration of this model is to use the IPv6 capabilities
integrated, in addition to normal BIER function, to facilitate new
requirements that may emerge in an IPv6 network.
Appendix B. List of Solutions
There have been some proposed solutions for BIER in IPv6 There have been some proposed solutions for BIER in IPv6
environments. Some solutions propose encoding while others propose environments. Some solutions propose encoding while others propose
encapsulation. It is recommended for the wg to evaluate these encapsulation. It is recommended for the wg to evaluate these
solutions, against the requirements listed previously, in order to solutions, against the requirements listed previously, in order to
make informed decisions on solution readiness. make informed decisions on solution readiness.
This section lists these solutions categorizing in the two conceptual This section lists these solutions categorizing in the two conceptual
models. models.
A.1. Integrated mode approach B.1. Integrated mode approach
One example of this model is defined in [I-D.pfister-bier-over-ipv6], One example of this model is defined in [I-D.pfister-bier-over-ipv6],
where the information required for BIER forwarding, e.g., the where the information required for BIER forwarding, e.g., the
BitString, is encoded in the low-order bits of the IPv6 destination BitString, is encoded in the low-order bits of the IPv6 destination
address of each packet. The high-order bits of the IPv6 destination address of each packet. The high-order bits of the IPv6 destination
address are used by intermediate routers for unicast forwarding, address are used by intermediate routers for unicast forwarding,
deciding whether a packet is a BIER packet, and if so, to identify deciding whether a packet is a BIER packet, and if so, to identify
the BIER Sub-Domain, Set Identifier and BitString length. The BIER the BIER Sub-Domain, Set Identifier and BitString length. The BIER
function is integrated in the IPv6 header and its forwarding function is integrated in the IPv6 header and its forwarding
procedure, and the BIER payload is encapsulated as the IPv6 payload. procedure, and the BIER payload is encapsulated as the IPv6 payload.
skipping to change at page 10, line 12 skipping to change at page 10, line 12
its forwarding procedure, and the BIER payload is encapsulated as the its forwarding procedure, and the BIER payload is encapsulated as the
IPv6 payload. IPv6 payload.
+---------------+-----------------+------------------- +---------------+-----------------+-------------------
| IPv6 header | IPv6 Ext header | payload | IPv6 header | IPv6 Ext header | payload
| | (BIER header in | | | (BIER header in |
| | TLV Type = X) | | | TLV Type = X) |
| Next Header | Next Header | | Next Header | Next Header |
+---------------+-----------------+------------------- +---------------+-----------------+-------------------
A.2. Independent model approach B.2. Independent model approach
One example of this model is defined in [I-D.zhang-bier-bierin6], One example of this model is defined in [I-D.zhang-bier-bierin6],
where the BIER header and the payload following it are L2 payload where the BIER header and the payload following it are L2 payload
when feasible (e.g. when two BFRs are directly connected) or IPv6 when feasible (e.g. when two BFRs are directly connected) or IPv6
payload when IPv6 transport is needed/desired (e.g. when two BFRs are payload when IPv6 transport is needed/desired (e.g. when two BFRs are
not directly connected). This is indicated by either a 0xAB37 not directly connected). This is indicated by either a 0xAB37
Ethertype allocated to BIER or a new IPv6 Next-Header value to be Ethertype allocated to BIER or a new IPv6 Next-Header value to be
allocated by IANA. allocated by IANA.
+---------------+-----------------+------------------- +---------------+-----------------+-------------------
 End of changes. 21 change blocks. 
119 lines changed or deleted 121 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/