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

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 05 Oct 2015 13:12:12 -0500

I was alerted to the presence of draft-ietf-mboned-interdomain-peering-bcp-00.txt
via another mailing list, so I took some time to look at it & comment
here.  Thus, I am new to this WG.

In general I think this document is useful, but in all honesty it's
proper place in time may have been a decade ago.  The problem space is 
incredibly complex, so my hat is off to the authors who are trying to 
document it.  One disclaimer is that in my experience on the various 
networks I have been involved with, the number of multicast peers I 
have is only decreasing rather than increasing.  I also have never 
witnessed anything better or newer than igmpv2/pim-sm/bgp/msdp in actual 
use.

Section 1, assumption "Network Administrative Domains involved in setting 
up multicast peering points are assumed to adopt compatible protocols. The 
use of different protocols is beyond the scope of this document."
I almost stopped here. :-)  My multicast peering sessions with service 
providers typically fall into this category.  Some reasons include
dense-mode only on one side, sparse on the other, incompatible use of 
rfc1918 on one side and MLDv1 clients on the other... and so on.

Section 1 AMT Relay assumption.  However, this seems not to be necessary 
at all for the topologies described in 3.1 or 3.2 (nor I have I ever seen 
one).

Section 1 last statement, and also for Section 2:  We actually tried for 
some time to run bilateral multicast peering on an exchange switch (that 
we ran) between participating ISP's.  So this is a valid topology, although 
probably even less common than peering on private interconnects.  Plus, 
it does have a multitude of other issues.

Another topology we have much experience with particularly in our
community is with a multicast enabled ISPs between sites.

Section 3.1 guidelines.  for (c) AD-1 may also employ a policy to only
allow certain groups for which AD-2 has paid.  For example I have seen
cherry-picker devices for determining which video channels are eligible
to be injected into AD-2.  

Section 3.1, Can we add a guideline 'e' to include ensuring that proper 
filtering is enabled between networks, or reference the security
section?

I am guessing it may not be possible to reference draft-nickless-ipv4-mcast-unusable-03
but there has been a lot of real-world pain there.  Another (old) 
example is http://aharp.ittns.northwestern.edu/papers/mcast-template.html

Section 3.2 guideline (e).  Nearly all aspects of peering between
AS's are manually configured, so I don't see how this is an issue.

Section 4.3.  I think this is where I get to say the IETF doesn't get to
tell me how I operate my network... or something ;-)  This looks like it
is really specific to some sort of market segment of which I am not a
part.  My router doesn't have a "manifest file".  In my world, the
client's IGMP/MLD join is what gets them sprayed with content.  

Section 4.4.   Looks pretty good.  I am not sure if the commentary about
violating SLA's and seeking compensation is needed though.  Having
transparency with the quality monitoring probes is very important.  When
we ran the multicast-enabled IX, we also had a probe deployed there
that could be provisioned for anyone's use to ensure the exchange switch
was behaving (which it often was not... another story)

Section 5:  We have had good luck in exposing a Looking glass style
router proxy to our peers to aid in faster problem resolution and help
with the finger pointing in addition to the stream monitoring probes.
This really helps not only when there is a 3rd party in the middle, but
also when troubleshooting filtering / cherry picking / control state,
particularly when turning up the peering sessions.

Section 6:  Text should be added to invoke BCP-38 style filtering.
Something like each multicast peer MUST (can you say MUST?) employ
BCP-38 style filtering to ensure they are not sourcing multicast content
nor any network control state that should not be legitimately sourced by
that network.

Other commentary:
In general I was a bit surprised by the amount of text focused on billing 
& business issues.

Dale

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 22 Oct 2015 11:04:53 -0500

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

Thus spake TARAPORE, PERCY S ([email-masked]) 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

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 22 Oct 2015 17:11:53 +0000

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:[email-masked]] 
Sent: Thursday, October 22, 2015 12:05 PM
To: TARAPORE, PERCY S
Cc: [email-masked]
Subject: Re: [MBONED] draft-ietf-mboned-interdomain-peering-bcp-00.txt comments

sample text:

Here's an attempt:

Dale