Re: [MBONED] draft-ietf-mboned-interdomain-peering-bcp-00.txt comments

["TARAPORE, PERCY S" <[e-mail]>]

Thanks Dale,

We will revise the BCP accordingly. The deadline for uploading drafts for the November meeting has passed but we should be able to upload on Monday, November 2.

Greg, Lenny, hopefully we will get a chance to present the changes during the upcoming IETF meeting? 10 minutes should suffice.

Thanks again Dale - we sincerely appreciate your feedback and suggestions

Best wishes,

Percy & Bob

-----Original Message-----
From: Dale W. Carder [mailto:[e-mail]] 
Sent: Thursday, October 22, 2015 12:05 PM
To: TARAPORE, PERCY S
Cc: [e-mail]
Subject: Re: [MBONED] draft-ietf-mboned-interdomain-peering-bcp-00.txt comments


replying to the list...  sorry for the delay.

Thus spake TARAPORE, PERCY S ([e-mail]) on Thu, Oct 15, 2015 at 02:45:12PM +0000:
> Dale,
> 
> Thanks so much for your detailed set of comments on our BCP Last Call. We appreciate these comments and our responses are provided in detail below. However, we should point out two aspects regarding the use of multicast - our BCP is based on these:
> 
> 1.	As you know, AT&T has recently acquired DirecTV - we envision a significant increase in video distribution both On-Net and Off-Net. There will be many channels including third party channels for distribution. We envision an increased role for multicast in this process including inter-domain peering.
> 2.	We understand the angst in the IETF against "billing and business" issues. However, this is simply a BCP and not a prescriptive RFC. As such, these business issues are included as guidance and not as normative requirements precisely for service providers that may need to multicast content through their respective domains.
> 
> Onto your specific comments:
> 
> -	Thanks for tipping your hat off to us - getting this through MBONE was a long process.
> -	Section 1 Assumption on compatible multicast protocols: This topic probably needs a separate RFC in its own right!! We don't feel it is within the scope of a BCP unless there is documentation we can point to on HOW any incompatibility can be resolved.
> -	Section 1 AMT Assumption - we will add text stating that this is not necessary for Use Cases 3.1 & 3.2.
> -	Section 3.1 Guideline (c) - we will add text per your suggestion.
> -	Section 3.1 Proposal for New Guideline - sure we can add text either here or point to something in the Security section. Perhaps we can jointly draft some text. As far as "old" references, maybe we can add them to the Informative Reference Section 9.2. Note that we have added a Draft I-D from 2000 there. Let's see if that is allowed.

sample text:

e.  The interconnection of AD-1 and AD-2 should minimally follow BCP-38 
    guidelines for traffic filtering between autonomous systems.  
    Filtering guidelines specific to the multicast control-plane and
    data-plane are described in section 6.


> -	Section 3.2 Guideline (e) - OK we are stating the obvious.
> -	Section 4.3 - Please refer to comment 2 above. We are definitely NOT trying to tell anyone how to run their network. This is a BCP not an RFC. In our SP world, it is important to have such guidelines present.
> -	Section 4.4 - We'll take the complement but we are not sure if you want something added here; please let us know.
> -	Section 5 - looks like you are suggesting we add a description on the "Looking glass style router proxy"?? We can do that; we would need references as well. Again, maybe we can jointly develop some text? Please let us know.

Here's an attempt:

Service providers may wish to allow limited read-only administrative
access to their routers via a looking-glass style router proxy to 
facilitate the debugging of multicast control state and peering status.
Software such as the implementations available at 
http://traceroute.org/#source%20code can be easily extended to provide
access to commonly-used multicast troubleshooting commands in a secure
manner.


> -	Section 6 - Again, maybe we can work jointly on adding new text here?

There exists some pretty good prior work we should reference hopefully
instead of re-documenting the wheel.  Of these, 
draft-chown-mboned-multicast-filtering-02 is probably the most comprehensive.
It looks like this died at ietf-83?



Dale