draft-ietf-mboned-interdomain-peering-bcp-00.txt		draft-ietf-mboned-interdomain-peering-bcp-01.txt
	MBONED Working Group Percy S. Tarapore		MBONED Working Group Percy S. Tarapore
	Internet Draft Robert Sayko		Internet Draft Robert Sayko
	Intended status: BCP AT&T		Intended status: BCP AT&T
	Expires: January 20, 2016 Greg Shepherd		Expires: July 20, 2016 Greg Shepherd
	Toerless Eckert		Toerless Eckert
	Cisco		Cisco
	Ram Krishnan		Ram Krishnan
	Brocade		Brocade
	July 20, 2015		January 21, 2016
	Use of Multicast Across Inter-Domain Peering Points		Use of Multicast Across Inter-Domain Peering Points
	draft-ietf-mboned-interdomain-peering-bcp-00.txt		draft-ietf-mboned-interdomain-peering-bcp-01.txt
	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 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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 20, 2016.		This Internet-Draft will expire on July 21, 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		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 3, line 4		skipping to change at page 3, line 4
	4.2.2 GRE Tunnel over Interconnecting Peering Point.....16		4.2.2 GRE Tunnel over Interconnecting Peering Point.....16
	4.2.3 Routing Aspects with AMT Tunnels.....................16		4.2.3 Routing Aspects with AMT Tunnels.....................16
	4.3. Back Office Functions - Billing and Logging Guidelines...19		4.3. Back Office Functions - Billing and Logging Guidelines...19
	4.3.1 Provisioning Guidelines...........................19		4.3.1 Provisioning Guidelines...........................19
	4.3.2 Application Accounting Billing Guidelines.........21		4.3.2 Application Accounting Billing Guidelines.........21
	4.3.3 Log Management Guidelines.........................21		4.3.3 Log Management Guidelines.........................21
	4.4. Operations - Service Performance and Monitoring Guidelines22		4.4. Operations - Service Performance and Monitoring Guidelines22
	4.5. Client Reliability Models/Service Assurance Guidelines...24		4.5. Client Reliability Models/Service Assurance Guidelines...24
	5. Troubleshooting and Diagnostics...............................24		5. Troubleshooting and Diagnostics...............................24
	6. Security Considerations.......................................25		6. Security Considerations.......................................25
	7. IANA Considerations...........................................25		7. IANA Considerations...........................................26
	8. Conclusions...................................................26		8. Conclusions...................................................26
	9. References....................................................26		9. References....................................................26
	9.1. Normative References.....................................26		9.1. Normative References.....................................26
	9.2. Informative References...................................26		9.2. Informative References...................................27
	10. Acknowledgments..............................................27		10. Acknowledgments..............................................27
	1. Introduction		1. Introduction
	Several types of applications (e.g., live video streaming, software		Several types of applications (e.g., live video streaming, software
	downloads) are well suited for delivery via multicast means. The use		downloads) are well suited for delivery via multicast means. The use
	of multicast for delivering such applications offers significant		of multicast for delivering such applications offers significant
	savings for utilization of resources in any given administrative		savings for utilization of resources in any given administrative
	domain. End user demand for such applications is growing. Often,		domain. End user demand for such applications is growing. Often,
	this requires transporting such applications across administrative		this requires transporting such applications across administrative
	skipping to change at page 4, line 4		skipping to change at page 3, line 46
	Discovery (MLD) [RFC4604], and Multicast Source Discovery		Discovery (MLD) [RFC4604], and Multicast Source Discovery
	Protocol (MSDP) [RFC3618]. This BCP is independent of the		Protocol (MSDP) [RFC3618]. This BCP is independent of the
	choice of multicast protocol; it focuses solely on the		choice of multicast protocol; it focuses solely on the
	implications for the inter-domain peering points. However, in		implications for the inter-domain peering points. However, in
	order to help explain use cases the figures will use the		order to help explain use cases the figures will use the
	general SSM flows and architectures.		general SSM flows and architectures.
	o Network Administrative Domains involved in setting up		o Network Administrative Domains involved in setting up
	multicast peering points are assumed to adopt compatible		multicast peering points are assumed to adopt compatible
	protocols. The use of different protocols is beyond the scope		protocols. The use of different protocols is beyond the scope
	of this document.		of this document.
	o It is assumed that an AMT Relay will be available to a client		o It is assumed that an AMT Relay will be available to a client
	for multicast delivery. The selection of an optimal AMT relay		for multicast delivery. The selection of an optimal AMT relay
	by a client is out of scope for this document.		by a client is out of scope for this document. Note that AMT
			use is necessary only when native multicast is unavailable in
			the peering point (Use Case 3.3) or in the downstream
			administrative domain (Use Cases 3.4, and 3.5).
	o The collection of billing data is assumed to be done at the		o The collection of billing data is assumed to be done at the
	application level and is not considered to be a networking		application level and is not considered to be a networking
	issue. The settlements process for end user billing and/or		issue. The settlements process for end user billing and/or
	inter-provider billing is out of scope for this document.		inter-provider billing is out of scope for this document.
	o Inter-domain network connectivity troubleshooting is only		o Inter-domain network connectivity troubleshooting is only
	considered within the context of a cooperative process between		considered within the context of a cooperative process between
	the two domains.		the two domains.
	This document also attempts to identify ways by which the peering		This document also attempts to identify ways by which the peering
	process can be improved. Development of new methods for improvement		process can be improved. Development of new methods for improvement
	skipping to change at page 7, line 15		skipping to change at page 7, line 15
	b. If the peering point between AD-1 and AD-2 is a controlled network		b. If the peering point between AD-1 and AD-2 is a controlled network
	environment, then bandwidth can be allocated accordingly by the		environment, then bandwidth can be allocated accordingly by the
	two domains to permit the transit of non-rate adaptive multicast		two domains to permit the transit of non-rate adaptive multicast
	traffic. If this is not the case, then it is recommended that the		traffic. If this is not the case, then it is recommended that the
	multicast traffic should support rate-adaption.		multicast traffic should support rate-adaption.
	c. The sending and receiving of multicast traffic between two domains		c. The sending and receiving of multicast traffic between two domains
	is typically determined by local policies associated with each		is typically determined by local policies associated with each
	domain. For example, if AD-1 is a service provider and AD-2 is an		domain. For example, if AD-1 is a service provider and AD-2 is an
	enterprise, then AD-1 may support local policies for traffic		enterprise, then AD-1 may support local policies for traffic
	delivery to, but not traffic reception from AD-2.		delivery to, but not traffic reception from AD-2. Another example
			is the use of a policy by which AD-1 delivers specified content
			to AD-2 only if such delivery has been accepted by contract.
	d. Relevant information on multicast streams delivered to End Users		d. Relevant information on multicast streams delivered to End Users
	in AD-2 is assumed to be collected by available capabilities in		in AD-2 is assumed to be collected by available capabilities in
	the application layer. The precise nature and formats of the		the application layer. The precise nature and formats of the
	collected information will be determined by directives from the		collected information will be determined by directives from the
	source owner and the domain operators.		source owner and the domain operators.
			e. The interconnection of AD-1 and AD-2 should minimally follow
			guidelines for traffic filtering between autonomous systems
			[BCP38]. Filtering guidelines specific to the multicast control-
			plane and data-plane are described in section 6.
	3.2. Peering Point Enabled with GRE Tunnel		3.2. Peering Point Enabled with GRE Tunnel
	The peering point is not native multicast enabled in this Use Case.		The peering point is not native multicast enabled in this Use Case.
	There is a Generic Routing Encapsulation Tunnel provisioned over the		There is a Generic Routing Encapsulation Tunnel provisioned over the
	peering point. In this case, the interconnection I1 between AD-1 and		peering point. In this case, the interconnection I1 between AD-1 and
	AD-2 in Figure 1 is multicast enabled via a Generic Routing		AD-2 in Figure 1 is multicast enabled via a Generic Routing
	Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast		Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast
	protocols across the interface. The routing configuration is		protocols across the interface. The routing configuration is
	basically unchanged: Instead of BGP (SAFI2) across the native IP		basically unchanged: Instead of BGP (SAFI2) across the native IP
	multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across		multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across
	skipping to change at page 19, line 17		skipping to change at page 19, line 17
	to that stream.		to that stream.
	o AMT Relay encapsulates the multicast stream into the tunnel		o AMT Relay encapsulates the multicast stream into the tunnel
	between the Relay and the Gateway, providing the requested content		between the Relay and the Gateway, providing the requested content
	to the EU.		to the EU.
	Note: Further routing discussion on optimal method to find "best AMT		Note: Further routing discussion on optimal method to find "best AMT
	Relay/GW combination" and information exchange between AD's to be		Relay/GW combination" and information exchange between AD's to be
	provided.		provided.
	4.3. Back Office Functions - Billing and Logging Guidelines		4.3. Back Office Functions - Provisioning and Logging Guidelines
	Back Office refers to the following:		Back Office refers to the following:
	o Servers and Content Management systems that support the delivery		o Servers and Content Management systems that support the delivery
	of applications via multicast and interactions between ADs.		of applications via multicast and interactions between ADs.
	o Functionality associated with logging, reporting, ordering,		o Functionality associated with logging, reporting, ordering,
	provisioning, maintenance, service assurance, settlement, etc.		provisioning, maintenance, service assurance, settlement, etc.
	4.3.1 Provisioning Guidelines		4.3.1 Provisioning Guidelines
	skipping to change at page 21, line 5		skipping to change at page 21, line 5
	o Automated interfaces are built between AD-1 and AD-2 such that		o Automated interfaces are built between AD-1 and AD-2 such that
	operations and customer care continue using their own systems. This		operations and customer care continue using their own systems. This
	requires coordination between the two AD's with appropriate		requires coordination between the two AD's with appropriate
	provisioning of necessary resources.		provisioning of necessary resources.
	o AD-1's operations and customer care personnel are provided access		o AD-1's operations and customer care personnel are provided access
	directly to AD-2's system. In this scenario, additional provisioning		directly to AD-2's system. In this scenario, additional provisioning
	in these systems will be needed to provide necessary access.		in these systems will be needed to provide necessary access.
	Additional provisioning must be agreed to by the two AD-2s to support		Additional provisioning must be agreed to by the two AD-2s to support
	this option.		this option.
	4.3.2 Application Accounting Billing Guidelines		4.3.2 Application Accounting Guidelines
	All interactions between pairs of ADs can be discovered and/or be		All interactions between pairs of ADs can be discovered and/or be
	associated with the account(s) utilized for delivered applications.		associated with the account(s) utilized for delivered applications.
	Supporting guidelines are as follows:		Supporting guidelines are as follows:
	o A unique identifier is recommended to designate each master		o A unique identifier is recommended to designate each master
	account.		account.
	o AD-2 is expected to set up "accounts" (logical facility generally		o AD-2 is expected to set up "accounts" (logical facility generally
	protected by login/password/credentials) for use by AD-1. Multiple		protected by login/password/credentials) for use by AD-1. Multiple
	accounts and multiple types/partitions of accounts can apply, e.g.		accounts and multiple types/partitions of accounts can apply, e.g.
	skipping to change at page 22, line 9		skipping to change at page 22, line 9
	The two ADs may supply additional security logs to each other as		The two ADs may supply additional security logs to each other as
	agreed to by contract(s). Examples include the following:		agreed to by contract(s). Examples include the following:
	o Information related to general security-relevant activity which		o Information related to general security-relevant activity which
	may be of use from a protective or response perspective, such as		may be of use from a protective or response perspective, such as
	types and counts of attacks detected, related source information,		types and counts of attacks detected, related source information,
	related target information, etc.		related target information, etc.
	o Aggregated or summarized logs according to agreement (with		o Aggregated or summarized logs according to agreement (with
	additional detail potentially provided during security events, by		additional detail potentially provided during security events, by
	agreement)		agreement)
	o
	4.4. Operations - Service Performance and Monitoring Guidelines		4.4. Operations - Service Performance and Monitoring Guidelines
	Service Performance refers to monitoring metrics related to		Service Performance refers to monitoring metrics related to
	multicast delivery via probes. The focus is on the service provided		multicast delivery via probes. The focus is on the service provided
	by AD-2 to AD-1 on behalf of all multicast application sources		by AD-2 to AD-1 on behalf of all multicast application sources
	(metrics may be specified for SLA use or otherwise). Associated		(metrics may be specified for SLA use or otherwise). Associated
	guidelines are as follows:		guidelines are as follows:
	o Both AD's are expected to monitor, collect, and analyze service		o Both AD's are expected to monitor, collect, and analyze service
	skipping to change at page 25, line 5		skipping to change at page 25, line 5
	monitoring functions or by customer reported problems as described		monitoring functions or by customer reported problems as described
	in section 4.4.		in section 4.4.
	It is expected that multicast diagnostics will be collected		It is expected that multicast diagnostics will be collected
	according to currently established practices [MDH-04]. However,		according to currently established practices [MDH-04]. However,
	given that inter-domain creates a significant interdependence of		given that inter-domain creates a significant interdependence of
	proper networking functionality between providers there does exist a		proper networking functionality between providers there does exist a
	need for providers to be able to signal/alert each other if there		need for providers to be able to signal/alert each other if there
	are any issues noted by either one.		are any issues noted by either one.
			Service providers may also wish to allow limited read-only
			administrative access to their routers via a looking-glass style
			router proxy to facilitate the debugging of multicast control state
			and peering status. Software implementations for this purpose is
			readily available [Traceroute] and can be easily extended to provide
			access to commonly-used multicast troubleshooting commands in a
			secure manner.
	The specifics of the notification and alerts are beyond the scope of		The specifics of the notification and alerts are beyond the scope of
	this document, but general guidelines are similar to those described		this document, but general guidelines are similar to those described
	in section 4.4 (Service Performance and Monitoring). Some general		in section 4.4 (Service Performance and Monitoring). Some general
	communications issues are stated as follows.		communications issues are stated as follows.
	o Appropriate communications channels will be established between		o Appropriate communications channels will be established between
	the customer service and operations groups from both AD's to		the customer service and operations groups from both AD's to
	facilitate information sharing related to diagnostic		facilitate information sharing related to diagnostic
	troubleshooting.		troubleshooting.
	skipping to change at page 25, line 30		skipping to change at page 25, line 38
	6. Security Considerations		6. Security Considerations
	DRM and Application Accounting, Authorization and Authentication		DRM and Application Accounting, Authorization and Authentication
	should be the responsibility of the multicast application source		should be the responsibility of the multicast application source
	provider and/or AD-1. AD-1 needs to work out the appropriate		provider and/or AD-1. AD-1 needs to work out the appropriate
	agreements with the source provider.		agreements with the source provider.
	Network has no DRM responsibilities, but might have authentication		Network has no DRM responsibilities, but might have authentication
	and authorization obligations. These though are consistent with		and authorization obligations. These though are consistent with
	normal operations of a CDN to insure end user reliability, security		normal operations of a CDN to insure end user reliability, security
	and network security		and network security.
	AD-1 and AD-2 should have mechanisms in place to ensure proper		AD-1 and AD-2 should have mechanisms in place to ensure proper
	accounting for the volume of bytes delivered through the peering		accounting for the volume of bytes delivered through the peering
	point and separately the number of bytes delivered to EUs.		point and separately the number of bytes delivered to EUs. For
			example, [BCP38] style filtering could be deployed by both AD's to
			ensure that only legitimately sourced multicast content is exchanged
			between them.
	If there are problems related to failure of token authentication		If there are problems related to failure of token authentication
	when end-users are supported by AD-2, then some means of validating		when end-users are supported by AD-2, then some means of validating
	proper working of the token authentication process (e.g., back-end		proper working of the token authentication process (e.g., back-end
	servers querying the multicast application source provider's token		servers querying the multicast application source provider's token
	authentication server are communicating properly) should be		authentication server are communicating properly) should be
	considered. Details will have to be worked out during implementation		considered. Details will have to be worked out during implementation
	(e.g., test tokens or trace token exchange process).		(e.g., test tokens or trace token exchange process).
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 26, line 40		skipping to change at page 27, line 5
	Protocol Version 3 (IGMPv3) and Multicast Listener Discovery		Protocol Version 3 (IGMPv3) and Multicast Listener Discovery
	Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604,		Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604,
	August 2006		August 2006
	[RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607,		[RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607,
	August 2006		August 2006
	[RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol",		[RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol",
	RFC 3618, October 2003		RFC 3618, October 2003
			[BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating
			Denial of Service Attacks which employ IP Source Address Spoofing",
			BCP: 38, May 2000
	9.2. Informative References		9.2. Informative References
	[INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a		[INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a
	Multi-Party Federation Environment", ATIS Standard A-0200010,		Multi-Party Federation Environment", ATIS Standard A-0200010,
	December 2012		December 2012
	[MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D		[MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D
	draft-ietf-mboned-mdh-04.txt, May 2000		draft-ietf-mboned-mdh-04.txt, May 2000
			[Traceroute] http://traceroute.org/#source%20code
	10. Acknowledgments		10. Acknowledgments
	Authors' Addresses		Authors' Addresses
	Percy S. Tarapore		Percy S. Tarapore
	AT&T		AT&T
	Phone: 1-732-420-4172		Phone: 1-732-420-4172
	Email: tarapore@att.com		Email: tarapore@att.com
	Robert Sayko		Robert Sayko
	AT&T		AT&T
End of changes. 19 change blocks.
	15 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/