Re: [MBONED] Mirja K?hlewind's No Objection on draft-ietf-mboned-interdomain-peering-bcp-11: (with COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Toerless,

thanks for addressing my discuss in such detail. The new text is great. Maybe one little change:

OLD:
   Like IP unicast traffic, IP multicast traffic carried across non-
   controlled networks must comply to Congestion Control Principles...
NOW
   Like IP unicast traffic, IP multicast traffic carried across non-
   controlled networks MUST comply to Congestion Control Principles…

Also I would still like to see that the respective text in section 3.1 is slightly rephrased to match this:

OLD:
      b. If the peering point between AD-1 and AD-2 is a controlled
        network environment, then bandwidth can be allocated
        accordingly by the two domains to permit the transit of non-
        rate adaptive multicast traffic. If this is not the case, then
        it is recommended that the multicast traffic should support
        rate-adaption.
Proposed NEW:
      b. If the peering point between AD-1 and AD-2 is a controlled
        network environment, then bandwidth can be allocated
        accordingly by the two domains to permit the transit of non-
        rate adaptive multicast traffic. If this is not the case, then
        the multicast traffic MUST also support rate-adaption.

Thanks!
Mirja



> Am 28.10.2017 um 02:05 schrieb 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
> 
> =====================================================================================
> Mirja Kuehlewind:
> 
> 
>> Sorry for this last minute discuss but I would like to emphasize the points made in the tsv-art review on congestion/rate control (Thanks Yoshi!):
> 
>> Please provide stronger guidance (MUST) on the use of rate/congestion control in these two cases:
>> 
>> In Section 3.1:
>>    " If the peering point between AD-1 and AD-2 is a controlled
>>   network environment, then bandwidth can be allocated
>>   accordingly by the two domains to permit the transit of non-
>>   rate adaptive multicast traffic. If this is not the case, then
>>   it is recommended that the multicast traffic should support
>>   rate-adaption."
>> 
>> In Section 4.1,
>>     "When determining the appropriate bandwidth allocation, parties should consider use
>>       of a multicast protocol suitable for live video streaming that
>>       is consistent with Congestion Control Principles [BCP41]."
> 
> I tried to fix this text a bit more comprehensively:
> - removed text from 3.1. The CC requirements apply to every subsection of 3 (3.x)
>  and it duplicates partial text in 4.1, so a random mentioning in 3.1 was not
>  helpfull.
> - Moved CC text from 4.1 to dedicated section 4.1.1 and made it a lot more explanatory
>  because in my past experience most readers do not really understand our cryptic
>  rules alone ("CC principles across non-controlled network paths"). Also added
>  reference to the fresh BCP145.
> 
> Please re-read new section and let me know what you think.
> 
>> Minor 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?
> 
> Changed to:
>  <t>Efficient use of bandwidth in AD-1 (The closer AR is to uBR, the more efficient).</t>
> 
>> 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.
> 
> Yes, i thought about this and came up with the following explanation:
> 
>   <t>Note that except for implied multicast specific elements,
>   the options listed here are not unique or novel for IP multicast, but
>   they are more important for services novel to the operators than for
>   operationally well established services (such as unicast).  Therefore
>   we detail them as follows:</t>
> 
>> 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.
> 
> Removed - for the time being. I was told that having a wrap up in documents is
> always a good way to reflect on the document, but i agree the existing text
> is more distracting than helpful.
>