Re: [16NG] Re: multicast and IPv6 over ETHCS

Alexandru Petrescu <alexandru.petrescu@motorola.com> Wed, 17 January 2007 16:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Dzw-0004a6-Lz; Wed, 17 Jan 2007 11:50:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Dzv-0004a1-Hq for 16ng@ietf.org; Wed, 17 Jan 2007 11:50:51 -0500
Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Dzu-0005eP-5T for 16ng@ietf.org; Wed, 17 Jan 2007 11:50:51 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@motorola.com
X-Msg-Ref: server-7.tower-119.messagelabs.com!1169052649!7063959!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.7]
Received: (qmail 17378 invoked from network); 17 Jan 2007 16:50:49 -0000
Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-7.tower-119.messagelabs.com with SMTP; 17 Jan 2007 16:50:49 -0000
Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l0HGomMu011854; Wed, 17 Jan 2007 09:50:49 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0HGojQ8004880; Wed, 17 Jan 2007 10:50:47 -0600 (CST)
Message-ID: <45AE53E5.90001@motorola.com>
Date: Wed, 17 Jan 2007 17:50:45 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS
References: <20070117160348.14171.qmail@web81913.mail.mud.yahoo.com>
In-Reply-To: <20070117160348.14171.qmail@web81913.mail.mud.yahoo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

gabriel montenegro wrote:
> 
> I'd suggest less rather than more text.

I agree with the intent.

> If it's standard behavior (as suggested by Max), rather than 
> describing it again and risking getting it wrong (even 
> informatively), I think it's better to just refer to the proper 
> sources (and sections within them if need be).

Yes, but currently it is not the case - it doesn't refer to at least
MLDv2 RFC (but prefers to refer to an INFORMATIONAL 4541 optimization of
its usage).  For example MLDv2 says all MLDv2-capable nodes should join
FF02::16.  Will an 802.16 ETHCS node join that address or not?  MUST it?
  RFC2460-2464 don't require that.

For multicast it reads as if authors concentrated in making link-layer
do multicast.  For example, the IPv6 section doesn't contain the word
'multicast' - or the fundamental need for it is IPv6 running over
Ethernet _only_ if that Ethernet is multicast capable.  This is
completely absent from the IPv6 text.

But, the document contains 7 occurences of 'bridge SHALL' statements.

> The whole point of ETH CS is that the data path should look very 
> similar to most (switched) ethernet nowadays ("point-to-point LAN" as
>  per section 6.5.1--Support by IEEE Std 802.3--of IEEE 802.1D-2004).

I agree and share the intent.

> The problem of limiting potential flooding at the link-layer is not 
> new and we can just point at section 2.7 of 
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt
>  for existing procedures.

I agree, I think we can refer to that (although it looks as a
infrastructure multicast problem, non link-local).  But I'm not sure
what is the potential flooding problem in this 802.16 context?  Anyone
noticed such problem?

The only problem I'm aware of is that IPv6 prefers the link-layer to be
multicast capable.

> Now, if there's anything normative that needs to change, Alex, please
>  point that out.

You mean link-layer normative?

Or you mean IPv6 normative?  Sorry, I'm trying to figure out.

For example rfc2461 says the node MUST join a group before receiving
some messages.  The IP-over-ETHCS document doesn't say neither it joins
neither it doesn't.  If the SS MUST join, then how would it do it?  2461
is silent about how to do it and MLDv2 has certain conditions under
which the join should happen.  IP-over-ETHCS document is silent about
all this.

There are also unspecified rules for joining a link-local group, running
over Ethernet, and that don't involve message exchange, and deployed
today.  Which of those should SS do?

RFC2464 says what are the mapping rules for IPv6 multicast addresses to
EThernet link-layer multicast addresses.  In that document there are no
'mapping rules' for IPv6 unicast addresses, nor for IPv4uni/multicast
addresses.

IP-over-ETHCS document says 'mapping' only for IPv4 (referring to
rfc894) and says nothing about IPv6 mapping rules, it's silent about that.

Alex


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng