Subject: (ngtrans) Multicast over 6to4

From: "Dave Thaler" <[email-masked]>
Date: Mon, 11 Dec 2000 23:32:01 -0800

Here's a summary of the one remaining open issue in
draft-thaler-ngtrans-6to4-multicast-01.txt.
I presented this in ngtrans today and said I'd ask
on the list as well.

Scenario:
There are two 6to4 sites, site A has a source S,
and site B has a receiver that wants to join (S,G).
B's site gateway has two choices as to where it
sends an MLD report:
1) to the relay it points default at.
   The relay is responsible for joining back to
   A's site gateway by sending an MLD report to it.
   Pro: relay already has to do this anyway if
        there are receivers behind it in the v6
        native infrastructure.
   Cons: packets don't take the most efficient path,
        and good connectivity to a relay is required.

2) directly to A's site gateway (just like it would
   send a unicast packet to S).  A's site gateway
   is responsible for replicating data to all other 
   sites which have send reports to it.  (A's site
   gateway already has to be able to replicate data 
   to multiple relays which send reports to it, and
   reports are reports regardless of who they come from)
   Pros: packets take efficient paths, 
         no dependency on good connectivity to a relay.
   Con: A's site gateway now has to keep state on the
        order of the number of 6to4 sites with receivers,
        not just the number of relays with receivers.

So far people who have expressed an opinion tend to 
prefer option 2.  Counter-arguments for the "con" of
option 2 are:
a) if the site is a popular source-specific content
   distributor, then they're probably doing replicated
   unicast in IPv4 today, and the state requirement
   is no different from what they have today.
b) if state becomes a problem because the site has
   a popular multicast source, then this can be solved
   by getting native ipv6 connectivity, thus providing
   an incentive to upgrade.

Any other comments from the list?

-Dave