Use of Multicast across Inter-domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-14

I support Alissa's and Kathleen's DISCUSSes; and (as a separate concern), I support Ben's DISCUSS.

Most of the comments I noted in my review of this document have been made by other reviewers, and I will not reiterate most of them. I would, however, like to draw particular attention to Ben's comments regarding charging, billing, and settlement -- I believe these issues should either be fleshed out in significantly more detail, or removed (with a simple statement in the introduction that such issues are generally out of scope for the entire document).

___

Section 4.2.3 contains the following text:

    (Note
     that in IPv6 there is a specific Anycast format and Anycast is
     inherent in IPv6 routing, whereas in IPv4 Anycast is handled via
     provisioning in the network. Details are out of scope for this
     document.)

It would be helpful to the reader if the "out of scope" statement were accompanied by a pointer to BCP 126/RFC 4786.

___

Section 5 contains the following text:

   It is expected that multicast diagnostics will be collected
   according to currently established practices [MDH-04].

I believe this statement makes [MDH-04] normative, as it is required to understand its contents to implement the recommendations in this BCP.

Thank for addressing my DISCUSS and COMMENTs.

Thanks for addressing my DISCUSS point.

As a new editorial comment, I note that there are a few other mentions of "location" in the draft. It might be helpful to qualify those as "network location". But this is not a show stopper, since you did qualify it in the authoritative mention.

I support Kathleen's and Alissa's discusses

I'm concerned about whether the practices described adequately capture the notion of user consent to receive the data. Specifically, we're talking about sending large streams of data to people. Do the protocols in question adequately ensure that the addresses in question wish to receive the data. Specifically, the issue I am concerned with is whether I can cause you to get a large video stream. I'm filing this as a Comment rather than a Discuss because it doesn't seem like an issue for this BCP but rather for the protocols it documents.

Please define S,G at first use.

Thanks for addressing my prior discuss and comments.

Thanks for addressing my discuss and providing a detailed section on congestion control. And thanks Yoshi for the TSV-ART review again!

-----------------------------
Old questions/comments:

1) Section 3.4 also says:
"Highly efficient use of bandwidth in AD-1."
But aren't packets eventually duplicated in this case in AD-1? I guess it's more efficient than replicating them at the network border but might be still less efficient than native multicast in the whole network, no?

2) section 4.3.3 says:
"The two AD's may supply additional security logs..."
This seems to be a general action not specific to multicast or the scenarios described in this doc.

3) I don't think the conclusion section (8) is helpful or needed. If you want to keep it at all, this text could be moved into the introduction.

Thanks for doing this work.

I have comments, but they're all editorial.

In this text,

     o AD-1 and AD-2 are assumed to adopt compatible protocols. The
         use of different protocols is beyond the scope of this
         document.

"compatible protocols" isn't helpful without some context. Is this talking about "compatible multicast protocols", or complete protocol stacks from IP on up, or something else?

I'm also noticing that the terms "should" and "recommended" appear a few times in this document. This is a BCP and doesn't reference BCP 14, which is all fine, but the wording is likely to lead readers in one direction. I wonder if it's helpful to say these things differently, so that (for instance)

         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.

might become

         Hence, this document assumes that in the case of inter-domain 
         peering, only SSM protocols are used; the setup of inter-
         domain peering for ASM (Any-Source Multicast) is not in scope
         for this document.

Nit: "out of cope"

This text,

        packet streams will be part of a suitable
        multicast transport protocol.

didn't parse for me - was it saying

       packet streams will be carried by a suitable
       multicast transport protocol.

or something else?

In this text,

  Note that domain 2 may be an independent network domain (e.g., Tier
   1 network operator domain). Alternately, domain 2 could also be an
   Enterprise network domain operated by a single customer. The peering
   point architecture and requirements may have some unique aspects
   associated with the Enterprise case.

  The Use Cases describing various architectural configurations for
   the multicast distribution along with associated requirements is
   described in section 3. Unique aspects related to the Enterprise
   network possibility will be described in this section. 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.

it wasn't easy for me to tie "some unique aspects" in the first paragraph to "will be described in this section" in the second - if the last sentence in the first paragraph was moved to be the second paragraph, so the text was 

  Note that domain 2 may be an independent network domain (e.g., Tier
   1 network operator domain). Alternately, domain 2 could also be an
   Enterprise network domain operated by a single customer. 

  The Use Cases describing various architectural configurations for
   the multicast distribution along with associated requirements is
   described in section 3. The peering
   point architecture and requirements may have some unique aspects
   associated with the Enterprise case. These unique aspects will be
   described in this section. 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.

that would have been easier for me to follow. It's also worth mentioning that I'm guessing that "section 3" is "this section" in that text, and I'm pretty sure "this section" isn't "section 2", which is actually where the sentence appears, but it might be easier for the reader to say "will also be described in section 3".

The first sentence in 

     e. The interconnection of AD-1 and AD-2 should, at a minimum,
        follow guidelines for traffic filtering between autonomous
        systems [BCP38]. Filtering guidelines specific to the multicast
        control-plane and data-plane are described in section 6.

just seems odd ("this BCP says you should do that BCP"). ISTM that if there are multicast-specific reasons to do BCP38 in addition to the usual reasons, that would be a fine thing to say here, of course.

If your audience doesn't already know 

     o The GRE tunnel is often left pinned up.

(and if they don't, thank you for telling them), you might want to add a few words explaining why that's a disadvantage.

In this text,

  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 unicast stream across the peering point instead of possibly,
   an 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.

is there a good reference for "suitable mechanism(s)"?