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 ---