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

Ronald Bonica <rbonica@juniper.net> Mon, 02 July 2012 19:28 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 D095A21F8525 for <mboned@ietfa.amsl.com>; Mon, 2 Jul 2012 12:28:02 -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 nl0CbYf0QfLz for <mboned@ietfa.amsl.com>; Mon, 2 Jul 2012 12:28:02 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id E4F4421F8517 for <mboned@ietf.org>; Mon, 2 Jul 2012 12:28:01 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT/H2Rhd97ckT64VG/Q/VMfQ01QaP74Fy@postini.com; Mon, 02 Jul 2012 12:28:07 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Jul 2012 12:28:02 -0700
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 2 Jul 2012 12:28:02 -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 15:28:00 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>, "mboned@ietf.org" <mboned@ietf.org>
Date: Mon, 02 Jul 2012 15:27:58 -0400
Thread-Topic: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?
Thread-Index: Ac1WYemRmeS2biyti0iWC24nf7E7XAB+sRIQAAmb9+AAAL6wQA==
Message-ID: <13205C286662DE4387D9AF3AC30EF456D76F6883EE@EMBX01-WF.jnpr.net>
References: <mailman.4264.1341020564.3336.mboned@ietf.org> <13205C286662DE4387D9AF3AC30EF456D76F687E26@EMBX01-WF.jnpr.net> <C0E0A32284495243BDE0AC8A066631A80D463831@dfweml513-mbx.china.huawei.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A80D463831@dfweml513-mbx.china.huawei.com>
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 19:28:02 -0000

Tina (et al),

First, please accept my apologies for the rather confused email that I sent this morning. For the last few days, we have been without electricity in Northern Virginia, recovering from a severe storm. I have only caught up with this email thread in the last hour.

That said, I would like to restate a few architectural principles. The MLTRANS problem will only be with us for a short time (until walled-garden IPTV operators have converted to IPv6). Therefore, we want to minimize our investment in MLTRANS.

In my mind, the best way to do this is to solve only for use-cases that will see significant deployment. One or two deployments isn't enough to justify a solution. Beyond that, we want to limit the scope of our solutions. If we can avoid changing the IPv6 addressing scheme, that would be a win. Also, restricting our solution to a few optional TLVs in routing and signaling protocols would also be a win.

                                                  Ron



> -----Original Message-----
> From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
> Sent: Monday, July 02, 2012 2:47 PM
> To: Ronald Bonica; mboned@ietf.org
> Subject: RE: [MBONED] An alternative to draft-ietf-mboned-64-multicast-
> address-format?
> 
> Dear Ron,
> I agree with you that if the addressing scheme is kept simple, it is
> definitely better. However, since the Internet at present is more IPv4
> rather than IPv6, should we consider keeping more IPv4 only transit
> networks in mind? On the other hand, if IPv6 addressing scheme supports
> more IPv4 only networks, according to me, people will be more reluctant
> to deploy IPv6 in their IPv4 only network. So, for deployment and
> adoption of IPv6, the use cases should be limited, right? I look
> forward hearing from you.
> 
> Tina
> 
> 
> > -----Original Message-----
> > From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On
> > Behalf Of Ronald Bonica
> > Sent: Monday, July 02, 2012 7:27 AM
> > To: mboned@ietf.org
> > Subject: Re: [MBONED] An alternative to
> > draft-ietf-mboned-64-multicast- address-format?
> >
> > 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
> > >
> > >
> > **********
> > _______________________________________________
> > MBONED mailing list
> > MBONED@ietf.org
> > https://www.ietf.org/mailman/listinfo/mboned