RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

Samita Chakrabarti <samita.chakrabarti@ericsson.com> Fri, 20 December 2013 00:56 UTC

Return-Path: <samita.chakrabarti@ericsson.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239E61AC4AB for <ipv6@ietfa.amsl.com>; Thu, 19 Dec 2013 16:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xAtejRm4oC1 for <ipv6@ietfa.amsl.com>; Thu, 19 Dec 2013 16:56:01 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A18FC1AC404 for <ipv6@ietf.org>; Thu, 19 Dec 2013 16:56:01 -0800 (PST)
X-AuditID: c6180641-b7fbd8e0000011cc-24-52b3959da037
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3A.24.04556.D9593B25; Fri, 20 Dec 2013 01:55:57 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0347.000; Thu, 19 Dec 2013 19:55:40 -0500
From: Samita Chakrabarti <samita.chakrabarti@ericsson.com>
To: Erik Kline <ek@google.com>, Ole Troan <otroan@employees.org>
Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
Thread-Topic: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
Thread-Index: AQHO5RSHI47a5UQsiE68Y1syr/NqV5otQZoAgC8iTSA=
Date: Fri, 20 Dec 2013 00:55:39 +0000
Message-ID: <ECA43DA70480A3498E43C3471FB2E1F01C1375BA@eusaamb103.ericsson.se>
References: <1F653502-AD41-4EB6-A43D-541356810DF2@employees.org> <CAAedzxrQcfa+2OEqpgFQEgnEiDbVRFkZW24CHzX-av0-xN4u7A@mail.gmail.com>
In-Reply-To: <CAAedzxrQcfa+2OEqpgFQEgnEiDbVRFkZW24CHzX-av0-xN4u7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXSPt+7cqZuDDDYstrZY0NnEavH59jx2 i5dn3zNZTG5bwebA4nHw2EdGjwWbSj2WLPnJ5PHl8me2AJYoLpuU1JzMstQifbsEroybh/cy F9zmrbi1fTFjA+NPri5GTg4JAROJF0e3s0PYYhIX7q1nA7GFBI4wSny/FNXFyAVkL2eU+HDx OCNIgk3ASqKjdw9QAweHiICDxKkPPCAms4CrxI/lAiAVwgLBEru+TgQbKSIQInH7wBQ2CNtK YsKbZ0wgNouAqsSii2eYQVp5BXwlTr8Sh9jUzijxpHkuK0gNp0CgxMJ9e8DqGYFO+35qDZjN LCAucevJfCaIkwUkluw5zwxhi0q8fPyPFcJWlvg+5xELRL2OxILdn9ggbG2JZQtfg9XzCghK nJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw3MQLj6JgEm+MOxgWfLA8xSnOw KInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcYpCanfz9AvXFNfneGYs2KjaVNxz buocSePQTI+GNaX2jDeu5RsGfzZYo/T/19enXk841DOtzvCZV+R+yugwbk1/tblT7+2+lwcS V2kvc4lbsUBqwWH/pSu1TcTadZXPGyeI+Czi5ngla35Q+EZYiFCh+gr/P2Wn6+fuKQ6XVxNo WP/6UFCfEktxRqKhFnNRcSIAD7log3ECAAA=
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 00:56:03 -0000

Hi Erik,

Some explanation for  your comments below:


> Fundamentally, the main use case seems to be trying to merge two different link types.  One link type for low power nodes, one for "more traditional" nodes, if you will.
[SC>] 
[SC>]  The main usecase of the solution is to reduce multicast and do registration of nodes to the default routers.  It indeed helps wireless devices  not to waste energy on repeated multicast transmission/reception and wireless switches and Wifi-controllers to be more efficient  (due to reduced multicast messaging). Optionally it can do further support on mobility of wireless devices within a large area containing multiple default routers covering the same subnet. The registration, in turn helps reduce ND DOS problem as well as a by-product.

 > I think we have *routing* for this.  Merging what is really two different L2 types so that they can try to be one seemless L2 domain still doesn't feel right to me.
[SC>]  This document  does not talk about merging two different link types.   If you are referring to mixed modes section -- they are simply the use-cases for accommodating classic RFC4861 and the nodes that follow the registration method. 

The efficient ND simply allows many different types of devices ( cell phones, PDA, laptops, cameras, TV, wireless gadgets, servers, Routers etc.) to stay in same IPv6 subnet and communicate with each other more efficiently than today in IPv6. That's why we need this solution as the world is going toward IPv6 with wireless devices.

I think you have been confusing it with RFC6775(6lowpan-ND) - which is a different thing and allows multi-link subnets. 

Cheers,
-Samita