Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

Ronald Bonica <rbonica@juniper.net> Mon, 02 July 2012 14:27 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F7D21F84DE for <mboned@ietfa.amsl.com>; Mon, 2 Jul 2012 07:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.574
X-Spam-Level:
X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyX-CKZEDhXP for <mboned@ietfa.amsl.com>; Mon, 2 Jul 2012 07:27:45 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96D21F84B9 for <mboned@ietf.org>; Mon, 2 Jul 2012 07:27:45 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT/Gv5gTVrP4xGxvRH8io4KwsoerG8KxH@postini.com; Mon, 02 Jul 2012 07:27:50 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Jul 2012 07:27:30 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 2 Jul 2012 10:27:29 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: "mboned@ietf.org" <mboned@ietf.org>
Date: Mon, 02 Jul 2012 10:27:27 -0400
Thread-Topic: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?
Thread-Index: Ac1WYemRo9GBBAIsT6O34PFLgQvYLQB+sRIQ
Message-ID: <13205C286662DE4387D9AF3AC30EF456D76F687E26@EMBX01-WF.jnpr.net>
References: <mailman.4264.1341020564.3336.mboned@ietf.org>
In-Reply-To: <mailman.4264.1341020564.3336.mboned@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jul 2012 14:27:46 -0000

Tina,

We should be remember two things wrt address formats:

- the MLTRANS problem will be with us only for a short time (until walled-garden IPTV providers upgrade to IPv6)
- changes that we make to the IPv6 addressing scheme will be with us forever

So, in the interest of keeping the IPv6 addressing scheme simple, we should try our best to limit the number of uses cases that we support and make the smallest possible change to the IPv6 addressing scheme. It doesn't make sense to complicate the IPv6 addressing scheme in order to support a use-case that will rarely or never be deployed.

                                       Ron
                                       /speaking as AD


> Date: Sat, 30 Jun 2012 01:41:22 +0000
> From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
> To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, Stig Venaas
> 	<stig@venaas.com>
> Cc: "mboned@ietf.org" <mboned@ietf.org>
> Subject: Re: [MBONED] An alternative to
> 	draft-ietf-mboned-64-multicast-address-format?
> 
> The fixed 96 bits and then 32 bits of the IPv4 address is a simpler and
> better approach according to me, as described in
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-
> format-02. However, this http://tools.ietf.org/html/draft-kumar-mboned-
> 64mcast-embedded-address-00 document has its advantages of 6-4-6-4
> scenario which is missing in the alternative document. The only point I
> would like to stress upon is if it covers the scenario of 6-4-6, as
> IPv6 multicast address expressed in terms of IPv4 is something I didn't
> find in the document. I am only concerned about the validity of the
> attributes in an IPv4 only multicast network. Would tunnels be used to
> route the IPv6 packets with the end routers being dual stack?
> 
> Tina
> 
> 
**********