< draft-ietf-bier-use-cases-00.txt		draft-ietf-bier-use-cases-01.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: October 29, 2015 M. Chen		Expires: February 4, 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
	April 27, 2015		V. Arya
			DirecTV Inc
			August 3, 2015
	BIER Use Cases		BIER Use Cases
	draft-ietf-bier-use-cases-00.txt		draft-ietf-bier-use-cases-01.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 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 October 29, 2015.		This Internet-Draft will expire on February 4, 2016.
	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 39 ¶		skipping to change at page 2, line 39 ¶
	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 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
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 9		3.8. 4k broadcast video services . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER)		Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is
	[I-D.wijnands-bier-architecture] is an architecture that provides		an architecture that provides optimal multicast forwarding through a
	optimal multicast forwarding through a "BIER domain" without		"BIER domain" without requiring intermediate routers to maintain any
	requiring intermediate routers to maintain any multicast related per-		multicast related per-flow state. BIER also does not require any
	flow state. BIER also does not require any explicit tree-building		explicit tree-building protocol for its operation. A multicast data
	protocol for its operation. A multicast data packet enters a BIER		packet enters a BIER domain at a "Bit-Forwarding Ingress Router"
	domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the		(BFIR), and leaves the BIER domain at one or more "Bit-Forwarding
	BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).		Egress Routers" (BFERs). The BFIR router adds a BIER header to the
	The BFIR router adds a BIER header to the packet. The BIER header		packet. The BIER header contains a bit-string in which each bit
	contains a bit-string in which each bit represents exactly one BFER		represents exactly one BFER to forward the packet to. The set of
	to forward the packet to. The set of BFERs to which the multicast		BFERs to which the multicast packet needs to be forwarded is
	packet needs to be forwarded is expressed by setting the bits that		expressed by setting the bits that correspond to those routers in the
	correspond to those routers in the BIER header.		BIER header.
	The obvious advantage of BIER is that there is no per flow multicast		The obvious advantage of BIER is that there is no per flow multicast
	state in the core of the network and there is no tree building		state in the core of the network and there is no tree building
	protocol that sets up tree on demand based on users joining a		protocol that sets up tree on demand based on users joining a
	multicast flow. In that sense, BIER is potentially applicable to		multicast flow. In that sense, BIER is potentially applicable to
	many services where Multicast is used and not limited to the examples		many services where Multicast is used and not limited to the examples
	described in this draft. In this document we are describing a few		described in this draft. In this document we are describing a few
	use-cases where BIER could provide benefit over using existing		use-cases where BIER could provide benefit over using existing
	mechanisms.		mechanisms.
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 28 ¶
	ingress PE's. Creating PMSI state per VPN can be prevented by		ingress PE's. Creating PMSI state per VPN can be prevented by
	applying the procedures as documented in [RFC5331]. This however has		applying the procedures as documented in [RFC5331]. This however has
	not been very much adopted/implemented due to the excessive flooding		not been very much adopted/implemented due to the excessive flooding
	it would cause to Egress PE's since *all* VPN multicast packets are		it would cause to Egress PE's since *all* VPN multicast packets are
	forwarded to *all* PE's that have one or more VPN's attached to it.		forwarded to *all* PE's that have one or more VPN's attached to it.
	With BIER, the destination PE's are identified in the multicast		With BIER, the destination PE's are identified in the multicast
	packet, so there is no flooding concern when implementing [RFC5331].		packet, so there is no flooding concern when implementing [RFC5331].
	For that reason there is no need to create multiple BIER domain's per		For that reason there is no need to create multiple BIER domain's per
	VPN, the VPN context can be carry in the multicast packet using the		VPN, the VPN context can be carry in the multicast packet using the
	procedures as defined in [RFC5331]. Also see		procedures as defined in [RFC5331]. Also see [I-D.ietf-bier-mvpn]
	[I-D.rosen-l3vpn-mvpn-bier] for more information.		for more information.
	With BIER only a few MVPN profiles will remain relevant, simplifying		With BIER only a few MVPN profiles will remain relevant, simplifying
	the operational cost and making it easier to be interoperable among		the operational cost and making it easier to be interoperable among
	different vendors.		different vendors.
	3.2. BUM in EVPN		3.2. BUM in EVPN
	The current widespread adoption of L2VPN services [RFC4664],		The current widespread adoption of L2VPN services [RFC4664],
	especially the upcoming EVPN solution [I-D.ietf-l2vpn-evpn] which		especially the upcoming EVPN solution [I-D.ietf-l2vpn-evpn] which
	transgresses many limitations of VPLS, introduces the need for an		transgresses many limitations of VPLS, introduces the need for an
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	delivery of multicast data increases, thereby undermining the overall		delivery of multicast data increases, thereby undermining the overall
	security aspect.		security aspect.
	BIER enables setting up the most optimal path from publisher to		BIER enables setting up the most optimal path from publisher to
	subscribers by leveraging unicast routing relevant for the		subscribers by leveraging unicast routing relevant for the
	subscribers. With BIER, the multicast convergence is as fast as		subscribers. With BIER, the multicast convergence is as fast as
	unicast, uniform and deterministic regardless of number of multicast		unicast, uniform and deterministic regardless of number of multicast
	flows. This makes BIER a perfect multicast technology to achieve		flows. This makes BIER a perfect multicast technology to achieve
	fairness for market derivatives per each subscriber.		fairness for market derivatives per each subscriber.
			3.8. 4k broadcast video services
			In a broadcast network environment, the media content is sourced from
			various content providers across different locations. The 4k
			broadcast video is an evolving service with enormous demand on
			network infrastructure in terms of Low latency, faster convergence,
			high throughput, and high bandwidth.
			In a typical broadcast satellite network environment, the receivers
			are the satellite Terminal nodes which will receive the content from
			various sources and feed the data to the satellite. Typically a
			multicast group address is assigned for each source. Currently the
			receivers can join the sources using either PIM-SM [RFC4601] or PIM-
			SSM [RFC4607].
			In such network scenarios, normally PIM will be the multicast routing
			protocol used to establish the tree between Ingress connecting the
			content media sources to egress routers connecting the receivers. In
			PIM-SM mode, the receivers relies on shared tree to learn the source
			address and build source tree while in PIM-SSM mode, IGMPv3 is used
			by receiver to signal the source address to the egress router. In
			either case, as the number of sources increases, the number of
			multicast trees in the core also increases resulting with more
			multicast state entries in the core and increasing the convergence
			time.
			With BIER in 4k broadcast satellite network environment, there is no
			need to run PIM in the core and no need to maintain any multicast
			state. The obvious advantage with BIER is the low multicast state
			maintained in the core and the faster convergence (which is typically
			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
			receiver facility can act as BFER routers. Any addition of a new
			content source or new satellite Terminal nodes can be added
			seamlessly in to the BEIR domain. The group membership from the
			receivers to the sources can be provisioned either by BGP or SDN
			controller.
	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
	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.ietf-bier-architecture]
	Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S.,
	Dolganow, A., and T. Przygienda, "Multicast VPN Using
	BIER", draft-rosen-l3vpn-mvpn-bier-02 (work in progress),
	December 2014.
	[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-04 (work in		Replication", draft-ietf-bier-architecture-02 (work in
	progress), February 2015.		progress), July 2015.
			[I-D.ietf-bier-mvpn]
			Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S.,
			Dolganow, A., and T. Przygienda, "Multicast VPN Using
			BIER", draft-ietf-bier-mvpn-01 (work in progress), July
			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,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	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., Decraene, B., Litkowski, S.,
	Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,		and r. rjs@rob.sh, "Segment Routing Architecture", draft-
	and E. Crabbe, "Segment Routing Architecture", draft-ietf-		ietf-spring-segment-routing-04 (work in progress), July
	spring-segment-routing-01 (work in progress), February
	2015.		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,
			DOI 10.17487/RFC4601, August 2006,
			<http://www.rfc-editor.org/info/rfc4601>.
	[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	Private Networks (L2VPNs)", RFC 4664, September 2006.		IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
			<http://www.rfc-editor.org/info/rfc4607>.
			[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
			2 Virtual Private Networks (L2VPNs)", RFC 4664,
			DOI 10.17487/RFC4664, September 2006,
			<http://www.rfc-editor.org/info/rfc4664>.
	[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-
	PIM)", RFC 5015, October 2007.		PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
			<http://www.rfc-editor.org/info/rfc5015>.
	[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream		[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
	Label Assignment and Context-Specific Label Space", RFC		Label Assignment and Context-Specific Label Space",
	5331, August 2008.		RFC 5331, DOI 10.17487/RFC5331, August 2008,
			<http://www.rfc-editor.org/info/rfc5331>.
	[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP		[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	VPNs", RFC 6513, February 2012.		BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
			2012, <http://www.rfc-editor.org/info/rfc6513>.
	[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual		L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
	eXtensible Local Area Network (VXLAN): A Framework for		eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3		Overlaying Virtualized Layer 2 Networks over Layer 3
	Networks", RFC 7348, August 2014.		Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
			<http://www.rfc-editor.org/info/rfc7348>.
	Authors' Addresses		Authors' Addresses
	Nagendra Kumar		Nagendra Kumar
	Cisco		Cisco
	7200 Kit Creek Road		7200 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Email: naikumar@cisco.com		Email: naikumar@cisco.com
	skipping to change at line 516 ¶		skipping to change at page 13, line 9 ¶
	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
			DirecTV Inc
			2230 E Imperial Hwy
			CA 90245
			USA
			Email: varya@directv.com
End of changes. 19 change blocks.
	49 lines changed or deleted		103 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/