[MBONED] Spencer Dawkins' No Objection on draft-ietf-mboned-interdomain-peering-bcp-11: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-mboned-interdomain-peering-bcp-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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)"?