All things related to multicast

[David Meyer <>]

> This policy has the following consequences:  Internet2 and 
> Internet1(from the MIX only) multicast sources are provided to 
> Abilene connectors.  Only Internet2 sources are accepted from  
> connectors, and will be provided to then MIX.
> 
> Steve and Dave is this a correct interpretation of how things are 
> working?     

        If you mean me Dave, then I guess you mean you (whatever
        this I2 thing is) can receive all sources (your language
        "Internet2 and Internet1(from the MIX only) multicast sources
        are provided to Abilene connectors." BTW, I have no idea of
        what the term Internet1 means). 
        
        I can't parse this:

        "Only Internet2 sources are accepted from connectors, and will 
        be provided to then MIX."

        meaning you'll send routes to your peers at the mix? That
        allows them to not RPF fail *your* sources. 

> I now have a few questions and comments:
> 
> 1. Should Abilene connectors be allowed give Internet2 multicast 
> routes to non-Internet2 peers?  I hope yes, what do other think?
> If no, is there anyway to enforce such a policy?

        Sure there is. Don't advertise your prefixes to them.
        Don't accept their prefixes. Don't send them SAs.

> 2. If yes to 1, should connectors give non-Internet2 peers routes 
> from the MIX?  I hope not, what do others think? If no, is there 
> anyway to enforce it?   Since I don't think it can be enforced by 
> Abilene, what can be done to make it easy for people to do the right 
> thing?  Maybe a community marking routes from the MIX.

        There are three questions in 1. above. Yes to ?

>> If yes to 1, should connectors give non-Internet2 peers routes from
>> the MIX? 

        again, this is almost impossible to parse, but no, you 
        shouldn't be providing transit (if I understand what this
        means).
        
        
> 3.  I don't think forcing all non-Internet2 Multicast sources to come in 
> from the MIX is a good idea.  Internet2 claims to be promoting 
> Multicast, or to own the technology by some readings, but we're only 
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

        This is completely bogus. You consume standards based 
        technologies developed and debugged by others. You
        just deployed it (and long after the commercial sector
        did if you need a data point). BTW, if you're talking about
        the press release that said that NANOG was using I2
        technology, that was plain embarrassing (for you folks; hope
        you realized that). 

> willing to peer with other non-Internet2 Multicast networks at the MIX. 
> Which means we will only peer with big ISPs and smaller west 
> coast ISPs. What about smaller ISPs in other parts of the country.  
> Yes, this could be a lot of work, but I think having connectors 
> provide Internet2 multicast sources and accept multicast sources 
> from Local and Regional ISPs for delivery to Internet2 receivers 
> would really be promoting Multicast.  

        Fine. You can multicast peer anywhere you do unicast, if 
        you have either a cross-connect/vc/the like (like ADDS), or
        there is a shared multicast capable LAN (like the MIX, PAIX,
        or PEN), or if you have other private peerings. It's no different.

> I'd almost be willing to suggest that if we're not willing to make 
> peering happen in other parts of the country then we shouldn't even 
> peer at the MIX, we should have exactly the same policy for 
> Multicast as Unicast.

        Sorry, this too is bogus. There's nothing magic about the MIX.
        If you want sources from people who turn up there, you have
        to be there (no transit). If you can get it elsewhere (private
        or public) do so. I do.

> If the amount of work involved is the issue, then I think proper use of 
> registries and communities could make it manageable.  But yes, 
> there  will be real work involved. 

        Again, it's no different than unicast. Really. Just in
        the reverse direction. 

        BTW, the real difference isn't in how you handle routing
        (topology) information (what the above discussing was about),
        it about how you handle the contruction of forwarding trees.
        That as of yet hasn't been discussed.


        Dave