IETF Logo Mail Archive

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

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Sat, 30 June 2012 01:42 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
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 3BCE021F8421 for <mboned@ietfa.amsl.com>; Fri, 29 Jun 2012 18:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.674
X-Spam-Level:
X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 N0rq7wfTKRTr for <mboned@ietfa.amsl.com>; Fri, 29 Jun 2012 18:42:41 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C115E21F841D for <mboned@ietf.org>; Fri, 29 Jun 2012 18:42:41 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI05135; Fri, 29 Jun 2012 21:42:38 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 29 Jun 2012 18:41:29 -0700
Received: from dfweml513-mbx.china.huawei.com ([169.254.3.109]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Fri, 29 Jun 2012 18:41:23 -0700
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, Stig Venaas <stig@venaas.com>
Thread-Topic: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?
Thread-Index: AQHNVi5bmeS2biyti0iWC24nf7E7XJcSFkcQ
Date: Sat, 30 Jun 2012 01:41:22 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A80D447A49@dfweml513-mbx.china.huawei.com>
References: <4FECD32D.30403@venaas.com> <EE15DDE8-F921-4F9F-B0B4-704A8BD10045@huawei.com> <4FECD960.8070407@venaas.com> <B0147C3DD45E42478038FC347CCB65FE02BC4A5ADC@XCH-MW-08V.mw.nos.boeing.com> <4FECDBA0.3090405@venaas.com> <B0147C3DD45E42478038FC347CCB65FE02BC4A5AE1@XCH-MW-08V.mw.nos.boeing.com> <4FED2926.60300@venaas.com> <B0147C3DD45E42478038FC347CCB65FE02BC4A5D35@XCH-MW-08V.mw.nos.boeing.com>
In-Reply-To: <B0147C3DD45E42478038FC347CCB65FE02BC4A5D35@XCH-MW-08V.mw.nos.boeing.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "mboned@ietf.org" <mboned@ietf.org>
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: Sat, 30 Jun 2012 01:42:43 -0000

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


> -----Original Message-----
> From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On Behalf
> Of Manfredi, Albert E
> Sent: Friday, June 29, 2012 12:35 PM
> To: Stig Venaas
> Cc: mboned@ietf.org
> Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-
> address-format?
> 
> > -----Original Message-----
> 
> 
> > For multicast things are kind of reversed. From say PIM perspective,
> > you
> > can start out with someone joining an IPv6 group where the last 32 bits
> > form an IPv4 group address. When this IPv6 join reaches say a device on
> > the edge of the IPv4 network, it can based on configuration (or
> > hard-coded if a standardized prefix), or a flag in the group address,
> > or a join attribute (these are the solutions I think we have on the
> > table), know that it should extract those 32 bits, and join the IPv4
> > source. When it receives IPv4 data packets, it can based on its PIM
> > state know what IPv6 address to translate them to.
> >
> > There are other use-cases, this is maybe the easiest one.
> 
> This seems similar yo what I had described, except that the 96-bit prefix
> is configurable (presumably there will be an OOB mechanism to indicate
> what the prefix should be), AND it also seems to depend on PIM.
> 
> What about cases in which PIM isn't used? For example, where proxy IGMP or
> proxy MLD is used, to make multicasts traversing a network available to an
> egress router? Or are we saying that it's okay to have incompatible
> solutions depending on each use case?
> 
> Bert
> 
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned

v2.23.0 | Report a Bug | By Email