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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 21 April 2011 19:32 UTC

Return-Path: <pthubert@cisco.com>
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 2CD61E07E2 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 12:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.852
X-Spam-Level:
X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[AWL=1.747, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 1aRwygvDIz1v for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 12:32:15 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 22DF9E07E0 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 12:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=21816; q=dns/txt; s=iport; t=1303414334; x=1304623934; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3Nvlc1rKGRRu7QAH0LV3EYiAK9IR4HXPSQeDBbFRmsc=; b=ivV1mcK2NahTQCbRmhCPlBPhqQxfbmh4XuTIsr28BpxXRvfLGIJ23Hzj OFseOf9aTX5wr7Gu+3nysCJV5piGqOK6Kq6DySaU0ITy8+qAoJxhZAqAj urkFEizFrx/hqYQ0cglHUBT5s6y6xHuseoIHSAUCZwTFnBV90sVTcRYPa E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUBAJaFsE2Q/khRgWdsb2JhbACET5J8jH+BChQBARYmJadui1yQfIEpg1B9BJI3
X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="26664276"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 19:32:13 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3LJWCBg004642; Thu, 21 Apr 2011 19:32:12 GMT
Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 21:32:12 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Thu, 21 Apr 2011 21:32:08 +0200
Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com>
In-Reply-To: <1303400445.1671.1576.camel@d430>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
Thread-Index: AcwAOoD4MkFgJKs+QLCNA6lxgM/QhAAH2bNA
References: <OF05FC8EC8.E2C545F7-ONC1257878.002DC800-C1257878.002DE486@Schneider-Electric.com> <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Geoff Mulligan" <geoff.ietf@mulligan.com>
X-OriginalArrivalTime: 21 Apr 2011 19:32:12.0607 (UTC) FILETIME=[D02564F0:01CC005A]
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 19:32:17 -0000

Geoff:

There is twice as much support for restoring the TID than there is for  not doing it.
Before we drop the TID, I'd like to see a proposal that allows a 6LoWPAN ND subnet to scale with multiple LBRs, allows nodes to move from a router to the next, and that does not need a TID.
Otherwise, we are not speeding towards the wall, we're already crashing.

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com]
> Sent: Thursday, April 21, 2011 5:41 PM
> To: Pascal Thubert (pthubert)
> Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; 6lowpan@ietf.org
> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
> ARO]
> 
> Pascal,
>   We need to close on this discussion.
> 
> Back in Hiroshima the Working Group decided that Backbone router stuff and
> "address defense" across backbone routers was not going to be part of ND
> draft.  It appeared that the draft was getting way to complicated and the
> Working Group decided to simplify things.
> 
> I have not seen much support on the list for making these changes to include
> the TID in ND.
> 
> We need to get this draft completed.  If there is a large "unheard from"
> support group for these changes, please speak up or we shall move forward
> with the draft as it is.
> 
> 	geoff
> 
> 
> 
> 
> On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote:
> > Hi Erik
> >
> > The TID is not a strong coupling between the H2R and the R2R operations,
> and it is not a coupling with a RPL version  explicitly.
> > It is an abstract information that if defined properly can be used by many
> forms or R2R interactions.
> > As demonstrated by older versions of the ND spec (Backbone Router), RPL,
> and MIP.
> >
> > 6LoWPAN ND cannot scale if the node needs to register to all LBRs.
> 6LoWPAN ND does not define anymore any LBR interaction.
> > IOW, 6LoPWAN ND lost the capability to scale when the backbone router
> piece was removed from the draft.
> > Which means that it lost its capability to apply in the domains I'm looking at
> (industrial and metering).
> >
> > With the TID, we know that we can restore scalability in the future, and we
> know how. I do not know of a plan B.
> >
> > Pascal
> > http://www.xtranormal.com/watch/7011357/
> >
> >
> > > -----Original Message-----
> > > 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?
> > >
> > > 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>om>, "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.
> > > >
> > >
> __________________________________________________________
> > > ____________
> > > >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lowpan
>