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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> wrote:

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