draft-ietf-mboned-interdomain-peering-bcp-02.txt   draft-ietf-mboned-interdomain-peering-bcp-03.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: July 20, 2016 Greg Shepherd Expires: December 1, 2016 Greg Shepherd
Toerless Eckert Toerless Eckert
Cisco Cisco
Ram Krishnan Ram Krishnan
Brocade Brocade
March 21, 2016 June 1, 2016
Use of Multicast Across Inter-Domain Peering Points Use of Multicast Across Inter-Domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-02.txt draft-ietf-mboned-interdomain-peering-bcp-03.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 July 21, 2016. This Internet-Draft will expire on December 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
| | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU |
| | | +------+ | I1 | +------+ |I2 +----+ | | | +------+ | I1 | +------+ |I2 +----+
\ +----+ / \ / \ +----+ / \ /
\ / \ / \ / \ /
\ / \ / \ / \ /
------------------- ------------------- ------------------- -------------------
AD = Administrative Domain (Independent Autonomous System) AD = Administrative Domain (Independent Autonomous System)
AS = Application (e.g., Content) Multicast Source AS = Application (e.g., Content) Multicast Source
BR = Border Router BR = Border Router
I1 = AD-1 and AD-2 Multicast Interconnection (MBGP or BGMP) I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP or BGMP)
I2 = AD-2 and EU Multicast Connection I2 = AD-2 and EU Multicast Connection
Figure 1 - Content Distribution via End to End Native Multicast Figure 1 - Content Distribution via End to End Native Multicast
Advantages of this configuration are: Advantages of this configuration are:
o Most efficient use of bandwidth in both domains o Most efficient use of bandwidth in both domains
o Fewer devices in the path traversed by the multicast stream when o Fewer devices in the path traversed by the multicast stream when
compared to unicast transmissions. compared to unicast transmissions.
skipping to change at page 14, line 42 skipping to change at page 14, line 42
needs to be a determination of the share of bandwidth reserved needs to be a determination of the share of bandwidth reserved
for multicast delivery. for multicast delivery.
o QoS Requirements - Delay/latency specifications that need to be o QoS Requirements - Delay/latency specifications that need to be
specified in an SLA. specified in an SLA.
o AD Roles and Responsibilities - the role played by each AD for o AD Roles and Responsibilities - the role played by each AD for
provisioning and maintaining the set of peering points to support provisioning and maintaining the set of peering points to support
multicast delivery. multicast delivery.
o
4.2. Routing Aspects and Related Guidelines 4.2. Routing Aspects and Related Guidelines
The main objective for multicast delivery routing is to ensure that The main objective for multicast delivery routing is to ensure that
the End User receives the multicast stream from the "most optimal" the End User receives the multicast stream from the "most optimal"
source [INF_ATIS_10] which typically: source [INF_ATIS_10] which typically:
o Maximizes the multicast portion of the transport and minimizes o Maximizes the multicast portion of the transport and minimizes
any unicast portion of the delivery, and any unicast portion of the delivery, and
o Minimizes the overall combined network(s) route distance. o Minimizes the overall combined network(s) route distance.
skipping to change at page 15, line 48 skipping to change at page 15, line 48
the manifest file. It contains instructions directing the EU the manifest file. It contains instructions directing the EU
client to launch an appropriate application if necessary, and client to launch an appropriate application if necessary, and
also additional information for the application about the source also additional information for the application about the source
location and the group (or stream) id in the form of the "S,G" location and the group (or stream) id in the form of the "S,G"
data. The "S" portion provides the name or IP address of the data. The "S" portion provides the name or IP address of the
source of the multicast stream. The file may also contain source of the multicast stream. The file may also contain
alternate delivery information such as specifying the unicast alternate delivery information such as specifying the unicast
address of the stream. address of the stream.
o The client uses the join message with S,G to join the multicast o The client uses the join message with S,G to join the multicast
stream [RFC2236]. stream [RFC4604].
To facilitate this process, the two AD's need to do the following: To facilitate this process, the two AD's need to do the following:
o Advertise the source id(s) over the Peering Points o Advertise the source id(s) over the Peering Points
o Exchange relevant Peering Point information such as Capacity and o Exchange relevant Peering Point information such as Capacity and
Utilization (Other??) Utilization (Other??)
o Implement compatible multicast protocols to ensure proper o Implement compatible multicast protocols to ensure proper
multicast delivery across the peering points. multicast delivery across the peering points.
 End of changes. 7 change blocks. 
8 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/