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

"Pete St. Pierre" <pete.st.pierre@oracle.com> Tue, 26 April 2011 05:15 UTC

Return-Path: <pete.st.pierre@oracle.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EB6E06CD for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWcRGyyxeLaA for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:15:25 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9641AE067C for <6lowpan@ietf.org>; Mon, 25 Apr 2011 22:15:25 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3Q5FMtj006845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Apr 2011 05:15:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p3Q5FMDR029932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 05:15:22 GMT
Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3Q5FGFV030670; Tue, 26 Apr 2011 00:15:16 -0500
Received: from [192.168.1.56] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Apr 2011 22:15:16 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: "Pete St. Pierre" <pete.st.pierre@oracle.com>
In-Reply-To: <1303414920.1671.1849.camel@d430>
Date: Mon, 25 Apr 2011 22:15:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7289A47C-61EC-4E55-B201-1F4950517D3F@oracle.com>
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> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430>
To: Geoff Mulligan <geoff@proto6.com>
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4DB654ED.0001:SCFMA922111,ss=1,fgs=0
Cc: 6lowpan <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: Tue, 26 Apr 2011 05:15:27 -0000

Geoff -
I think Erik has made some very good points on this topic. I don't see a need to make the ND draft any more complex than it already is.

...Pete

On Apr 21, 2011, at 12:42 PM, Geoff Mulligan wrote:

> Pascal,
>  I couple of people supporting the TID is not group consensus.  We have
> had many presentations and discussions about multiple LBRs, backbone
> LBRs and more and none have met with the support of the working group.
> 
> In your opinions we are crashing, but I fail to see that this is the
> opinion of the working group.
> 
> If there are other in the working group that strongly advocate this TID
> idea or the work on multiple and backbone LBRs then they need to speak
> up now en masse or we must move on.
> 
> 	geoff
> 
> 
> On Thu, 2011-04-21 at 21:32 +0200, Pascal Thubert (pthubert) wrote:
>> 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>, "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
>>> 
>> 
> 
> 
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan