(ngtrans) Multicast over 6to4

Dave Thaler <dthaler@Exchange.Microsoft.com> Tue, 12 December 2000 09:02 UTC

Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23801 for <ngtrans-archive@odin.ietf.org>; Tue, 12 Dec 2000 04:02:31 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA28477; Tue, 12 Dec 2000 01:02:15 -0800 (PST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA08854; Tue, 12 Dec 2000 01:01:21 -0800 (PST)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) id eBC901s14239 for ngtrans-dist; Tue, 12 Dec 2000 01:00:01 -0800 (PST)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with ESMTP id eBC8xsr14232 for <ngtrans@sunroof.eng.sun.com>; Tue, 12 Dec 2000 00:59:55 -0800 (PST)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v1.7) with ESMTP id AAA22937 for <ngtrans@sunroof.eng.sun.com>; Tue, 12 Dec 2000 00:59:55 -0800 (PST)
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15662 for <ngtrans@sunroof.eng.sun.com>; Tue, 12 Dec 2000 00:59:55 -0800 (PST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 11 Dec 2000 23:31:20 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Dec 2000 23:32:02 -0800 (Pacific Standard Time)
Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 11 Dec 2000 23:32:02 -0800
content-class: urn:content-classes:message
Subject: (ngtrans) Multicast over 6to4
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 11 Dec 2000 23:32:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
Message-ID: <5B90AD65A9E8934987DB0C8C0762657420FCDF@DF-BOWWOW.platinum.corp.microsoft.com>
Thread-Topic: (ngtrans) 6to4 relay router discovery consensus
Thread-Index: AcBkANk8vXr4uOpBQtqvrdNitPIOkQACrbcQ
From: Dave Thaler <dthaler@Exchange.Microsoft.com>
To: NGtrans List <ngtrans@sunroof.eng.sun.com>
X-OriginalArrivalTime: 12 Dec 2000 07:32:02.0634 (UTC) FILETIME=[9EB442A0:01C0640D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id eBC8xtr14233
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Dave Thaler <dthaler@Exchange.Microsoft.com>
Content-Transfer-Encoding: 8bit

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