< draft-kumar-bier-use-cases-01.txt		draft-kumar-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: August 3, 2015 M. Chen		Expires: August 13, 2015 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
	January 30, 2015		D. Robinson
			id3as-company Ltd
			February 9, 2015
	BIER Use Cases		BIER Use Cases
	draft-kumar-bier-use-cases-01.txt		draft-kumar-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 7 ¶		skipping to change at page 2, line 10 ¶
	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 August 3, 2015.		This Internet-Draft will expire on August 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 34 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. 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 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 6		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 . . . . . . . . . . . . . . . . . . . 7		3.7. Financial Services . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER)		Bit Index Explicit Replication (BIER)
	[I-D.wijnands-bier-architecture] is an architecture that provides		[I-D.wijnands-bier-architecture] is an architecture that provides
	optimal multicast forwarding through a "BIER domain" without		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
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 28 ¶
	targets. In a sense BIER is an inclusive as well as a selective tree		targets. In a sense BIER is an inclusive as well as a selective tree
	and can allow to deliver the frame to only the set of receivers		and can allow to deliver the frame to only the set of receivers
	interested in a frame even though many others participate in the same		interested in a frame even though many others participate in the same
	PMSI.		PMSI.
	As another significant advantage, it is imaginable that the same BIER		As another significant advantage, it is imaginable that the same BIER
	tunnel needed for BUM frames can optimize the delivery of the		tunnel needed for BUM frames can optimize the delivery of the
	multicast frames though the signaling of group memberships for the		multicast frames though the signaling of group memberships for the
	PEs involved has not been specified as of date.		PEs involved has not been specified as of date.
	3.3. IPTV Services		3.3. IPTV and OTT Services
	IPTV is a service, well known for its characteristics of allowing		IPTV is a service, well known for its characteristics of allowing
	both live and on-demand delivery of media traffic over IP. In a		both live and on-demand delivery of media traffic over end-to-end
	typical IPTV environment the egress routers connecting to the		Managed IP network.
			Over The Top (OTT) is a similar service, well known for its
			characteristics of allowing live and on-demand delivery of media
			traffic between IP domains, where the source is often on an external
			network relative to the receivers.
			Content Delivery Networks (CDN) operators provide layer 4
			applications, and often some degree of managed layer 3 IP network,
			that enable media to be securely and reliably delivered to many
			receivers. In some models they may place applications within third
			party networks, or they may place those applications at the edges of
			their own managed network peerings and similar inter-domain
			connections. CDNs provide capabilities to help publishers scale to
			meet large audience demand. Their applications are not limited to
			audio and video delivery, but may include static and dynamic web
			content, or optimized delivery for Massive Multiplayer Gaming and
			similar. Most publishers will use a CDN for public Internet
			delivery, and some publishers will use a CDN internally within their
			IPTV networks to resolve layer 4 complexity.
			In a typical IPTV environment the egress routers connecting to the
	receivers will build the tree towards the ingress router connecting		receivers will build the tree towards the ingress router connecting
	to the IPTV servers. The egress routers would rely on IGMP/MLD		to the IPTV servers. The egress routers would rely on IGMP/MLD
	(static or dynamic) to learn about the receiver's interest in one or		(static or dynamic) to learn about the receiver's interest in one or
	more multicast group/channels. Interestingly, BIER could allows		more multicast group/channels. Interestingly, BIER could allows
	provisioning any new multicast group/channel by only modifying the		provisioning any new multicast group/channel by only modifying the
	channel mapping on ingress routers. This is deemed beneficial for		channel mapping on ingress routers. This is deemed beneficial for
	the linear IPTV video broadcasting in which every receivers behind		the linear IPTV video broadcasting in which every receivers behind
	every egress PE routers would receive the IPTV video traffic.		every egress PE routers would receive the IPTV video traffic.
	With BIER, there is no need of tree building from egress to ingress.		With BIER in IPTV environment, there is no need of tree building from
	Further, any addition of new channel or new egress routers can be		egress to ingress. Further, any addition of new channel or new
	directly controlled from ingress router. When a new channel is		egress routers can be directly controlled from ingress router. When
	included, the multicast group is mapped to Bit string that includes		a new channel is included, the multicast group is mapped to Bit
	all egress routers. Ingress router would start sending the new		string that includes all egress routers. Ingress router would start
	channel and deliver it to all egress routers. As it can be observed,		sending the new channel and deliver it to all egress routers. As it
	there is no need for static IGMP provisioning in each egress routers		can be observed, there is no need for static IGMP provisioning in
	whenever a new channel/stream is added. Instead, it can be		each egress routers whenever a new channel/stream is added. Instead,
	controlled from ingress router itself by configuring the new group to		it can be controlled from ingress router itself by configuring the
	Bit Mask mapping on ingress router.		new group to Bit Mask mapping on ingress router.
			With BIER in OTT environment, these edge routers in CDN domain
			terminating the OTT user session connect to the Ingress BIER routers
			connecting content provider domains or a local cache server and
			leverage the scalability benefit that BIER could provide. This may
			rely on MBGP interoperation (or similar) between the egress of one
			domain and the ingress of the next domain, or some other SDN control
			plane may prove a more effective and simpler way to deploy BIER. For
			a single CDN operator this could be well managed in the Layer 4
			applications that they provide and it may be that the initial
			receiver in a remote domain is actually an application operated by
			the CDN which in turn acts as a source for the Ingress BIER router in
			that remote domain, and by doing so keeps the BIER more descrete on a
			domain by domain basis.
	3.4. Multi-service, converged L3VPN network		3.4. Multi-service, converged L3VPN network
	Increasingly operators deploy single networks for multiple-services.		Increasingly operators deploy single networks for multiple-services.
	For example a single Metro Core network could be deployed to provide		For example a single Metro Core network could be deployed to provide
	Residential IPTV retail service, residential IPTV wholesale service,		Residential IPTV retail service, residential IPTV wholesale service,
	and business L3VPN service with multicast. It may often be desired		and business L3VPN service with multicast. It may often be desired
	by an operator to use a single architecture to deliver multicast for		by an operator to use a single architecture to deliver multicast for
	all of those services. In some cases, governing regulations may		all of those services. In some cases, governing regulations may
	additionally require same service capabilities for both wholesale and		additionally require same service capabilities for both wholesale and
	skipping to change at page 8, line 46 ¶		skipping to change at page 9, line 32 ¶
	The authors would like to thank IJsbrand Wijnands, Greg Shepherd and		The authors would like to thank IJsbrand Wijnands, Greg Shepherd and
	Christian Martin for their contribution.		Christian Martin for their contribution.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.rosen-l3vpn-mvpn-bier]		[I-D.rosen-l3vpn-mvpn-bier]
	Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S.,		Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S.,
	Dolganow, A., and T. Przygienda, "Multicast VPN Using		Dolganow, A., and T. Przygienda, "Multicast VPN Using
	BIER", draft-rosen-l3vpn-mvpn-bier-01 (work in progress),		BIER", draft-rosen-l3vpn-mvpn-bier-02 (work in progress),
	October 2014.		December 2014.
	[I-D.wijnands-bier-architecture]		[I-D.wijnands-bier-architecture]
	Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and		Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
	S. Aldrin, "Multicast using Bit Index Explicit		S. Aldrin, "Multicast using Bit Index Explicit
	Replication", draft-wijnands-bier-architecture-01 (work in		Replication", draft-wijnands-bier-architecture-04 (work in
	progress), October 2014.		progress), February 2015.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-l2vpn-evpn]		[I-D.ietf-l2vpn-evpn]
	Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.		Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
	Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-		Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
	evpn-11 (work in progress), October 2014.		evpn-11 (work in progress), October 2014.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,		Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
	and E. Crabbe, "Segment Routing Architecture", draft-ietf-		and E. Crabbe, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-00 (work in progress), December		spring-segment-routing-01 (work in progress), February
	2014.		2015.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.		Protocol Specification (Revised)", RFC 4601, August 2006.
	[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual		[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
	Private Networks (L2VPNs)", RFC 4664, September 2006.		Private Networks (L2VPNs)", RFC 4664, September 2006.
	[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
	"Bidirectional Protocol Independent Multicast (BIDIR-		"Bidirectional Protocol Independent Multicast (BIDIR-
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 37 ¶
	Email: andrew.dolganow@alcatel-lucent.com		Email: andrew.dolganow@alcatel-lucent.com
	Tony Przygienda		Tony Przygienda
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	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
			id3as-company Ltd
			UK
			Email: Dom@id3as.co.uk
End of changes. 15 change blocks.
	31 lines changed or deleted		69 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/