< draft-ietf-bier-ipv6-requirements-06.txt		draft-ietf-bier-ipv6-requirements-07.txt >
	Network Working Group M. McBride		Network Working Group M. McBride
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Standards Track J. Xie		Intended status: Informational J. Xie
	Expires: January 29, 2021 S. Dhanaraj		Expires: March 20, 2021 X. Geng
			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.
	July 28, 2020		Z. Zhang
			Juniper
			September 16, 2020
	BIER IPv6 Requirements		BIER IPv6 Requirements
	draft-ietf-bier-ipv6-requirements-06		draft-ietf-bier-ipv6-requirements-07
	Abstract		Abstract
	The BIER WG charter includes work on developing "a mechanism to use		There have been several proposed solutions with BIER being used in
	BIER natively in IPv6". There have been several proposed solutions		IPv6. But there hasn't been a document which describes the problem
	in this area. But there hasn't been a document which describes the		and lists the requirements. The goal of this document is to describe
	problem and lists the requirements. The goal of this document is to		the general BIER IPv6 encapsulation problem, summarize the
	describe the BIER IPv6 requirements, summarize the encapsulation		encapsulation modes of the proposed solutions, detail solution
	modes of the proposed solutions, guide the working group in		requirements, and assist the working group in the development of
	understanding the benefits and drawbacks of the various solutions,		acceptable solutions.
	and help in the development of acceptable solutions.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 29, 2021.		This Internet-Draft will expire on March 20, 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		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. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 4
	3.1. Transport-Independent Model . . . . . . . . . . . . . . . 5		3.1. Independent Model . . . . . . . . . . . . . . . . . . . . 4
	3.2. Native IPv6 Model . . . . . . . . . . . . . . . . . . . . 6		3.2. Integrated Model . . . . . . . . . . . . . . . . . . . . 5
	3.3. Encapsulation Approaches Considered . . . . . . . . . . . 7		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 6
	4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 8		4.1.1. Support various L2 link types . . . . . . . . . . . . 6
	4.1.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . 8		4.1.2. Support BIER architecture . . . . . . . . . . . . . . 6
	4.1.2. Support BIER architecture . . . . . . . . . . . . . . 8		4.1.3. Support deployment with Non-BFR routers . . . . . . . 6
	4.1.3. Conform to existing IPv6 Spec . . . . . . . . . . . . 8		4.1.4. Support OAM . . . . . . . . . . . . . . . . . . . . . 6
	4.1.4. Support deployment with Non-BFR routers . . . . . . . 8		4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 7
	4.1.5. Support inter-AS multicast deployment . . . . . . . . 8		4.2.1. Support Fragmentation . . . . . . . . . . . . . . . . 7
	4.1.6. Support Simple Encapsulation . . . . . . . . . . . . 9		4.2.2. Support IPSEC ESP . . . . . . . . . . . . . . . . . . 7
	4.1.7. Support Deployment Security . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	4.2.1. Support MVPN . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2.2. Support OAM . . . . . . . . . . . . . . . . . . . . . 9		8. Normative References . . . . . . . . . . . . . . . . . . . . 8
	4.2.3. Support IPSEC . . . . . . . . . . . . . . . . . . . . 9		Appendix A. List of Solutions . . . . . . . . . . . . . . . . . 9
	4.2.4. Support Fragmentation . . . . . . . . . . . . . . . . 9		A.1. Integrated mode approach . . . . . . . . . . . . . . . . 9
	4.2.5. Support hardware fast path . . . . . . . . . . . . . 10		A.2. Independent model approach . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Normative References . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 12
	A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 12
	A.2. Encode Bitstring in IPv6 destination address . . . . . . 13
	A.3. Add BIER header into IPv6 Extension Header . . . . . . . 13
	A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 14
	A.5. Tunnelling BIER in a IPv6 tunnel . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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 to run on physical links: one is BIER MPLS		encapsulation: one is BIER MPLS encapsulation for MPLS environments,
	encapsulation to run on various physical links that support MPLS, the		the other is non-MPLS BIER encapsulation to run without MPLS. This
	other is non-MPLS BIER Ethernet encapsulation to run on ethernet		document describes non-MPLS BIER encapsulation in IPv6 environments.
	links, with an ethertype 0xAB37. This document describes using BIER		We explain the requirements of transporting IPv4/IPv6 multicast
	in non-MPLS IPv6 environments. We explain the requirements of		overlay payload through an IPv6 network underlay using BIER. The
	transporting IPv4/IPv6 multicast payloads through an IPv6 network		solutions may require the use of IPv6 forwarding plane and may
	using "BIER natively in IPv6". As clarified in the working-group,		include IPv6 encapsulation and/or generic IPv6 tunnelling.
	"BIER natively in IPv6" means BIER not encapsulated in MPLS or
	Ethernet. This may include native IPv6 encapsulation and generic
	IPv6 tunnelling. The goal of this document is to help the BIER WG
	evaluate the BIER v6 requirements and solutions in order to begin
	adopting solution drafts.
	1.1. Requirements Language		1.1. 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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	1.2. Terminology		1.2. Terminology
	o BIER: Bit Index Explicit Replication. Provides optimal multicast		o BIER: Bit Index Explicit Replication. Provides optimal multicast
	forwarding through adding a BIER header and removing state in		forwarding through adding a BIER header and removing state in
	intermediate routers.		intermediate routers.
	o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe
	the three types of Ethernet modes that will be forwarded to
	multiple destinations
	2. Problem Statement		2. Problem Statement
	The problem is the ability of the network to transport BUM packets,		The problem is how to transport multicast packets, with non-MPLS BIER
	with BIER headers, in an IPv6 environment. In many IPv6 network		encapsulation, in an IPv6 environment. We need to determine where to
	deployments, non-MPLS encapsulation is used for unicast as the data-		put the BIER header in this IPv6 environment. With IPv6
	plane. It is likewise expected to have BIER IPv6 deployments which		encapsulation being increasingly used for unicast services, such as
	depend on these same unicast technologies to traverse through non-BFR		VPN or L2VPN, it may be desirable to have IPv6 encapsulation also
	routers.		used in BIER deployments for multicast services such as MVPN. It may
			also be desirable to not use IPv6 encapsulation except when IPv6
	One such case involves supporting a non-BFR router in a network as		tunneling (native or GRE/UDP-like) is used to transport BIER packets
	described in section 6.9 of RFC8279. In the context of this		over BIER-incapable routers.
	document, an IPv6 based unicast tunnel is needed to support such
	deployment where a non-BFR exists. Another case is to support inter-
	AS multicast deployment as illustrated in
	[I-D.geng-bier-ipv6-inter-domain]. In such deployment, there are
	non-BFR routers, or even an entire non-BIER network, that needs the
	ability to traverse from one BFR to another.
	[I-D.ietf-bier-use-cases] shows it is possible there are other cases
	where inter-AS multicast deployment is required.
	As with IPv6, another problem of BIER IPv6 technology may be
	"Transition Mechanisms and Partial Deployments" which is listed as
	the No.1 charter item of BIER WG. Therefore, a basic requirement of
	BIER IPv6 is to leverage IPv6 reachability for incremental and inter-
	AS BIER deployment.
	Below is a simple scenario that needs BIER IPv6 encapsulation and		Below is a simple scenario that needs BIER IPv6-based forwarding:
	forwarding:
	+--------------------------------------------+		+--------------------------------------------+
	| |		| |
	| +------+		| +------+
	| | BFER |		| | BFER |
	+------+ +-------+ +-----+ +------+		+------+ +-------+ +-----+ +------+
	| BFIR | |Non-BFR| | BFR | |		| BFIR | |Non-BFR| | BFR | |
	+------+ +-------+ +-----+ +------+		+------+ +-------+ +-----+ +------+
	| | BFER |		| | BFER |
	| IPv6 Network +------+		| IPv6 Network +------+
	| (intra-AS or inter-AS) |		| |
	+--------------------------------------------+		+--------------------------------------------+
	This scenario depicts the need to replicate bier packets from a BFIR		This scenario depicts the need to replicate BIER packets from a BFIR
	to BFERs across an IPv6 core. The IPv6 environment may include a		to BFERs across an IPv6 Service Provider core. Inside the IPv6
	variety of link types, may be entirely IPv6, may be dual stack or any		network, the BIER header is used to direct the packet from one BFR to
	type of combination which includes IPv6. Regardless of the		the next BFRs, and either a IPv6 header or an L2/tunnel header is
	environment, there are times when a BIER header, including the BIER		used to provide reachability between BFRs. The IPv6 environment may
	BitString used to determine the set of BIER forwarding egress		include a variety of link types, may be entirely IPv6, or may be dual
	routers, will need to traverse a IPv6 domain. The ways in which BIER		stack. There may be cases where not all routers are BFR capable in
	will function in an IPv6 environment is the problem that needs to be		the IPv6 environment but still want to deploy BIER. Regardless of
	solved.		the environment, the problem is to deploy BIER, with non-MPLS BIER
			encapsulation, in an IPv6 network.
	3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding		3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding
	This analysis introduces two conceptual models for BIER IPv6		This analysis introduces two conceptual models for BIER in IPv6
	encapsulation and forwarding based on the experience and examples		networks based on the experience and solutions discussed in the IETF
	that have been seen in the IETF community.		community.
	3.1. Transport-Independent Model		3.1. Independent Model
	The first conceptual model is a Transport-Independent Model that		The first conceptual model is an Independent Model, where IPv6 is
	views IP tunnels as links of BIER, and views BIER as an independent		nothing special to BIER but a transportation means that may be used
	"Layer-2.5".		just like other transportation means, and BIER is nothing special to
			IPv6 but a payload type just like other payload types.
	|<----------(L2.5 BIER(P2MP) Tunnel)-------->|		|<<-----(BIER-based multicast overlay)----->>|
	| |		| |
	| +~~~~~~~~~~~~~~~~~~+ +~~~~+ |		|<---------(L2.5 BIER(P2MP) Tunnel)--------->|
			| |
			| TEP TEP TEP TEP |
			| +~~~~~~~~~~~~~~~~~~+ +BIER+ |
	| / \ / \ |		| / \ / \ |
			+------+ +-------+ +-----+ or +------+
			| BFIR |-------|Non-BFR|-------| BFR |--BIER--| BFER |
	+------+ +-------+ +-----+ +------+		+------+ +-------+ +-----+ +------+
	| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |		------- L2 link
	+------+ +-------+ +-----+ +------+
	------- physical link
	~~~~~~~ IPv6(P2P) tunnel		~~~~~~~ IPv6(P2P) tunnel (TEP = Tunnel EndPoint)
	<-----> BIER(P2MP) tunnel		<-----> BIER(P2MP) tunnel
	In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER		In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER
	works as a transport-independent layer (or layer-2.5) over a virtual-		works as a layer-2.5 over tunnels or L2 links. Between two BFRs,
	link (IPv6 tunnel). On each BFR, the IPv6 tunnel of the receiving		either a L2 link can be used directly or any tunnel (IPv6 or not) can
	packet is decapsulated, and a new IPv6 tunnel is encapsulated before		be used for BIER transport. In the tunnel case, the transmitting BFR
	sending the packet to the next-hop BFR neighbour.		adds tunnel encapsulation (e.g. IPv6 header) and the receiving BFR
			removes the tunnel encapsulation.
	From the view of the IPv6 layer, the BIER header is a kind of Upper-
	layer header (Layer-4). From the view of the BIER layer, the IPv6
	encapsulation is a tunnel working as a "link" of BIER. With an End-
	to-End view, the tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP)
	tunnel, and the BFIR-id is the BIER packet source-origin identifier,
	and is unchanged through the BIER domain from BFIR to BFERs.
	This model is similar to the "MPLS over IP" [RFC4023] or "MPLS over
	UDP" [RFC7510] approach. A more general output of such approach in
	IETF is "MPLS Segment Routing over IP" [RFC8663]. It makes use of
	IPv4/IPv6 tunnel, IPv4/IPv6 UDP tunnel and IPv4/IPv6 GRE tunnel to
	encapsulate the MPLS-based instructions. In fact, BIER-MPLS could
	use this approach directly since BIER-MPLS is based on MPLS.
	There may be, however, in certain cases some difficulty with
	allocation of an MPLS label and advertisement through the control-
	plane. For example, a simple inter-AS BIER deployment may want to
	use the auto-configuration of BIFT-id using Non-MPLS BIER
	encapsulation [RFC8296] as illustrated in
	[I-D.geng-bier-ipv6-inter-domain]. This brings the need of a new
	"Next Header" value to indicate the "Non-MPLS" BIER header.
	For IPv4/IPv6 GRE, the "Next Header" is the 16-bit "Protocol Type"
	field, and has adequate space for such requirement.
	For IPv4/IPv6 UDP, the "Next Header" is the 16-bit "Destination Port"
	field, and has adequate space for such requirement.
	For IPv4/IPv6, the "Next Header" is a 8-bit value and needs to be
	allocated from the "Assigned Internet Protocol Numbers" registry.
	Reassembly/Re-fragmentation of a packet has to be executed on each
	BFR in such case. This may be common and even friendly for a
	protocol stack in a BFR software implementation, but it may impose
	cost for a BFR hardware implementation.
	IPv6 functions that are expected to be executed from BFIR to BFER are
	assumed to be broken on the BFRs, for example, IPv6 Fragmentation/
	Assembly or IPSEC ESP. This is because the "IPv6 tunnel" and all its
	functions is "terminated" on the BFRs. These functions, if desired,
	may need to be re-designed in the "Layer-2.5" BIER mode.
	For deployment security, it is necessary to ensure the "BIER" packet		General consideration of this model is to keep BIER and IPv6
	is only using the allowed IPv6 tunnel.		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. Native IPv6 Model		3.2. Integrated Model
	The second conceptual model is a Native IPv6 Model that integrates		The second conceptual model is an Integrated Model that integrates
	BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"		BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
	approach.		approach.
	|<----------(L3 BIER(P2MP) tunnel)--------->|		|<<-----(BIER-based multicast overlay)----->>|
	| |		| |
			|<----------(L3 BIER(P2MP) tunnel)---------->|
			| |
			| SEP SEP SEP SEP |
			| +~~~~~~~~~~~~~~~~~~+ +~~~~+ |
			| / \ / \ |
	+------+ +-------+ +-----+ +------+		+------+ +-------+ +-----+ +------+
	| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |		| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
	+------+ +-------+ +-----+ +------+		+------+ +-------+ +-----+ +------+
	------- physical link		------- L2 link
			~~~~~~~ IPv6(P2P) segment (SEP = Segment EndPoint)
	<-----> BIER(P2MP) tunnel		<-----> BIER(P2MP) tunnel
	In this model, BIER works as part of the IPv6 data plane. BFIR and		In this model, BIER works as part of the IPv6 data plane. The BFIR
	BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6		and BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
	segment endpoints. On each BFR, the segment endpoint behaviour of		segment endpoints. The BIER header is processed on each segment
	IPv6 data plane is executed, and there is no decapsulation of		endpoint and there is no decapsulation, or re-encapsulation, on the
	receiving IPv6 tunnel and encapsulation of new IPv6 tunnel for		segment endpoints.
	sending.
	In this mode, the BIER header is integrated into the IPv6 extension		This model typically needs an IPv6 extension header to carry the BIER
	header and processing of the BIER header (e.g., the BitString) is		header. and processing of the BIER header (e.g., the BitString) will
	implemented as part of the IPv6 extension header processing. The		be implemented as part of the IPv6 extension header processing. The
	IPv6 source address is the BIER packet source-origin identifier, and		IPv6 source address is the BIER packet source-origin identifier, and
	is unchanged through the BIER domain from BFIR to BFERs.		is unchanged through the BIER domain from BFIR to BFERs.
	This model is similar to many examples emerging in the IETF community		General consideration of this model is to use the IPv6 capabilities
	which soley use the IPv6 data plane. SRv6 introduced in [RFC8754]		integrated, in addition to normal BIER function, to facilitate new
	and [I-D.ietf-spring-srv6-network-programming] is an example. The		requirements that may emerge in an IPv6 network.
	benefits of such approach includes reducing the number of
	encapsulation layers, capability of deployment with non-capable
	routers in a network, extending the technology in a wider inter-AS
	scope using IP reachability, and capability of integrating the
	functions of the IPv6 data plane.
	This model typically needs an extension to IPv6 data plane, with an
	IPv6 extension header or Option introduced.
	IPv6 functions that are expected to be executed from BFIR to BFER is
	supported if correctly designed, for example, IPv6 Fragmentation/
	Assembly or IPSEC ESP.
	For deployment security, it is necessary to ensure the "BIER" packet
	is in a trusted IPv6-based domain.
	3.3. Encapsulation Approaches Considered
	A number of approaches to the design of BIER-IPv6 encapsulation were
	investigated by the BIER Working Group and were discussed in IETF
	meetings and on the BIER list. This section divides these approaches
	into the two conceptual models.
	Transport-Independent Model approaches include:
	Transport-Independent BIER [I-D.xu-bier-encapsulation].
	BIERin6 [I-D.zhang-bier-bierin6].
	Native IPv6 Model approaches include:
	BIER-over-IPv6 [I-D.pfister-bier-over-ipv6].		4. Requirements
	BIERv6 [I-D.xie-bier-ipv6-encapsulation].		There are several suggested requirements for BIER IPv6 solutions.
	4. Requirements		In this document, the requirements are divided into two levels:
			Mandatory and Optional. The requirement levels are determined based
			on the following factors:
	There have been several suggested requirements, on the BIER email		If the requirement is required for a feature that is likely to be
	list and in meetings, which have been used to form BIER IPv6		a potential deployment, the requirement level will be considered
	requirements used to help the wg evaluate against the proposed		mandatory.
	solutions. There is also many further discussions on the list about
	BIER IPv6 requirements from different scenarios.
	Considering that the importance of requirement for BIER IPv6 solution		If the impact of not implementing the requirement may block BIER
	is different, in this document, the requirements are divided into two		from been deployed, the requirement level will be considered
	groups: mandatory and optional. The requirements in the mandatory		mandatory.
	group are considered necessary for any BIER IPv6 solution, while the
	requirements in the optional group should be considered but are not
	mandatory.
	4.1. Mandatory Requirements		4.1. Mandatory Requirements
	4.1.1. L2 Agnostic		Considering that these mandatory requirements are all well-known to
			the working group, and practical in normal deployment, they will be
			listed without a detailed description.
	The solution must be agnostic to the underlying L2 data link type.		4.1.1. Support various L2 link types
	The solution needs to support P2P ethernet links as well as shared
	media ethernet links without requiring the LAN switch to perform BIER		The solution should support various kinds of L2 data link types.
	snooping.
	4.1.2. Support BIER architecture		4.1.2. Support BIER architecture
	The solution must support the BIER architecture.		The solution must support the BIER architecture.
	Multiple sub-domains bound to one or many topologies or algorithms,		Supporting different multicast flow overlays, multiple sub-domains,
	multiple sets for more BFERs, multiple Bit String Lengths for		multi-topologies, multiple sets, multiple Bit String Lengths, and
	different forwarding capabilities, and multiple BIFTs for ECMP are		deterministic ECMP are considered essential functions of BIER and
	considered essential functions of BIER and need to be supported.		need to be supported.
	4.1.3. Conform to existing IPv6 Spec
	The proposed encapsulation must conform to the IPv6 specification and
	guidelines as described in RFC8200. If new extensions to existing
	IPv6 specification are required, it needs to be discussed and
	reviewed by the 6man working-group.
	4.1.4. Support deployment with Non-BFR routers
	The solution must support deployments with Non-BFR routers. This is
	beneficial to the deployment of BIER, especially in early deployments
	when some routers do not support BIER forwarding but support IPv6
	forwarding. This is also the No.1 charter item, "Transition
	Mechanisms and Partial Deployments" of the BIER WG.
	4.1.5. Support inter-AS multicast deployment
	Inter-AS multicast support is needed for ease of provisioning the
	P2MP transport service to enterprises. This could greatly increase
	the scalability of BIER, as it is usually considered to be suitable
	only for small intra-AS scenarios.
	4.1.6. Support Simple Encapsulation		4.1.3. Support deployment with Non-BFR routers
	The solution must avoid requiring different encapsulation types. A		The solution must support deployments with BIER-incapable routers.
	solution needs to do careful trade-off analysis and select one		This is beneficial to the deployment of BIER, especially in early
	encapsulation as its proposal for best coverage of various scenarios.		deployments when some routers do not support BIER forwarding but
			support IPv6 forwarding.
	4.1.7. Support Deployment Security		4.1.4. Support OAM
	The proposed solution must include careful security considerations,		BIER OAM should be supported, either directly using existing methods,
	including all that is already considered in BIER architecture RFC8279		or by specifying a new method for the same functionality. It may be
	and RFC8296, and other security concerns that may raise due to the		considered essential as part of the BIER architecture in some cases.
	addition of IPv6.
	4.2. Optional Requirements		4.2. Optional Requirements
	4.2.1. Support MVPN		The requirements in this section are listed as optional, and each
			requirement is explained with a detailed scenario. Note that
	The solution MAY support MVPN services that is defined in [RFC6513].		fragmentation and IPSEC ESP are not BIER functions, they are provided
	When MVPN is supported, it should work in a "tunnel" mode,		by the upper IP layer.
	encapsulating IP or IPv6 multicast packet in an outer IPv6 header.
	When MVPN is supported, it is suggested to think about both intra-AS
	and inter-AS deployment.
	4.2.2. Support OAM
	BIER OAM MAY be supported, either directly using existing method, or
	specify some variant method for the same function. It may be
	considered essential as part of the BIER architecture in some cases.
	4.2.3. Support IPSEC		4.2.1. Support Fragmentation
	IPSEC is optional to IPv6 and multicast. It is preferred to support		There are some cases where the Fragmentation/Assembly function is
	IPSEC, including AH/ESP. If IPSEC is to be supported, it shouldn't		needed for BIER to work in an IPv6 network.
	require hop-by-hop encryption/decryption.
	4.2.4. Support Fragmentation		For example, a customer IPv6 multicast packet may be 1280 bytes and
			is required to be transported through an IPv6 network using BIER.
			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
			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
			MTU to the source [RFC8296]. Instead, the IPv6 transport mechanism,
			either integrated with or independent to BIER, need to provide the
			fragmentation and assembly function.
	As part of IPv6 specification [RFC8200], BIER IPv6 may support		4.2.2. Support IPSEC ESP
	fragmentation on BFIR and assembly on BFER. Support of Fragmentation
	can enhance the capability of BIER leveraging the BIER-MTU as
	introduced in section 3 of [RFC8296]. If Fragmentation is to be
	supported, it shouldn't require fragmentation and re-assembly at each
	hop.
	4.2.5. Support hardware fast path		There are some cases where the IPSEC ESP function may be needed to
			transport c-multicast packets through an IPv6 network with
			confidentiality using BIER technology.
	If a proposed solution is intended for some scenarios like service-		A service provider may want to provide additional security SLA to its
	provider networks, it should enable the processing and forwarding of		customer to ensure that the unencrypted c-multicast packet is not
	BIER packets in hardware fast path.		altered in the service provider's network. In this case, if the BIER
			technology is preferred for the multicast service, BIER with IPSEC
			ESP support may be a candidate solution. On the other hand, the
			traffic protection may be better provided via IPSEC or MACSEC at
			multicast flow overlay over and beyond the BIER domain.
	5. IANA Considerations		5. IANA Considerations
	Some BIERv6 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 BIER Destination Option		IANA while other proposals require new IPv6 Option codepoints from
	codepoints from IPv6 sub-registries, new "Next header" values, or		IPv6 sub-registries, new "Next header" values, or require new IP
	require new IP Protocol codes. This document, however, does not		Protocol codes. This document, however, does not require anything
	require anything from IANA.		from IANA.
	6. Security Considerations		6. Security Considerations
	There are no security issues introduced by this draft.		There are no security issues introduced by this draft.
	7. Acknowledgement		7. Acknowledgement
	Thank you to Eric Rosen for his listed set of requirements on the		Thanks to Eric Rosen for his listed set of initial requirements on
	bier wg list.		the BIER WG mailing list.
	8. Normative References		8. Normative References
	[I-D.geng-bier-ipv6-inter-domain]
	Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain
	Multicast Deployment using BIERv6", draft-geng-bier-ipv6-
	inter-domain-01 (work in progress), January 2020.
	[I-D.ietf-bier-use-cases]
	Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
	Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
	Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-11
	(work in progress), March 2020.
	[I-D.ietf-spring-srv6-network-programming]
	Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
	Matsushima, S., and Z. Li, "SRv6 Network Programming",
	draft-ietf-spring-srv6-network-programming-16 (work in
	progress), June 2020.
	[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-
	xie-bier-ipv6-encapsulation-08 (work in progress), July		xie-bier-ipv6-encapsulation-08 (work in progress), July
	2020.		2020.
	[I-D.xu-bier-encapsulation]
	Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
	C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
	Index Explicit Replication (BIER) Encapsulation Header",
	draft-xu-bier-encapsulation-06 (work in progress),
	September 2016.
	[I-D.zhang-bier-bierin6]		[I-D.zhang-bier-bierin6]
	Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and		Zhang, Z., Zhang, Z., Wijnands, I., Bidgoli, H., and M.
	M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-		McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-
	bierin6-06 (work in progress), July 2020.		bierin6-07 (work in progress), July 2020.
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, DOI 10.17487/RFC1112, August 1989,
	<https://www.rfc-editor.org/info/rfc1112>.
	[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>.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <https://www.rfc-editor.org/info/rfc2473>.		December 1998, <https://www.rfc-editor.org/info/rfc2473>.
	[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
	"Encapsulating MPLS in IP or Generic Routing Encapsulation
	(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
	<https://www.rfc-editor.org/info/rfc4023>.
	[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
	2012, <https://www.rfc-editor.org/info/rfc6513>.
	[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
	"Encapsulating MPLS in UDP", RFC 7510,
	DOI 10.17487/RFC7510, April 2015,
	<https://www.rfc-editor.org/info/rfc7510>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	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>.
	[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,		Appendix A. List of Solutions
	W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
	DOI 10.17487/RFC8663, December 2019,
	<https://www.rfc-editor.org/info/rfc8663>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.
	Appendix A. Solutions Evaluation
	The following are solutions that have been proposed to solve BIER in
	IPv6 environments. Some solutions propose encoding while others
	propose encapsulation. It is recommended for the wg to evaluate
	these solutions against the requirements listed previously in order
	to make informed decisions on solution readiness.
	As illustrated in these examples, the BIER header, or the BitString,
	may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,
	or IPv6 Tunnel Packet:
	A.1. BIER-ETH encapsulation in IPv6 networks
	+---------------+-----------------+-------------------		There have been some proposed solutions for BIER in IPv6
	| Ethernet | BIER header | payload		environments. Some solutions propose encoding while others propose
	| (ethType = | (BIFT-id, ...) |		encapsulation. It is recommended for the wg to evaluate these
	| 0xAB37) | |		solutions, against the requirements listed previously, in order to
	| | Next Header |		make informed decisions on solution readiness.
	+---------------+-----------------+-------------------
	BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined		This section lists these solutions categorizing in the two conceptual
	in [RFC8296]) can be used to transport the multicast data in the IPv6		models.
	network by encapsulating the multicast user data payload within the
	BIER-ETH header. However, BIER-ETH in IPv6 networks is not
	considered to be a "BIER natively in IPv6" solution which utilizes
	the IPv6 header to forward the packet.
	Mixed use of BIER-ETH in a native IPv6 solution is up to the solution		A.1. Integrated mode approach
	and is outside the scope of this document.
	A.2. Encode Bitstring in IPv6 destination address		One example of this model is defined in [I-D.pfister-bier-over-ipv6],
			where the information required for BIER forwarding, e.g., the
			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 are used by intermediate routers for unicast forwarding,
			deciding whether a packet is a BIER packet, and if so, to identify
			the BIER Sub-Domain, Set Identifier and BitString length. The BIER
			function is integrated in the IPv6 header and its forwarding
			procedure, and the BIER payload is encapsulated as the IPv6 payload.
	+---------------+-------------------		+---------------+-------------------
	| IPv6 header | payload		| IPv6 header | payload
	| (BitString in |		| (BitString in |
	| DA lower bits)|		| DA lower bits)|
	| Next Header |		| Next Header |
	+---------------+-------------------		+---------------+-------------------
	As described in [I-D.pfister-bier-over-ipv6], The information		Another example of this model is defined in
	required by BIER is stored in the destination IPv6 address. The BIER		[I-D.xie-bier-ipv6-encapsulation], where information required for
	BitString is encoded in the low-order bits of the IPv6 destination		BIER forwarding, e.g., the BIER header, is encoded in an Option TLV
	address of each packet. The high-order bits of the IPv6 destination		(indicated by an Option Type to be allocated by IANA) of the IPv6
	address are used by intermediate routers for unicast forwarding,		Destination Option Header. The third-highest-order bit of the Option
	deciding whether a packet is a BIER packet, and if so, to identify		Type is set to 1 to allow Option Data (e.g., the BitString) change en
	the BIER Sub-Domain, Set Identifier and BitString length. No		route. The BIER function is integrated in IPv6 extension header and
	additional extension or encapsulation header is required. Instead of		its forwarding procedure, and the BIER payload is encapsulated as the
	encapsulating the packet in IPv6, the payload is attached to the BIER		IPv6 payload.
	IPv6 header and the IPv6 protocol number is set to the type of the
	payload. If the payload is UDP, the UDP checksum needs to change
	when the BitString in the IPv6 destination address changes.
	A.3. Add BIER header into IPv6 Extension Header
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	| 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 |
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	According to [RFC8200] In IPv6, optional internet-layer information		A.2. Independent model approach
	is encoded in separate headers that may be placed between the IPv6
	header and the upper- layer header in a packet. There is a small
	number of such extension headers, each one identified by a distinct
	Next Header value. An IPv6 packet may carry zero, one, or more
	extension headers, each identified by the Next Header field of the
	preceding header. Extension headers (except for the Hop-by-Hop
	Options header) are not processed, inserted, or deleted by any node
	along a packet's delivery path, until the packet reaches the node (or
	each of the set of nodes, in the case of multicast) identified in the
	Destination Address field of the IPv6 header. The Hop-by-Hop Options
	header is not inserted or deleted, but may be examined or processed
	by any node along a packet's delivery path, until the packet reaches
	the node (or each of the set of nodes, in the case of multicast)
	identified in the Destination Address field of the IPv6 header. The
	Hop-by-Hop Options header, when present, must immediately follow the
	IPv6 header. Its presence is indicated by the value zero in the Next
	Header field of the IPv6 header.
	Two of the currently-defined extension headers are the Hop-by-Hop
	Options header and the Destination Options header which carry a
	variable number of type-length-value (TLV) encoded "options".
	In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option
	is carried by the IPv6 Destination Option Header (indicated by a Next
	Header value 60). It is initialized in a packet sent by an IPv6 BFIR
	router to inform the following BFR routers in an IPv6 BIER domain to
	replicate to destination BFER routers hop-by-hop. BIER is generally
	a hop-by-hop and one-to-many architecture and it is required for a
	BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an
	IPv6 Extension Header, to pilot the hop-by-hop BIER replication.
	Hop by hop Options Headers may be considered. The Hop-by-Hop Options
	header is used to carry optional information that may be examined and
	processed by every node along a packet's delivery path. The Hop-by-
	Hop Options header is identified by a Next Header value of 0 in the
	IPv6 header.
	Defining New Extension Headers and Options may also be considered, if
	the IPv6 Destination Option Header is not good enough and new
	extension headers can solve the problem better.
	Such proposals may include requests to IANA to allocate a "BIER
	Option" code from "Destination Options and Hop-by-Hop Options", and/
	or a "BIER Option Header" code from "IPv6 Extension Header Types".
	A.4. Transport BIER as IPv6 payload
	+---------------+-----------------+-------------------		One example of this model is defined in [I-D.zhang-bier-bierin6],
	| IPv6 header | IPv6 Ext header | BIER Hdr + payload		where the BIER header and the payload following it are L2 payload
	| | (optional) | as IPv6 payload		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
	| Next Header | Next Header = X |		not directly connected). This is indicated by either a 0xAB37
	+---------------+-----------------+-------------------		Ethertype allocated to BIER or a new IPv6 Next-Header value to be
			allocated by IANA.
	There is a proposal for a transport-independent BIER encapsulation		+---------------+-----------------+-------------------
	header which is applicable regardless of the underlying transport		| Ethernet | BIER header | payload
	technology. As described in [I-D.xu-bier-encapsulation] and		| (ethType = | (BIFT-id, ...) |
	[I-D.zhang-bier-bierin6], the BIER header, and the payload following		| 0xAB37) | |
	it, can be combined as an IPv6 payload, and be indicated by a new		| | Next Header |
	Upper-layer IPv6 Next-Header value. A unicast IPv6 destination		+---------------+-----------------+-------------------
	address is used for the replication and changes when replicating a
	packet out to a neighbor.
	Such proposals may include a request to IANA to allocate an IPv6		+---------------+-----------------+-------------------
	Next-Header code from "Assigned Internet Protocol Numbers".		| IPv6 header | IPv6 Ext header | BIER Hdr + payload
			| | (optional) | as IPv6 payload
			| | |
			| Next Header | Next Header = X |
			+---------------+-----------------+-------------------
	A.5. Tunnelling BIER in a IPv6 tunnel		While not specified in [I-D.zhang-bier-bierin6], any other tunnel
			types supported by the IPv6 environment could be used, e.g. IPv6
			GRE/UDP:
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	| IPv6 header | IPv6 Ext header | GRE header |		| IPv6 header | IPv6 Ext header | GRE header |
	| | (optional) | | BIER Hdr +		| | (optional) | | BIER Hdr +
	| | | | payload as GRE		| | | | payload as GRE
	| Next Header | Next Header | Proto = X | Payload		| Next Header | Next Header |Proto=0xAB37| Payload
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	A generic IPv6 Tunnel could be used to encapsulate the bier packet
	within an IPv6 domain.
	GRE is a mechanism by which any ethernet payload can be carried by an
	IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4
	and IPv6 can be used to carry GRE. The Ethernet type codepoint
	0xAB37, defined for BIER, can be used in a GRE header to indicate the
	subsequent BIER header and payload in an IPv6 network.
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	| IPv6 header | IPv6 Ext header | UDP header |		| IPv6 header | IPv6 Ext header | UDP header |
	| | (optional) | | BIER Hdr +		| | (optional) | | BIER Hdr +
	| | | | payload as UDP		| | | | payload as UDP
	| Next Header | Next Header | DPort = X | Payload		| Next Header |Next Header =UDP | DPort=TBD | Payload
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	UDP-based tunnelling is another mechanism which uses a specific UDP
	port to indicate a UDP payload format. Both IPv4 and IPv6 can
	support UDP. Such UDP-based tunnels can be used for BIER in a IPv6
	network by defining a new UDP port to indicate the BIER header and
	payload.
	Authors' Addresses		Authors' Addresses
	Mike McBride		Mike McBride
	Futurewei		Futurewei
	Email: michael.mcbride@futurewei.com		Email: michael.mcbride@futurewei.com
	Jingrong Xie		Jingrong Xie
	Huawei		Huawei
	Email: xiejingrong@huawei.com		Email: xiejingrong@huawei.com
			Xuesong Geng
			Huawei
			Email: gengxuesong@huawei.com
	Senthil Dhanaraj		Senthil Dhanaraj
	Huawei		Huawei
	Email: senthil.dhanaraj@huawei.com		Email: senthil.dhanaraj@huawei.com
	Rajiv Asati		Rajiv Asati
	Cisco		Cisco
	Email: rajiva@cisco.com		Email: rajiva@cisco.com
	Yongqing Zhu		Yongqing Zhu
	China Telecom		China Telecom
	Email: zhuyq8@chinatelecom.cn		Email: zhuyq8@chinatelecom.cn
	Gyan S. Mishra
	Verizon Inc.
	13101 Columbia Pike		Gyan Mishra
			Verizon Inc.
	Silver Spring
	,
	MD 20904
	United States of America		Email: gyan.s.mishra@verizon.com
	Phone:		Zhaohui Zhang
	301 502-1347		Juniper
	Email:		Email: zzhang@juniper.net
	gyan.s.mishra@verizon.com
End of changes. 77 change blocks.
	481 lines changed or deleted		242 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/