1. Percy S. Tarapore, AT&T Robert Sayko, AT&T
Use of Multicast Across Inter-Domain Peering Points Last Call #5: Comments & Responses
Percy S. Tarapore, AT&T
Robert Sayko, AT&T

2. IETF 97 – Seoul, South Korea
Last Call #4 Summary
Several clarifications on technical statements based on inputs from Hitoshi, Tim, Lenny, Mikael, Jake.
Changes include:
Removal of “manifest file” texts
Scope limited to SSM only
Authentication location: Done at application layer independent of AD-2
References
Draft-ietf-mboned-interdomain-peering-bcp-05 uploaded September 30
Last Call 5 initiated October 28
November 14, 2016
IETF 97 – Seoul, South Korea

3. Last Call #5 Comments Comment 1 from Hitoshi: Revision:
Wrong RFCs in Section 2
Revision:
It is understood that several protocols are available for this purpose including PIM-SM [RFC4609], Protocol Independent Multicast - Source Specific Multicast (PIM-SSM) [RFC4607RFC7761], Internet Group Management Protocol (IGMP) [RFC4604RFC3376], and Multicast Listener Discovery (MLD) [RFC4604RFC3810].
July 18, 2016
IETF 96 – Berlin, Germany

4. Last Call #5 Comments Comment 2 (Mikael): Revision:
Add SSM only as scope in Abstract
Revision:
This document examines the use of Source Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objective is to describe the setup process for multicast-based delivery across administrative domains for these scenarios and document supporting functionality to enable this process.
July 18, 2016
IETF 96 – Berlin, Germany

5. Last Call #5 Comments
Comment 3 from Mikael: Add stronger emphasis on SSM as part of scope
Revision: Text added in Section 2 to provide emphasis:
Hence, in the case of inter-domain peering, it is recommended to use only SSM protocols.; the setup of inter-domain peering for ASM (Any-Source Multicast) is not in scope for this document.
July 18, 2016
IETF 96 – Berlin, Germany

6. Last Call #5 Comments Comment 4 from Mikael:
Exchange of multicast over public Internet exchange point (shared domain by many operators) out of scope
Paragraph added in Section 2:
Thus, the primary purpose of this document is to describe a scenario where two ADs interconnect via a direct connection to each other. Security and operational aspects for exchanging traffic on a public Internet Exchange Point (IXP) with a large shared broadcast domain between many operators, is not in scope for this document.
July 18, 2016
IETF 96 – Berlin, Germany

7. Last Call #5 Comments Comment 5 (Mikael): Revision: Minor Nits
Removed “(Other)” from text in Section 4.2.1
Added periods and commas in bullet points throughout document
July 18, 2016
IETF 96 – Berlin, Germany

8. Next Steps
Revised draft with diff-marked changes submitted to mailing list for review in Last Call #5
Responses from Mikael & Hitoshi: OK
Proposal:
These changes are editorial
Complete Last Call????
July 18, 2016
IETF 96 – Berlin, Germany