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

["Dale W. Carder" <[e-mail]>]

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