Re: [MBONED] AD review of draft-ietf-mboned-interdomain-peering-bcp
"TARAPORE, PERCY S" <pt5947@att.com> Wed, 09 August 2017 22:00 UTC
Return-Path: <pt5947@att.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D397132496; Wed, 9 Aug 2017 15:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.401
X-Spam-Level:
X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY7BtHtELiRV; Wed, 9 Aug 2017 15:00:42 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCD9132380; Wed, 9 Aug 2017 15:00:42 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v79IomG1024198; Wed, 9 Aug 2017 14:51:32 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2c86kekh1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Aug 2017 14:51:32 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v79IpVwC003668; Wed, 9 Aug 2017 14:51:31 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v79IpJFT003489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Aug 2017 14:51:26 -0400
Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 9 Aug 2017 18:51:03 GMT
Received: from MISOUT7MSGUSRDG.ITServices.sbc.com ([169.254.7.47]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0319.002; Wed, 9 Aug 2017 14:51:02 -0400
From: "TARAPORE, PERCY S" <pt5947@att.com>
To: Warren Kumari <warren@kumari.net>, "draft-ietf-mboned-interdomain-peering-bcp@ietf.org" <draft-ietf-mboned-interdomain-peering-bcp@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
Thread-Topic: [MBONED] AD review of draft-ietf-mboned-interdomain-peering-bcp
Thread-Index: AQHTEQ++6gLonVSs9U+yUbpcsNt7J6J8XfpQ
Date: Wed, 09 Aug 2017 18:51:02 +0000
Message-ID: <ACC789373DA69C4285B9678D0CEBF86F12F8DD62@MISOUT7MSGUSRDG.ITServices.sbc.com>
References: <CAHw9_iKu2iLBv5tUt273LPuB31ONunVihwnB=TOTuTWypKWijw@mail.gmail.com>
In-Reply-To: <CAHw9_iKu2iLBv5tUt273LPuB31ONunVihwnB=TOTuTWypKWijw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.222.124]
Content-Type: multipart/mixed; boundary="_002_ACC789373DA69C4285B9678D0CEBF86F12F8DD62MISOUT7MSGUSRDG_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-09_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708090292
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/n-eKxttO3LII06fdA1Db0kk7Wbw>
Subject: Re: [MBONED] AD review of draft-ietf-mboned-interdomain-peering-bcp
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2017 22:00:54 -0000
Hi Warren, Text revisions are done and the latest draft has been successfully uploaded per attached email. Please go ahead and start the second breakfast (aka IETF LC). Thanks Percy -----Original Message----- From: MBONED [mailto:mboned-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Wednesday, August 09, 2017 9:01 AM To: draft-ietf-mboned-interdomain-peering-bcp@ietf.org; mboned@ietf.org Subject: [MBONED] AD review of draft-ietf-mboned-interdomain-peering-bcp Hi there, Apologies for the delay in getting this done. I've completed my AD review; the document looks good, other than a few small nits -- if you could spin a new version with these addressed (and let me know) I'll start the LC. While these are mostly just minor nits, having them dealt with now will make the process go much more smoothly... W 1. Introduction Content and data from several types of applications (e.g., live video streaming, software downloads) are well suited for delivery via multicast means. The use of multicast for delivering such content/data offers significant savings for utilization of resources [O] savings for utilization of resources [P] savings of utilization of resources [C] I think -- or perhaps "savings of resources" or "resource savings" in any given administrative domain. End user demand for such content/data is growing. Often, this requires transporting the content/data across administrative domains via inter-domain peering points. 2. Overview of Inter-domain Multicast Application Transport ... Note that domain 2 may be an independent network domain (e.g., Tier 1 network operator domain) or it could also be an Enterprise network [O] domain) or it [P] domain), or it [R] grammar [O]A comprehensive list of pertinent information that needs to be exchanged between the two domains to support various functions enabling the application transport is provided in section 4. [P] Section 4 contains a comprehensive list of pertinent information that needs to be exchanged between the two domains in order to support functions to enable the application transport. [R] readability 3.1. Native Multicast This Use Case involves end-to-end Native Multicast between the two administrative domains and the peering point is also native [O] domains and the [P] domains, and the [R] grammar c. The sending and receiving of multicast traffic between two domains is typically determined by local policies associated with each 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 delivery to, but not traffic reception from AD-2. [O] but not traffic reception from [P] but not traffic reception from, [R] grammar d. Relevant information on multicast streams delivered to End Users in AD-2 is assumed to be collected by available capabilities in the application layer. The precise nature and formats of the collected information will be determined by directives from the source owner and the domain operators. e. The interconnection of AD-1 and AD-2 should minimally follow [O] should minimally follow [P] should, at a minimum, follow [R] readability/I think this is what you mean 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 The peering point is not native multicast enabled in this Use Case. There is a Generic Routing Encapsulation Tunnel provisioned over the peering point. In this case, the interconnection I1 between AD-1 and AD-2 in Figure 1 is multicast enabled via a Generic Routing Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast protocols across the interface. The routing configuration is basically unchanged: Instead of BGP (SAFI2) across the native IP multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across the GRE tunnel. Advantages of this configuration: o Highly efficient use of bandwidth in both domains although not [O] domains although [P] domains, although [R] grammar -- or perhaps put the "although not..." bit in parens? as efficient as the fully native multicast Use Case. 3.3. Peering Point Enabled with an AMT - Both Domains Multicast Enabled Both administrative domains in this Use Case are assumed to be native multicast enabled here; however the peering point is not. The [O] here; however the [P] here; however, the [R] grammar 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled In this AMT Use Case, the second administrative domain AD-2 is not multicast enabled. This implies that the interconnection between AD- 2 and the End User is also not multicast enabled as depicted in Figure 3. [O] is also not multicast enabled as depicted in Figure 3. [R] ? this is ambiguous; it can be read that Figure 3 depicts the End User as multicast enabled, but I don't think this is what is meant. 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 This is a variation of Use Case 3.4 as follows: ... The advantage for such a chained set of AMT tunnels is that the total number of unicast streams across AD-2 is significantly reduced thus freeing up bandwidth. Additionally, there will be a single [O] reduced thus freeing up bandwidth. [P] reduced, thus freeing up bandwidth. [R] grammar unicast stream across the peering point instead of possibly, an [O] instead of possibly, an [P] instead of, possible, an [R] grammar unacceptably large number of such streams per Use Case 3.4. However, this implies that several AMT tunnels will need to be dynamically configured by the various AMT Gateways based solely on the (S,G) information received from the application client at the EU device. A suitable mechanism for such dynamic configurations is therefore critical. 4. Supporting Functionality Supporting functions and related interfaces over the peering point that enable the multicast transport of the application are listed in this section. Critical information parameters that need to be exchanged in support of these functions are enumerated along with [O] enumerated along with [P] enumerated, along with [R] grammar/readability guidelines as appropriate. Specific interface functions for consideration are as follows. 4.1. Network Interconnection Transport and Security Guidelines ... o Bandwidth Allocation - If shared with other services, then there needs to be a determination of the share of bandwidth reserved for multicast delivery. When determining the appropriate bandwidth allocation, parties should consider that design of a multicast protocol suitable for live video streaming which is consistent with Congestion Control Principles [BCP41], especially in the presence of potentially malicious receivers, is still an open research problem. [R] Difficult to parse the above sentence. I *think* that parens around the "especially in the presence" bit, but even so it seems like it could be reworded to be less run-on... 4.2. Routing Aspects and Related Guidelines The main objective for multicast delivery routing is to ensure that the End User receives the multicast stream from the "most optimal" source [INF_ATIS_10] which typically: o Maximizes the multicast portion of the transport and minimizes any unicast portion of the delivery, and o Minimizes the overall combined network(s) route distance. This routing objective applies to both Native and AMT; the actual methodology of the solution will be different for each. Regardless, the routing solution is expected to be: [O] expected to be: [P] expected: [R] second and third bullet don't make sense if prefaced with "expected to be: o Scalable, [O] Scalable, [P] To be scalable, [R] consistency with list preface o Avoid/minimize new protocol development or modifications, and [O] Avoid/minimize [P] To avoid/minimize [R] consistency with list preface o Be robust enough to achieve high reliability and automatically adjust to changes/problems in the multicast infrastructure. For both Native and AMT environments, having a source as close as possible to the EU network is most desirable; therefore, in some cases, an AD may prefer to have multiple sources near different peering points, but that is entirely an implementation issue. [O] points, but that is entirely an implementation issue. [P] points. However, that is entirely an implementation issue. [R] grammar -- run-on sentence. 4.2.1 Native Multicast Routing Aspects Native multicast simply requires that the Administrative Domains coordinate and advertise the correct source address(es) at their network interconnection peering points(i.e., border routers). An example of multicast delivery via a Native Multicast process across two administrative Domains is as follows assuming that the [O] administrative Domains is as follows assuming that [P] Administrative Domains is as follows, assuming that [R] consistency and grammar interconnecting peering points are also multicast enabled: o Appropriate information is obtained by the EU client who is a subscriber to AD-2 (see Use Case 3.1). This information is in the form of metadata and it contains instructions directing the EU client to launch an appropriate application if necessary, and also additional information for the application about the source [O] and also additional [P] as well as [R] readability 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 source of the multicast stream. The metadata may also contain alternate delivery information such as specifying the unicast address of the stream. 4.2.3 Routing Aspects with AMT Tunnels Unlike Native (with or without GRE), an AMT Multicast environment is [O] Unlike Native (with or without GRE), [R] unless "Native" is a known noun, we need to add a noun or other context -- I think you mean Unlike Native Multicast ? But, I'm not really sure... each requesting endpoint within the unicast-only network. o AMT Gateway (GW): The Gateway will reside on an on End-Point - [O] End-Point [R] consistency. Sometimes this is End-Point, sometimes end point, sometimes endpoint; pick one and apply throughout. ... [O] The two ADs can coordinate and advertise special AMT Relay Anycast addresses with each other - though they may alternately decide to simply provision Relay addresses, though this would not be an optimal solution in terms of scalability. [P] The two ADs can coordinate and advertise special AMT Relay Anycast addresses with each other. Alternately, they may decide to simply provision Relay addresses, although this would not be an optimal solution in terms of scalability. [R] readability. Also: ADs is sometimes AD's in this document. Pick one. Use Cases 3.4 and 3.5 describe more complicated AMT situations as AD-2 is not multicast enabled. For these cases, the End User device needs to be able to setup an AMT tunnel in the most optimal manner. There are many methods by which relay selection can be done [O] can be done [P] can be done, [R] grammar including the use of DNS based queries and static lookup tables [RFC7450]. The choice of the method is implementation dependent and is up to the network operators. Comparison of various methods is out of scope for this document; it is for further study. 4.3.1 Provisioning Guidelines Native multicast functionality is assumed to be available across many ISP backbones, peering and access networks. If however, native [O] If however, native [P] If, however, native [R] grammar multicast is not an option (Use Cases 3.4 and 3.5), then: o EU must have multicast client to use AMT multicast obtained either from Application Source (per agreement with AD-1) or from AD-1 or AD-2 (if delegated by the Application Source). o If provided by AD-1/AD-2, then the EU could be redirected to a client download site (note: this could be an Application Source site). If provided by the Application Source, then this Source ... o Automated interfaces are built between AD-1 and AD-2 such that operations and customer care continue using their own systems. This requires coordination between the two AD's with appropriate [O] AD's [R] per above: ADs or AD's; consistency provisioning of necessary resources. o AD-1's operations and customer care personnel are provided access directly to AD-2's system. In this scenario, additional provisioning in these systems will be needed to provide necessary access. Additional provisioning must be agreed to by the two AD-2s [O] by the two AD-2s [P] by the two ADs [R] I think this is what is meant, but am not sure.... to support this option. 4.4. Operations - Service Performance and Monitoring Guidelines ... Service Monitoring generally refers to a service (as a whole) provided on behalf of a particular multicast application source provider. It thus involves complaints from End Users when service problems occur. EU's direct their complaints to the source provider; [O] EU's [P] EUs [R] Consistency and not possessive. 5. Troubleshooting and Diagnostics ... It is expected that multicast diagnostics will be collected according to currently established practices [MDH-04]. However, given that inter-domain creates a significant interdependence of [O] inter-domain creates [P] inter-domain multicast create [R] I think multicast was intended (could be networking!), but some noun is needed after inter-domain proper networking functionality between providers there does exist a need for providers to be able to signal/alert each other if there are any issues noted by either one. 6. Security Considerations From a security perspective, normal security procedures are expected to be followed by each AD to facilitate multicast delivery to registered and authenticated end users. Additionally: o Encryption - Peering point links may be encrypted per agreement if dedicated for multicast delivery. [C]: Only if dedicated for multicast? I'd think remove "if dedicated..." - it's allowed for me to encrypt other stuff too. o Security Breach Mitigation Plan - In the event of a security breach, the two AD's are expected to have a mitigation plan for shutting down the peering point and directing multicast traffic over alternated peering points. It is also expected that appropriate information will be shared for the purpose of securing the identified breach. [O]: over alternated peering points [P]: over alternative peering points (or other) [C]: Alternated sounds like I'm going to start doing per-packet LB across 2 other points :-P DRM and Application Accounting, Authorization and Authentication should be the responsibility of the multicast application source provider and/or AD-1. AD-1 needs to work out the appropriate agreements with the source provider. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ MBONED mailing list MBONED@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=iyleYj4TpgkRZtlkCSYg-4IWF_Wnm0v5nM7UIF5DrUM&s=2zOd0gS_NTiA6xz_B3jqbm7S2htDRFkLV-W5OG-QtnE&e=
--- Begin Message ---A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment WG of the IETF. Title : Use of Multicast Across Inter-Domain Peering Points Authors : Percy S. Tarapore Robert Sayko Greg Shepherd Toerless Eckert Ram Krishnan Filename : draft-ietf-mboned-interdomain-peering-bcp-10.txt Pages : 30 Date : 2017-08-09 Abstract: 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. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=X72Bp_tDn9I0DP8Wj2U9NSRev1oWYO3rWvsxxS1OhkU&s=FZWIJe8iGjtOADjQ65xz-bf5e3arI6HdYfD9LzoaXcI&e= There are also htmlized versions available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp-2D10&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=X72Bp_tDn9I0DP8Wj2U9NSRev1oWYO3rWvsxxS1OhkU&s=VUunQYwTKXrz0Fva0UCQGDVspu4MIfl5FA83YEx559U&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp-2D10&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=X72Bp_tDn9I0DP8Wj2U9NSRev1oWYO3rWvsxxS1OhkU&s=D4Cv9sK7fpoGlTSglm98_I0ko9mjGxoITAyC9MFdQGA&e= A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp-2D10&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=X72Bp_tDn9I0DP8Wj2U9NSRev1oWYO3rWvsxxS1OhkU&s=RZ0IDcauCc58MEgiEElZKOVTYxSWdclfNZ_z3NAvXwo&e= Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=X72Bp_tDn9I0DP8Wj2U9NSRev1oWYO3rWvsxxS1OhkU&s=GMj8xR1WdTwXLeTdb0VC3hXJSrauECnhzRoB0cXkLZ0&e= _______________________________________________ MBONED mailing list MBONED@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=sxTP_OScWsg-eIMvImIlmQ&m=X72Bp_tDn9I0DP8Wj2U9NSRev1oWYO3rWvsxxS1OhkU&s=EvShGD0LRjT9Sx2MiDPM5NEowkDuMRpTO5DaTzpkr5E&e=--- End Message ---
- [MBONED] AD review of draft-ietf-mboned-interdoma… Warren Kumari
- Re: [MBONED] AD review of draft-ietf-mboned-inter… Warren Kumari
- Re: [MBONED] AD review of draft-ietf-mboned-inter… TARAPORE, PERCY S
- Re: [MBONED] AD review of draft-ietf-mboned-inter… TARAPORE, PERCY S