Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]

Erik Nordmark <nordmark@acm.org> Thu, 21 April 2011 21:39 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: 6lowpan@ietfc.amsl.com
Delivered-To: 6lowpan@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0C4C2E06F4 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 14:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.742
X-Spam-Level:
X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldlSnQKgloPb for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 14:39:46 -0700 (PDT)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id B8918E0669 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 14:39:45 -0700 (PDT)
Received: from [128.107.114.52] (dhcp-128-107-114-52.cisco.com [128.107.114.52]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3LLdfMi019446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 14:39:41 -0700
Message-ID: <4DB0A442.4010905@acm.org>
Date: Thu, 21 Apr 2011 14:40:18 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: nicolas.riou@schneider-electric.com
References: <OF0DBCBB23.FB5BBA7F-ONC1257879.004686FB-C1257879.004FB860@Schneider-Electric.com>
In-Reply-To: <OF0DBCBB23.FB5BBA7F-ONC1257879.004686FB-C1257879.004FB860@Schneider-Electric.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 21:39:48 -0000

On 4/21/11 7:30 AM, nicolas.riou@schneider-electric.com wrote:
>
> Hi Erik,
>
> Comments in line...
>
>  > From: Erik Nordmark [mailto:nordmark@acm.org]
>  > Sent: Thursday, April 21, 2011 1:25 AM
>  > To: nicolas.riou@schneider-electric.com
>  > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko
>  > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
>  > ARO]
>  >
>  > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote:
>  > >
>  > > Dear Pascal and al,
>  > >
>  > > I support the idea of reviving the TID in ARO and DAR/DAC. Supporting
>  > > a TID directly in the node initiating the initial NS appears much
>  > > simpler than time stamping in the parent router.
>  >
>  > How would you make this work if the protocol between the routers is not
>  > RPLv1, but some future version of RPL or a completely different routing
>  > protocol?
>
> As Pascal answered in his post, the TID is not particularly coupled with
> RPLv1. The TID is just an extra information provided by the node during
> ND registration which dramatically simplifies node localization but also
> enable DAD across a backbone of Edge Routers advertizing the same prefix.
> Which alternative solution would you suggest for DAD?

DAD works fine with what we have in ARO.
If the same EUI-64 (re)registers the same IPv6 address, then it is not a 
duplicate.
If a different EUI-64 tries to registers an IPv6 address (already 
registered with some other EUI-64), then it is a duplicate.
That is independent whether the check is done in a 6LR or 6LBR.

What do you see as the problem with DAD? Can you provide an example of 
what doesn't work with 6lowpan-nd?

> The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come
> at no cost.

FWIW Complexity is the true cost, because unneeded complexity leads to 
non-interoperability for no benefit.

> Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID can be
> implemented even in the most constrained devices which might not be able
> to consistently increment the TID.

The lollipop stuff is not proven technology. It existed in an early 
draft of OSPF, and was replaced. I assume it was replaced for a reason.

Any proven TID scheme would require stable storage on the device, so 
that the device doesn't accidentally reuse old TIDs too soon. I don't 
think we want to require that capability on all 6lowpan hosts, just 
because it is perceived too hard to have RPL keep track of things.

    Erik

> Regards,
> Nicolas
>
>
>  > The decoupling of the host-router interaction from router-router
> interaction
>  > has served us well in the history of the Internet.
>  >
>  > Erik
>  >
>  > > A simple and efficient method to detect mobility of hosts along a
>  > > backbone of Edge Routers is an important feature to deploy backbones
>  > > of Edge Routers in Buildings and should be clarified before closing
>  > > 6LoWPAN WG.
>  > >
>  > > Cheers,
>  > > Nicolas
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > *"Pascal Thubert (pthubert)" <pthubert@cisco.com>* Envoyé par :
>  > > 6lowpan-bounces@ietf.org
>  > >
>  > > 18/04/2011 10:37
>  > >
>  > >
>  > > A
>  > > "Dijk, Esko" <esko.dijk@philips.com>, "Erik Nordmark"
>  > > <nordmark@acm.org> cc
>  > > 6lowpan@ietf.org
>  > > Objet
>  > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
>  > ARO]
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > Hi Esko, Erik
>  > >
>  > > The discussion on RPL and hosts should happen on the RPL list under a
>  > > different topic. The point being discussed here is this:
>  > >
>  > > The reality is also that those (LLN) networks will need to scale to
>  > > large subnets in plants, building, etc... (see the requirement drafts
>  > > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND
>  > > requires a coordination between LBRs but does not say how it happens.
>  > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07;
>  > > and it requires a TID, for the same reason as RPL. Removing the
>  > > backbone operation and the TID from the draft is ostrich policy.
>  > >
>  > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other
>  > > registrations do when strict ordering is not guaranteed (MIP being an
>  > > example). Say that due to some config, a node registers a lifetime of
>  > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a
>  > > rapid sequence, but does not get an answer yet. Then it finally gets 2
>  > > AROs back, lifetime X and 0. What's the final state in the router?
>  > >
>  > > I'd like to hear what others think.
>  > >
>  > > Pascal
>  > > http://www.xtranormal.com/watch/7011357/
>  > >
>  > >
>  > > > -----Original Message-----
>  > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday,
>  > > April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert
>  > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: TID
>  > > in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello Erik,
>  > > > > taking the definition you quoted:
>  > > > 'host' refers to an LLN device that can generate but does not
>  > > forward > RPL traffic > > the question may arise what is "RPL
>  > > traffic"? It is not defined in the RPL draft > it seems. Pascal
>  > > clarified to me it is traffic associated to a RPL instance, not >
>  > > necessarily RPL protocol messages. This means that a host could
>  > > generate > RPL traffic without being aware of the existence of RPL at
>  > > all. So, _not_ all > hosts have to speak RPL?
>  > > > The RPL draft does not explicitly state if "hosts" in a RPL network
>  > > always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL
>  > > speakers.
>  > > >
>  > > > Taking the definition of 'node' in the RPL draft:
>  > > > 'node' refers to any RPL device, either a host or a router > >
>  > > rules out (?) the option that all "hosts" are non-RPL speakers, since
>  > > there > may be a "RPL device" (i.e. RPL-speaking device, I assume)
>  > > that is also a host.
>  > > >
>  > > > I communicated these perceived unclarities to Pascal and the RFC
>  > > editor 2 > weeks ago. Once this is clear I think the present
>  > > discussion can continue.
>  > > > And then there is the related discussion of ND support for sleepy
>  > > devices, > the original topic of Anders ;) > > best regards, > >
>  > > Esko > > > > -----Original Message----- > From:
>  > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >
>  > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To:
>  > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re:
>  > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO]
>  > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote:
>  > > >
>  > > > > RPL can do what all classical IGPs can do WRT hosts. That is as
>  > > long > > as the host address belongs to the router's prefix and stays
>  > > attached > > to that router.
>  > > >
>  > > > I just realized that we might be talking about a different
>  > > definition of "host".
>  > > > What I mean by "host" is a node which does not participate in a
>  > > routing > protocol, and does not forward packets (except packets
>  > > explicitly addressed > to itself using e.g., a routing header).
>  > > >
>  > > > However, RPL has a different definition:
>  > > > 'host' refers to an LLN device that can generate but does not
>  > > forward > RPL traffic > > Basically per the RPL definition there is
>  > > no such thing as a node which does > not participate in the RPL
>  > > protocol.
>  > > > IMHO what is in RPL should have been defined as a non-forwarding
>  > > node, so > that we can have a sane discussion without getting
>  > > entangled in terminology > issues.
>  > > >
>  > > > Which definition of "host" are you using above?
>  > > >
>  > > > Per the RPL definition there is no need for 6lowpan-nd, since all
>  > > nodes will > speak RPL. This is rather confusing, don't you think?
>  > > >
>  > > > Erik
>  > > >
>  > > > > When the topology becomes multilink subnet and mobility is
>  > > required > > then it is a new problem entirely, and NO, 4861 is not a
>  > > suitable > > interaction with the router to allow the router to
>  > > redistribute a host route.
>  > > > > Because the neighbor cache that 4861 builds is not a of the same
>  > > > > nature as the binding table that 6LoWPAN ND builds. Another thing
>  > > that > > 6LoWPAN ND fails to express correctly. I proposed text to
>  > > explain that > > (attached) but it was not considered, contributing
>  > > to the illusion > > that a cache is a table.
>  > > > >
>  > > > > The reality is also that those networks will need to scale to
>  > > large > > subnets in plants, building, etc... (see the requirement
>  > > drafts in > > ROLL). Registering to all LBRS is totally impractical.
>  > > 6LoWPAN ND > > requires a coordination between LBRs but does not say
>  > > how it happens.
>  > > > > This problem was discussed in 6LoWPAN; the answer was in
>  > > ND-01to07; > > and it requires a TID, for the same reason as RPL.
>  > > Removing the > > backbone operation and the TID from the draft is
> ostrich
>  > policy.
>  > > > >
>  > > > > RPL already adapted to the new reality of large multilink subnet
>  > > with > > inner mobility. Placing the blame on RPL is another
>  > > illusionist trick.
>  > > > > And this is not RPL last call.
>  > > > >
>  > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all
>  > > other > > registrations do when strict ordering is not guaranteed
>  > > (MIP being an > > example). Say that due to some config, a node
>  > > registers a lifetime of > > X, then deregisters (lifetime 0), then
>  > > reregisters (lifetime X) in a > > rapid sequence, but does not get an
>  > > answer yet. Then it finally gets
>  > > 2
>  > > > > AROs back, lifetime X and 0. What's the final state in the router?
>  > > > >
>  > > > > It seems we can never agree on any of this. I'd like to hear what
>  > > > > others think.
>  > > > >
>  > > > > Pascal
>  > > > > http://www.xtranormal.com/watch/7011357/
>  > > > >
>  > > > >
>  > > > >> -----Original Message-----
>  > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-
>  > bounces@ietf.org]
>  > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011
>  > > 1:30 AM > >> To: 6lo>> '6lowpan'
>  > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in
>  > > ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert)
>  > > wrote:
>  > > > >>> Hi Erik:
>  > > > >>>
>  > > > >>> The RPL (DAO) sequence number allows the node to increment
>  > > rapidly > >>> in case of rapid changes and then lazily when the
>  > > situation is > >>> stable and DAO are scarce. The increase is
>  > > strictly monotonous which > > > >>> is critical to us.
>  > > > >>>
>  > > > >>> A time stamp imposes a synchronization between the routers. We
>  > > do > >>> not have such mechanism in RPL. A time unit (a granularity)
>  > > must be > >>> agreed upon. Within that unit, movements go undetected
>  > > so the time > >>> unit must be thin grained to cover rapid changes.
>  > > Yet, depending on > >>> the medium, the time unit, and the size of
>  > > the network, it is not > >>> necessarily easy/possible to guarantee a
>  > > strictly monotonous value > >>> with a thin grained time unit. And we
>  > > have limited space (2
>  > > octets)
>  > > > >>> and have to deal with wrap around, which divides the space by
>  > > at > > least 3.
>  > > > >>>
>  > > > >>> So RPL went for a sequence number.
>  > > > >>
>  > > > >> But the unstated assumption that RPL made is that all
>  > > host-to-router > >> protocols have to now be RPL aware. That doesn't
>  > > sound like good > > design.
>  > > > >> A host isn't aware of whether the routers speak IS-IS or OSPF,
>  > > so why > >> do the hosts need to be aware of RPL by passing some TID
>  > > around?
>  > > > >>
>  > > > >>> I think ND has the same need as MIP for a TID == Sequence # .
>  > > We > >>> know of MIP; We know of RPL. We know of the backbone router
>  > > > >>> operation. We know we'll need the TID and we know exactly why. I
>  > > > >>> think we should have it in the 6LowPAN ND spec right away to
>  > > avoid > >>> interop issues when we add RPL and BR operations.
>  > > > >>
>  > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works
>  > > fine > > without it.
>  > > > >> I think RPL needs to be improved to deal with reality. Isn't
>  > > there a > >> desire for RPL to handle 4861 hosts? Those would never
>  > > know about a > > TID.
>  > > > >>
>  > > > >> Erik
>  > > > >>
>  > > > >> _______________________________________________
>  > > > >> 6lowpan mailing list
>  > > > >> 6lowpan@ietf.org
>  > > > >> https://www.ietf.org/mailman/listinfo/6lowpan
>  > > > > _______________________________________________
>  > > > > 6lowpan mailing list
>  > > > > 6lowpan@ietf.org
>  > > > > https://www.ietf.org/mailman/listinfo/6lowpan
>  > > > >
>  > > >
>  > > > _______________________________________________
>  > > > 6lowpan mailing list
>  > > > 6lowpan@ietf.org
>  > > > https://www.ietf.org/mailman/listinfo/6lowpan
>  > > >
>  > > > The information contained in this message may be confidential and
>  > > legally > protected under applicable law. The message is intended
>  > > solely for the > addressee(s). If you are not the intended recipient,
>  > > you are hereby notified > that any use, forwarding, dissemination, or
>  > > reproduction of this message is > strictly prohibited and may be
>  > > unlawful. If you are not the intended recipient, > please contact the
>  > > sender by return e-mail and destroy all copies of the > original
>  > > message.
>  > >
>  > > _______________________________________________
>  > > 6lowpan mailing list
>  > > 6lowpan@ietf.org
>  > > https://www.ietf.org/mailman/listinfo/6lowpan
>  > >
>  > >
>  > __________________________________________________________
>  > ____________
>  > > This email has been scanned by the MessageLabs Email Security System.
>  > >
>  > __________________________________________________________
>  > ____________
>  > >
>
>
>
>
>
>