Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

Stig Venaas <stig.venaas@uninett.no> Tue, 22 January 2008 19:48 UTC

Return-path: <mboned-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHP6d-0002rC-12; Tue, 22 Jan 2008 14:48:23 -0500
Received: from mboned by megatron.ietf.org with local (Exim 4.43) id 1JHP6b-0002r6-6C for mboned-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 14:48:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHP6a-0002qx-SN for mboned@ietf.org; Tue, 22 Jan 2008 14:48:20 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHP6a-0005Eh-86 for mboned@ietf.org; Tue, 22 Jan 2008 14:48:20 -0500
Received: from [IPv6?2607?f278?5?3?213?2ff?fe0e?7215] (unknown [IPv6:2607:f278:5:3:213:2ff:fe0e:7215]) by tyholt.uninett.no (Postfix) with ESMTP id 0373E2BD076; Tue, 22 Jan 2008 20:48:17 +0100 (CET)
Message-ID: <47964B5E.7040407@uninett.no>
Date: Tue, 22 Jan 2008 21:00:30 +0100
From: Stig Venaas <stig.venaas@uninett.no>
User-Agent: Thunderbird 2.0.0.9 (X11/20071223)
MIME-Version: 1.0
To: Toerless Eckert <eckert@cisco.com>
Subject: Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>
References: <20080122110030.GE22077@login.ecs.soton.ac.uk> <26945.1201000836@aber.ac.uk> <20080122145939.GA1769@cisco.com>
In-Reply-To: <20080122145939.GA1769@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Dave Price <dave.price@aber.ac.uk>, mboned@ietf.org
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Errors-To: mboned-bounces@ietf.org

Toerless Eckert wrote:
> On Tue, Jan 22, 2008 at 11:20:36AM +0000, Dave Price wrote:
>> I've been quietly reading all the emails going
>> past on this issue.   I too can see the "point of principle",
>> but I, like Tim and others, really do think we need
>> something that will work in the short to medium
>> term for ASM.
> 
> When we did SSM in 2000, even the pessimists like Dave thought
> it might take 5 years for SSM to get adopted. 
> 
> Improving now the ease to load up the global Internet with more ASM
> state and it's MSDP management issues and unresolvable group security
> issues, is just fully giving up on using the IETF as a corrective instrument 
> to set future proof directions, and has us fall back to just leverage the
> IETF to do what serves our short term business interests best.
> Like drilling for oil in in the arctic wildlife refuge. 
> 
> I mean business wise i love it. The more people will use ASM across
> the Internet, the more we can sell of our multicast access control
> features in our routers and multicast with IPsec, yada yada, just
> to get around the intrinsic security issue of ASM. And the job
> security in explaining to folks how to use all that stuff ;-P
[...]

As I see it the people using ASM today would prefer to use SSM if they
could, but there are several obstacles. Perhaps we should rather focus
on those? Even with the unicast based addresses there are still many
advantages with SSM, I don't see that as a reason not to move to SSM.

As I see it, the unicast based addresses simply means that they have a
better and more structured way to choose what addresses to use and ease
management a bit. I can see why you would not do any significant
protocol effort to improve ASM, but this is a simple mechanism requiring
no code changes to make life easier while waiting for SSM.

The main obstacles for deploying SSM are application support, MacOS X
support and IGMPv3 snooping support. Things are slowly getting better...

Stig


_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www1.ietf.org/mailman/listinfo/mboned