< draft-ietf-bier-use-cases-01.txt		draft-ietf-bier-use-cases-02.txt >
	Network Working Group N. Kumar		Network Working Group N. Kumar
	Internet-Draft R. Asati		Internet-Draft R. Asati
	Intended status: Informational Cisco		Intended status: Informational Cisco
	Expires: February 4, 2016 M. Chen		Expires: July 29, 2016 M. Chen
	X. Xu		X. Xu
	Huawei		Huawei
	A. Dolganow		A. Dolganow
	Alcatel-Lucent		Alcatel-Lucent
	T. Przygienda		T. Przygienda
	Ericsson		Ericsson
	A. Gulko		A. Gulko
	Thomson Reuters		Thomson Reuters
	D. Robinson		D. Robinson
	id3as-company Ltd		id3as-company Ltd
	V. Arya		V. Arya
	DirecTV Inc		DirecTV Inc
	August 3, 2015		C. Bestler
			Nexenta
			January 26, 2016
	BIER Use Cases		BIER Use Cases
	draft-ietf-bier-use-cases-01.txt		draft-ietf-bier-use-cases-02.txt
	Abstract		Abstract
	Bit Index Explicit Replication (BIER) is an architecture that		Bit Index Explicit Replication (BIER) is an architecture that
	provides optimal multicast forwarding through a "BIER domain" without		provides optimal multicast forwarding through a "BIER domain" without
	requiring intermediate routers to maintain any multicast related per-		requiring intermediate routers to maintain any multicast related per-
	flow state. BIER also does not require any explicit tree-building		flow state. BIER also does not require any explicit tree-building
	protocol for its operation. A multicast data packet enters a BIER		protocol for its operation. A multicast data packet enters a BIER
	domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the		domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
	BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).		BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 12 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 February 4, 2016.		This Internet-Draft will expire on July 29, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Specification of Requirements . . . . . . . . . . . . . . . . 3		2. Specification of Requirements . . . . . . . . . . . . . . . . 3
	3. BIER Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3		3. BIER Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Multicast in L3VPN Networks . . . . . . . . . . . . . . . 3		3.1. Multicast in L3VPN Networks . . . . . . . . . . . . . . . 3
	3.2. BUM in EVPN . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. BUM in EVPN . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. IPTV and OTT Services . . . . . . . . . . . . . . . . . . 5		3.3. IPTV and OTT Services . . . . . . . . . . . . . . . . . . 5
	3.4. Multi-service, converged L3VPN network . . . . . . . . . 6		3.4. Multi-service, converged L3VPN network . . . . . . . . . 6
	3.5. Control-plane simplification and SDN-controlled networks 7		3.5. Control-plane simplification and SDN-controlled networks 7
	3.6. Data center Virtualization/Overlay . . . . . . . . . . . 7		3.6. Data center Virtualization/Overlay . . . . . . . . . . . 7
	3.7. Financial Services . . . . . . . . . . . . . . . . . . . 8		3.7. Financial Services . . . . . . . . . . . . . . . . . . . 8
	3.8. 4k broadcast video services . . . . . . . . . . . . . . . 9		3.8. 4k broadcast video services . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		3.9. Distributed Storage Cluster . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is		Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is
	an architecture that provides optimal multicast forwarding through a		an architecture that provides optimal multicast forwarding through a
	"BIER domain" without requiring intermediate routers to maintain any		"BIER domain" without requiring intermediate routers to maintain any
	multicast related per-flow state. BIER also does not require any		multicast related per-flow state. BIER also does not require any
	explicit tree-building protocol for its operation. A multicast data		explicit tree-building protocol for its operation. A multicast data
	packet enters a BIER domain at a "Bit-Forwarding Ingress Router"		packet enters a BIER domain at a "Bit-Forwarding Ingress Router"
	(BFIR), and leaves the BIER domain at one or more "Bit-Forwarding		(BFIR), and leaves the BIER domain at one or more "Bit-Forwarding
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 8 ¶
	state. The obvious advantage with BIER is the low multicast state		state. The obvious advantage with BIER is the low multicast state
	maintained in the core and the faster convergence (which is typically		maintained in the core and the faster convergence (which is typically
	at par with the unicast convergence). The edge router at the content		at par with the unicast convergence). The edge router at the content
	source facility can act as BIFR router and the edge router at the		source facility can act as BIFR router and the edge router at the
	receiver facility can act as BFER routers. Any addition of a new		receiver facility can act as BFER routers. Any addition of a new
	content source or new satellite Terminal nodes can be added		content source or new satellite Terminal nodes can be added
	seamlessly in to the BEIR domain. The group membership from the		seamlessly in to the BEIR domain. The group membership from the
	receivers to the sources can be provisioned either by BGP or SDN		receivers to the sources can be provisioned either by BGP or SDN
	controller.		controller.
			3.9. Distributed Storage Cluster
			Distributed Storage Clusters can benefit from dynamically targeted
			multicast messaging both for dynamic load-balancing negotiations and
			efficient concurrent replication of content to multiple targets.
			For example, in the NexentaEdge storage cluster (by Nexenta Systems)
			a Chunk Put transaction is accomplished with the following steps:
			o The Client multicast a Chunk Put Request to a multicast group
			known as a Negotiating Group. This group holds a small number of
			storage targets that are collectively responsible for providing
			storage for a stable subset of the chunks to be stored. In
			NexentaEdge this is based upon a cryptographic hash of the Object
			Name or the Chunk payload.
			o Each recipient of the Chunk Put Request unicast a Chunk Put
			Response to the Client indicating when it could accept a transfer
			of the Chunk.
			o The Client selects a different multicast group (a Rendezvous
			Group) which will target the set storage targets selected to hold
			the Chunk. This is a subset of the Negotiation Group, presumably
			selected so as to complete the transfer as early as possible.
			o >The Client multicast a Chunk Put Accept message to inform the
			Negotiation Group of what storage targets have been selected, when
			the transfer will occur and over what multicast group.
			o The client performs the multicast transfer over the Rendezvous
			Group at the agreed upon time.
			o Each recipient sends a Chunk Put Ack to positively or negatively
			acknowledge the chunk transfer.
			o The client will retry the entire transaction as needed if there
			are not yet sufficient replicas of the Chunk.
			Chunks are retrieved by multicasting a Chunk Get Request to the same
			Negotiating Group, collecting Chunk Get Responses, picking one source
			from those responses, sending a Chunk Get Accept message to identify
			the selected source and having the selected storage server unicast
			the chunk to the source.
			Chunks are found by the Object Name or by having the payload
			cryptographic hash of payload chunks be recorded in a "chunk
			reference" in a metadata chunk. The metadata chunks are found using
			the Object Name.
			The general pattern in use here, which should apply to other cluster
			applications, is that multicast messages are sent amongst a
			dynamically selected subset of the entire cluster, which may result
			in exchanging further messages over a smaller subset even more
			dynamically selected.
			Currently the distributed storage application discussed use of MLD
			managed IPV6 multicast groups. This in turn requires either a push-
			based mechanism for dynamically configuring Rendezvous Groups or pre-
			provisioning a very large number of potential Rendezvous Groups and
			dynamically selecting the multicast group that will deliver to the
			selected set of storage targets.
			BIER would eliminate the need for a vast number of multicast groups.
			The entire cluster can be represented as a single BIER domain using
			only the default sub-domain. Each Negotiating Group is simply a
			subset of the whole that is deterministically selected by the
			Cryptographic Hash of the Object Name or Chunk Payload. Each
			Rendezvous Group is a further subset of the Negotiating Group.
			In a simple mapping of the MLD managed multicast groups, each
			Negotiating Group could be represented by a short Bitstring selected
			by a Set Identifier. The Set Indentier effectively becomes the
			Negotiating Group. To address the entire Negotiating Group you set
			the Bitstring to all ones. To later address a subset of the group a
			subset Bitstring is used.
			This allows a short fixed size BIER header to multicast to a very
			large storage cluster.
	4. Security Considerations		4. Security Considerations
	There are no security issues introduced by this draft.		There are no security issues introduced by this draft.
	5. IANA Considerations		5. IANA Considerations
	There are no IANA consideration introduced by this draft.		There are no IANA consideration introduced by this draft.
	6. Acknowledgments		6. Acknowledgments
	skipping to change at page 13, line 4 ¶		skipping to change at page 14, line 32 ¶
	Email: antoni.przygienda@ericsson.com		Email: antoni.przygienda@ericsson.com
	Arkadiy Gulko		Arkadiy Gulko
	Thomson Reuters		Thomson Reuters
	195 Broadway		195 Broadway
	New York NY 10007		New York NY 10007
	USA		USA
	Email: arkadiy.gulko@thomsonreuters.com		Email: arkadiy.gulko@thomsonreuters.com
	Dom Robinson		Dom Robinson
	id3as-company Ltd		id3as-company Ltd
	UK		UK
	Email: Dom@id3as.co.uk		Email: Dom@id3as.co.uk
	Vishal Arya		Vishal Arya
	DirecTV Inc		DirecTV Inc
	2230 E Imperial Hwy		2230 E Imperial Hwy
	CA 90245		CA 90245
	USA		USA
	Email: varya@directv.com		Email: varya@directv.com
			Caitlin Bestler
			Nexenta Systems
			451 El Camino Real
			Santa Clara, CA
			US
			Email: caitlin.bestler@nexenta.com
End of changes. 10 change blocks.
	13 lines changed or deleted		96 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/