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

From: Spencer Dawkins <[email-masked]>
Date: Tue, 10 Oct 2017 14:30:49 -0700

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

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 28 Oct 2017 02:06:08 +0200

[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

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

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. 

>        multicast transport protocol.

Yes, Fixed.

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

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

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

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 29 Oct 2017 22:50:55 -0500

Hi, Toerless,

Tl;dr - thanks for working through my comments. I'm good.

Spencer

On Fri, Oct 27, 2017 at 7:06 PM, Toerless Eckert <[email-masked]> wrote:

> 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:
> > "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:
>
> > 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)
> >
> > 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
> >
> > 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".
>
> > 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.
>
> > (and if they don't, thank you for telling them), you might want to add a
> few words explaining why that's a disadvantage.
>