< 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/