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

Stig Venaas <stig.venaas@uninett.no> Tue, 22 January 2008 22:41 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 1JHRoR-0004Wz-42; Tue, 22 Jan 2008 17:41:47 -0500
Received: from mboned by megatron.ietf.org with local (Exim 4.43) id 1JHRoP-0004Wu-Uh for mboned-confirm+ok@megatron.ietf.org; Tue, 22 Jan 2008 17:41:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRoP-0004Wm-Ko for mboned@ietf.org; Tue, 22 Jan 2008 17:41:45 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHRoO-0002Tn-Sk for mboned@ietf.org; Tue, 22 Jan 2008 17:41:45 -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 7B1342BCFB0; Tue, 22 Jan 2008 23:41:40 +0100 (CET)
Message-ID: <479673FF.3010406@uninett.no>
Date: Tue, 22 Jan 2008 23:53:51 +0100
From: Stig Venaas <stig.venaas@uninett.no>
User-Agent: Thunderbird 2.0.0.9 (X11/20071223)
MIME-Version: 1.0
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Subject: Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>
References: <20080122145939.GA1769@cisco.com> <47964B5E.7040407@uninett.no> <CA7D9B4A761066448304A6AFC09ABDA90331BE46@XCH-NE-1V2.ne.nos.boeing.com>
In-Reply-To: <CA7D9B4A761066448304A6AFC09ABDA90331BE46@XCH-NE-1V2.ne.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: 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

Manfredi, Albert E wrote:
>> -----Original Message-----
>> From: Stig Venaas [mailto:stig.venaas@uninett.no] 
> 
>> 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?
> 
> I've seen this said many times, but I'm not sure how to interpret it.
> 
> Do you mean, those now implementing ASM would prefer to use
> IGMPv3/MLDv2, filtering on (*,G), or do you mean that everyone wants to
> be filtering on the source address too?
> 
> My experience is that ASM is what serves some purposes best, and that's
> why customers often prefer to specify IGMPv1/v2 or MLDv1. It's simpler,
> it's deployed (at least the IGMP versions of ASM), and it does exactly
> what is needed.

The one unique thing where ASM is needed IMO is service discovery,
autoconfiguration etc. Cases where you need some multicast address or
perhaps anycast for bootstrapping... But this isn't something you would
do on the Internet, just inside a site or an organisation.

In other cases I think you can do source discovery at the application
layer and use SSM. Of course there is lots of complexity in doing it
in the application as well, but I think that is a better approach.

Stig

> 
>> 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...
> 
> I don't have a case for global scope ASM, so maybe my comments are "who
> cares." In general, I would hate to see ASM disappear, because no one
> spoke up for it.
> 
> Bert



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