[MBONED] AD review of draft-ietf-mboned-interdomain-peering-bcp

Warren Kumari <warren@kumari.net> Wed, 09 August 2017 13:02 UTC

Return-Path: <warren@kumari.net>
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 EEFDE131CCF for <mboned@ietfa.amsl.com>; Wed, 9 Aug 2017 06:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 ogrKWG5945V4 for <mboned@ietfa.amsl.com>; Wed, 9 Aug 2017 06:02:10 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC3C13239D for <mboned@ietf.org>; Wed, 9 Aug 2017 06:02:07 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id u133so25218570vke.3 for <mboned@ietf.org>; Wed, 09 Aug 2017 06:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=H9kMEYn488OLyHaE8J2lnJPTFiMrjjLEFcuhCgZ5f5I=; b=FJgcka1JVLCt/ILjLJw++q4adgXoNl0bgSyGU3FOT37cEwF6aTNQ0yxQgD0A+5tTvf x23Fb/ccDSx76pWkTC/Aq6fvFuC5z34hObmAv5JZQhUGabR4YlQuMNbSzSdRs5R62AsB R3UpqjT3YxUGA6OatWhaipkpCMb0RdKg1ofkQufT1ruV2me+QoF4/GXOyozSUedzCHeQ Vgz4yzKnfSU2lGnkNSKevGfbvqJ7HoETbs4VbWWWNPZyPfekG/rcNbAnnalNiv6dF9R1 tG5vm/8UssN45zzYAyOg3yZfm8HdkI3U1j4ZBW8KKwPylp+CH505ZFqo9ZVwphwAe+d0 HW8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H9kMEYn488OLyHaE8J2lnJPTFiMrjjLEFcuhCgZ5f5I=; b=cPBLua4YhkaQRo8J+iA+sHxhvORZDAMmmnvcSOlFdnMWfXbYl5YeBNpLZMeVAKtHq2 0SW8HBjVYJAVJDFXG2hnaX4uK54HKduqqTz9vqDhfcOEwJS3G+Dr8/AaIxjhDjw9JfzZ xFF8/T6VC398vs51hZXW8id4t18hIxKTFXUaLd85pRhAqPoK7aU+bTO0d1Mz+RiukcwV NqlwtCdgXdBZ7p97MrKh4693ruTpTsZ9opMhoyOnFOJWhno2InEZFScw5B3UsllZFZzO GPeAGTUlRYonCRM2NgMW/xVeXp/N6D4she4kNomO1gDDxFgOZAws2diG7c2FjcjBWWPG vskg==
X-Gm-Message-State: AHYfb5hBi2PnZTrBXPTpmhmJry5kv1W+GWPJoL1iReo52Almqrwp7RMe IwQ7ZMgynFWgty5F43QW8v8WYvRIzRSU
X-Received: by 10.31.67.19 with SMTP id q19mr5497742vka.115.1502283726240; Wed, 09 Aug 2017 06:02:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.9.231 with HTTP; Wed, 9 Aug 2017 06:01:25 -0700 (PDT)
From: Warren Kumari <warren@kumari.net>
Date: Wed, 09 Aug 2017 09:01:25 -0400
Message-ID: <CAHw9_iKu2iLBv5tUt273LPuB31ONunVihwnB=TOTuTWypKWijw@mail.gmail.com>
To: draft-ietf-mboned-interdomain-peering-bcp@ietf.org, mboned@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/hnpoYkQ1r_nBNK50G0Q_VSsOf_g>
Subject: [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 13:02:13 -0000

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