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

"Hosnieh Rafiee" <ietf@rozanak.com> Fri, 22 November 2013 22:16 UTC

Return-Path: <ietf@rozanak.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 09D871AE33D for <ipv6@ietfa.amsl.com>; Fri, 22 Nov 2013 14:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 n3eec1uEQF-O for <ipv6@ietfa.amsl.com>; Fri, 22 Nov 2013 14:16:12 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D885D1AE2C9 for <ipv6@ietf.org>; Fri, 22 Nov 2013 14:16:12 -0800 (PST)
Received: from kopoli (g226059129.adsl.alicedsl.de [92.226.59.129]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MBnCB-1VqsuR0F3n-00AbA7; Fri, 22 Nov 2013 17:15:52 -0500
From: Hosnieh Rafiee <ietf@rozanak.com>
To: ipv6@ietf.org, 6man-chairs@tools.ietf.org
Subject: RE: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04
Date: Fri, 22 Nov 2013 23:15:43 +0100
Message-ID: <005001cee7d0$679561a0$36c024e0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac7n0GEVA4UpXOA5RdCQuibJYjNuOw==
Content-Language: en-us
X-Provags-ID: V02:K0:i4Z98ppl0X1tD2Ib3GYsXvBsOZARdfzdvzVbA5+9lLV i1kGMi/065HNbIsSQnVotheY7QXEcZRbcO71hsxUA997JGR2yQ 2ySo/qIZBhDy1wjkgGg6pKBJEefCG9D1ToddHqG3uYnRgJ5rvI Z5KmA9QEAUPfrMssMUlhO0s+vwK7NnEE2+EmIABYqhhCCOvHG+ ukIh5c9yLQLfXXlBpIQsNaFwGyCxnGLJGdtR4R65QzErv8euV/ m2kfMs+syhUkXplwoMKOpMeiXS+sRtzFiI443p7LL+TTSjjHW+ C5TDz7eDCONhWQN3/SNHnJA2kuS8+PsHS2JyTsVPuyItXrj3C5 GEo3JUK8x+M6Nsub+sek=
Cc: draft-chakrabarti-nordmark-6man-efficient-nd@tools.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, 22 Nov 2013 22:16:15 -0000

I reviewed this draft and support its adoption. I guess some of the
recommendation in this draft such as DAD process can be also used to
optimize NDP.
 
I have a few suggestions and questions
 
- In the draft, page 4, page 7, page 8, page 14, page 22 ... the authors
discussed about using EUI-64, since the status of EUI-64 is not clear, I
think it would be helpful if you explain more about the random generation
approach. maybe a reference to rfc 4086 or other approaches. Or either you
need to avoid EUI-64 deprecation.
-
 
Questions:
- I still did not get exactly how you do your optimization in mixed-mode. I
guess whenever any node that uses classic NDP do not hear anything from the
node with efficient-nd, then it will remove it from the cache and again next
time when your node wakes up, it should repeat the process to announce its
IP address. Is this task done by re-registration but what about nodes that
are not router? Probably I missed something about the mixed-mode.
 
- I guess your routers must implement this feature otherwise it cannot
support it. Mixed mode seems only useful for hosts and not routers. Is it
true? 
 
 
 
typos
- page 4: VM address reslution -> resolution
 
 Thanks
Smile,
Hosnieh
 

> On November 21, 2013 at 9:56 AM Suresh Krishnan
<suresh.krishnan@ericsson.com> wrote:
>
>
> I support the adoption of this draft.
>
> Thanks
> Suresh
>
>
> ----- Original Message -----
> From: "Eric Levy- Abegnoli (elevyabe)" <elevyabe@cisco.com>
> To: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
> Cc: 6man Chairs <6man-chairs@tools.ietf.org>
> Sent: 11/21/2013 3:20 AM
> Subject: Re: 6MAN Adoption call on
raft-chakrabarti-nordmark-6man-efficient-nd-04
>
>
>
> Hi,
> I support this draft: besides the operational value already mentioned, I
> can see all the cool things we would be able to do, to scale up the number
> of node on the link.
>
> Broadcasting on the link is quite fine when you have a limited number of
> addresses to deal with, and the dynamic is low. But we plan for layer-2
> networks much bigger and much more dynamic (industrial, datacenter, very
> large campus) and broadcasting + caching is creating a bottleneck.
>
> I imagine we could also do routing with a cache instead of a table, and
> broadcast queries to find the destination prefix. Everybody would agree it
> does not scale. It's not just the
> numbers; it's also the dynamic.
>
> I ran a simple math: 100,000 nodes, 3 addresses each, 10% of nodes moving
> every minute (moves can be physical or virtual), 3 multicast messages sent
> per move (DAD, NA, MLD), message size could go from 100B to 1KB (when
> using CGA for instance), that would range from 1 Mbit to 8 Mbit/sec.
> Definitely an issue for the wireless links, but not only.
> Last but not least, there is quite a bit of latency involved when looking
> for a target that is not in cache.
>
> A cache is a good response to these problems, as long as the dynamic is
> low. But it's just a cache: when numbers grow, it can't keep up. And it¹s
> not designed to be distributed.
> Registration and dissemination (this draft, and sail-draft) propose a
> shift to a more pro-active approach, "a la" routing. Any node looking for
> an address on-link will either have it in its table (not cache) or will
> know who have it (that's the distribution part).
> The critical piece is not just registration; it's also distribution so
> that the information is available quickly where it's needed, along the
> forwarding path.
>
> There is a lot to clarify though: co-existence with the legacy model,
> distribution scheme (hierarchical, hash-based, Š), nature of the
> registrars (Routers? Switches? DHCP servers? Š).
>
> Eric
>
> On 19/11/13 11:45, "Ole Troan" <otroan@employees.org> wrote:
>
> >All,
> >
> >There was moderate support to adopt this draft at the working group
> >meeting in Vancouver.
> >This is an adoption call to confirm the result of the hum at the meeting.
> >
> >Please provide a view with reasons as to whether the WG should adopt this
> >or not.
> >
> >This message starts a one week 6MAN Working Group call on adopting:
> >
> > Title : Wired and Wireless IPv6 Neighbor Discovery
> >Optimizations
> > Author(s) : S. Chakrabarti, E. Nordmark, P. Thubert, M. Wasserman
> > Filename : draft-chakrabarti-nordmark-6man-efficient-nd-04
> > Pages : 31
> > Date : 2013-10-22
> >
> >
>
>http://tools.ietf.org/html/draft-chakrabarti-nordmark-6man-efficient-nd-04
> >
> >The call ends on November 26th, 2013.
> >
> >Regards,
> >
> >Bob Hinden & Ole Trøan
> >--------------------------------------------------------------------
> >IETF IPv6 working group mailing list
> >ipv6@ietf.org
> >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >--------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
---
Hosnieh
Sorry for tpyos from my chubby fingers typing on my phone