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

[Warren Kumari <[e-mail]>]

On Wed, Aug 9, 2017 at 2:51 PM, TARAPORE, PERCY S <[e-mail]> wrote:
> 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).

"Last call requested

Your request to issue the last call has been submitted to the secretariat.

Note that the last call will not actually go out until the secretariat
takes appropriate steps. This may take up to one business day, as it
involves a person taking action."

Thanks,
W

>
> Thanks
>
> Percy
>
>
>
> -----Original Message-----
> From: MBONED [mailto:[e-mail]] On Behalf Of Warren Kumari
> Sent: Wednesday, August 09, 2017 9:01 AM
> To: [e-mail]; [e-mail]
> 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
> [e-mail]
> 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=
>
>
> ---------- Forwarded message ----------
> From: "[e-mail]" <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Bcc:
> Date: Wed, 9 Aug 2017 18:46:23 +0000
> Subject: [MBONED] I-D Action: draft-ietf-mboned-interdomain-peering-bcp-10.txt
>
> 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
> [e-mail]
> 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=
>



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