(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
- (ngtrans) Multicast over 6to4 Dave Thaler