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

[Toerless Eckert <[e-mail]>]

[The following text up to the individual reply comments is identical for 
 the replies to all ballot comments. I originally wanted to coalesce the reply to
 all positions into one email but the auto-generated header from datatracker
 makes it sound as if per-submitter replied are required. So, here we go with some
 repeated text followed by more individualized text:]

Dear Reviewer,

This is in response of your reviews of
    https://www.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-11.txt
as entered in the ballot:
    https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/ballot/

A version of this email containing replies to all IESG feedback for -11 is also in: 
    https://raw.githubusercontent.com/toerless/peering-bcp/master/11-iesg-review-reply.txt

Thank you so much for your thorough review. In response to the IESG
feedback, version -12 and -13 of the draft where posted which we hope 
will resolve the open issues.
make 2

Version -12 of the draft was just a conversion from docx generated txt to XML (previous generations
where not built from XML), this introduced formatting changes (line wraps etc.) that rfcdiff can not ignore
and that would have obfuscated actual content changes. 

Version -13 of the draft contains the text changes done in response to your
comments and discusses. The following RFC diff shows the content diffs
vs. -11 without any formatting introduced changes:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-12.txt&url2=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-13.txt

In summary:
   Beside the various smaller fixups from comments, the mayor rewritten/new blocks are:

   4.1.1 - bandwidth management (aka: congestion control section). 
           I didn't just want to put the magic CC sentence in but wanted to let
           readers understand what it means in the context of specifically
   6. Security considerations
      6.1.  DoS attacks (against state and bandwidth)	
      6.2.  Content security	
      6.3.  Peering encryption
      6.4.  Operational Aspects
            This is where the securing of log exchange is discussed.
   7. Privacy Considerations
      Got somewhat longer to explain because the specifics of multicast content and privacy
      are likely not that obious to non-multicast  experienced readers, and given how this
      is a BCP and i don't even think we did describe this anywhere else, it had to be
      explanatory.
   
   4.2.4.  Public Peering Routing Aspects
      text did mention non-private peerings, but i was afraid that readers would not
      understand the problematic implications, so i detailled them given how those
      peering L2 domains are still common for unicast.

Cheers
    Toerless for the Authors

====================================================================================
Spencer Dawkins

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

Changed to:

        <t>The rest of the document assumes that PIM-SSM and BGP are used across
         the peering point plus AMT and/or GRE according to scenario. The use
         of other protocols is beyond the scope of this document.</t>
> 
> 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"

Fixed this type, but will definitely do another spell checker after getting
approval to go through IESG, so lets not worry too much about typos.

Lower cased all MUST/SHOULD/MAY (where only few).

I think the use of the word "recommend" is in general ok. In the case
above, this was immediately preceeding the now fixed text where
i am using "assume". So i hope this solves the point you raised. 

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

Yes, Fixed.

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

Muchas Gracias, change applied as suggested.

Hey, how can i get more ADs that give me suggested solutions instead of raising just problems for me to solve ? 
(kidding, all input welcome)

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

I removed that paragraph because this applies to all scenarios anyhow,
and because BCP38 is really only a necessary ad-on consideration for
unicast. Instead section 7.1 second paragraph now explains how RPF
forwarding is part of PIM-SM/SSM and therefore provides equivalent
protection to BCP38.

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

;-) I actually didn't write that point and i do not agree that it is
much of a problem in the deployment scenario, but it was a consensus
between authors to have it. IMHO the likelyhood that in this setup the
GRE tunnel is at times not used at all is fairly low. You wouldn't bother
about setting up this tunnel in the first place if it wasn't expected
to be used regularily. And its not per-user, so little state wasted even
if it is unused.

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

No, not really. We discussed DNS but didn't make progress with that
draft yet. I think that short term deployments can quickly solve
those problems with simple SDN style automation though and then
standardize.