From nobody Fri Jun 6 03:00:52 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3F61A02C1 for ; Fri, 6 Jun 2014 03:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 LQaHWV3Hgqm3 for ; Fri, 6 Jun 2014 03:00:48 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3201A0449 for ; Fri, 6 Jun 2014 03:00:47 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so1355198lbd.14 for ; Fri, 06 Jun 2014 03:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=D3qHZ8Qwj1IUHfeFJLYy7+pNHJ7QODPpPA/av1dfCPY=; b=DYsN8FH54+ROfNzPLm/ZYrtKqbO/fe7ElXnGYKSmmuoZWHTYzsDbpbPEFwKb4i2aaA f/HeZZ8VbN8Ct9HMDJS/MgWZCCGc4LZup2hdSBtRP7V7lDxfe6Kmd1OrN6uI3k+8/g+f BkhIJjJTwI3i1uiNlNlcpRR6oZ2+A+Pa3iyELzmPnBnqGNN1ca/4w9JL87WfpmL70gEc ovPVTBE7FrcvzUdQEnwnZ+47WXVquCYxitJhF4HoQkw/pap7Rt2TN58tf89l/6Tq2jLo gycTc6Gua9ub/op/TQ/N8PonQh0pOnP6CsGnVSgQMYITXNjvJF3eAB72TXzFFCIzTK/g MDdA== X-Received: by 10.152.10.168 with SMTP id j8mr2771604lab.37.1402048839336; Fri, 06 Jun 2014 03:00:39 -0700 (PDT) Received: from [192.168.250.7] ([194.100.71.98]) by mx.google.com with ESMTPSA id d9sm7363930lag.19.2014.06.06.03.00.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Jun 2014 03:00:38 -0700 (PDT) Message-ID: <53919145.8060608@gmail.com> Date: Fri, 06 Jun 2014 13:00:37 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: efficientnd-dt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/VKA7xF7NOAEsnO78dvWLgUdvOdY Subject: [Efficientnd-dt] APs from the 29th May telco X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:00:50 -0000 Folks, we had a discussion whether it is possible to filter multicast frames on the Wi-Fi interface without bothering the main CPU.. I said to check this from broadcom chips point of view. Normally, this filtering is done by the driver, and support exists for Broadcom chips about 32 L2 MCAST addresses, that is up to 32 48-bit 802.1 group (i.e. multicast) MAC addresses. In some products (dongles) which comprise, for example, a fully contained WLAN device plus driver operating within a portable system which is attached to a larger system via a USB connector, the same filtering is performed in the firmware. Another thing we discussed was whether the unicast is more costly than multicast power save modes and power consumption point of view. Some mumble from our Wi-Fi folks. You probably know this already but just to write it down somewhere.. it at least helped me to understand things better :) Comments are welcome.. FOR UNICAST: The standard power save mechanism in 802.11 uses a system wherein the STA wakes from time to time to check to see if the AP has anything buffered for delivery to that STA. Typical the wake pattern is some integer multiple of the Beacon interval, and often the integer is 3. When the STA receives the Beacon, it checks for a bit in the Beacon which has been assigned for communicating its specific buffer status at the AP - each associated STA is given one bit location for this purpose. If the STA sees its bit set, then the STA will remain awake and then attempt to gain access to the medium to tell the AP that the STA is awake and wants its packet(s). There are various packet delivery schemes, some of which are more efficient than others, but the basic nature is the same - the STA has to wait for a turn on the medium and when it gets its turn it sends a request to the AP and the AP acknowledges the request and then fetches the data from storage and then waits for its turn to get access to the medium and possibly has other frames already in a transmission queue ahead of the one that it just fetched - so a sum total of N msec can elapse between the time when the STA wakes to listen for the beacon, send the request and then wait for the frame(s) to be transmitted by the AP. Note also, that depending on the particulars of the power save buffered frame retrieval scheme - and there are at least four or five to choose from - the STA might only get one buffered frame and then have to ask for the next one, etc. Or it can get two each time, or four or six, or get all at once after a single request. Other schemes have the STA wake completely instead of requesting - but in such a case, the timing is still the same. FOR MULTICAST: The AP sends all multicast frames immediately after a beacon which is called a DTIM beacon. A DTIM beacon is typically every 3rd beacon, but there is no specific requirement with respect to how often this happens. So - if a STA receives MCAST traffic, it only needs to wake for the DTIM beacon and then continue to listen because the AP will transmit all MCAST frames IMMEDIATELY after the DTIM beacon. In the MCAST case, there is no waiting for MAC access to the medium on the part of the STA, and the AP sends the MCAST without waiting either - they just follow the DTIM beacon. - Jouni From nobody Thu Jun 12 07:54:58 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C601B2A77 for ; Thu, 12 Jun 2014 07:54:54 -0700 (PDT) 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 VuhpIFbevjlY for ; Thu, 12 Jun 2014 07:54:52 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD30F1B2A46 for ; Thu, 12 Jun 2014 07:54:51 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-58-53996e5cb0b3 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 35.CA.27529.C5E69935; Thu, 12 Jun 2014 11:09:49 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 10:54:48 -0400 From: Samita Chakrabarti To: Jouni Korhonen , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] APs from the 29th May telco Thread-Index: AQHPgW4xhxP48Wdvh0aiuwA/3adxwpttlj2w Date: Thu, 12 Jun 2014 14:54:48 +0000 Message-ID: References: <53919145.8060608@gmail.com> In-Reply-To: <53919145.8060608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPlG5s3sxggw+3GC1efLrJaLF/XQOT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx/XsDc8E+pYonxy8xNjDukO5i5OSQEDCR mLjtCAuELSZx4d56ti5GLg4hgaOMEkf+PmCEcJYzShz4fJsNpIpNwEqio3cPO4gtIpAkseD3 TVYQW1jAUmLT/nWMEHEridY5x1ggbCOJDyvvgsVZBFQlTr3cy9zFyMHBK+Ar0dTNBxIWEtCQ aNl7E2wkp4CmREv3bWYQmxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJ Oa+vMUPU60gs2P2JDcLWlli28DVYnFdAUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyFFa nFqWm25ksIkRGA3HJNh0dzDueWl5iFGAg1GJh/dBwoxgIdbEsuLK3EOM0hwsSuK82jergoUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw6mfnc1TuYt3qIvv2Mt8Bea57Qe0fK7jvP9QseX3+ aHzXvojml4knrnmzT2o62K5T/vXAevZEn0PlKSoXZm+YbfgwN/Ca8mGljz+b0tT0fJ48urd9 zf67LnavzvW9fS+xvzX24lfGn1E+E3b6a6QuPxZ56tvi3mKZXdr2z0UyL85dqJ+ecPNihRJL cUaioRZzUXEiAN+xsXVnAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/_4SlLio7TKSaMAYIV4kLaVZAdAc Subject: Re: [Efficientnd-dt] APs from the 29th May telco X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:54:55 -0000 Hi Jouni, Thanks for the write-up on the power-save behavior of unicast and multicast= messages for the 802.11 devices. I think that it is worth documenting. However, from the description below i= t is not clear to me which mode consumes more power. It seems that one ca= n tune the STA wakeup timing and requsts for buffering in order to save pow= er. But MCAST messages are transmitted with DTIM beacon. Can you provide a bit analysis on powersaving on both modes ? As for multic= ast, the messages are sent on every ports -- right? Thanks, -Samita -----Original Message----- From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of = Jouni Korhonen Sent: Friday, June 06, 2014 3:01 AM To: efficientnd-dt@ietf.org Subject: [Efficientnd-dt] APs from the 29th May telco Folks, we had a discussion whether it is possible to filter multicast frames on th= e Wi-Fi interface without bothering the main CPU.. I said to check this from broadcom chips point of view. Normally, this filt= ering is done by the driver, and support exists for Broadcom chips about 32= L2 MCAST addresses, that is up to 32 48-bit 802.1 group (i.e.=20 multicast) MAC addresses. In some products (dongles) which comprise, for ex= ample, a fully contained WLAN device plus driver operating within a portabl= e system which is attached to a larger system via a USB connector, the same= filtering is performed in the firmware. Another thing we discussed was whether the unicast is more costly than mult= icast power save modes and power consumption point of view. Some mumble fro= m our Wi-Fi folks. You probably know this already but just to write it down= somewhere.. it at least helped me to understand things better :) Comments = are welcome.. FOR UNICAST: The standard power save mechanism in 802.11 uses a system wherein the STA w= akes from time to time to check to see if the AP has anything buffered for = delivery to that STA. Typical the wake pattern is some integer multiple of = the Beacon interval, and often the integer is 3. When the STA receives the Beacon, it checks for a bit in the Beacon which h= as been assigned for communicating its specific buffer status at the AP - e= ach associated STA is given one bit location for this purpose.=20 If the STA sees its bit set, then the STA will remain awake and then attemp= t to gain access to the medium to tell the AP that the STA is awake and wan= ts its packet(s). There are various packet delivery schemes, some of which are more efficient= than others, but the basic nature is the same - the STA has to wait for a = turn on the medium and when it gets its turn it sends a request to the AP a= nd the AP acknowledges the request and then fetches the data from storage a= nd then waits for its turn to get access to the medium and possibly has oth= er frames already in a transmission queue ahead of the one that it just fet= ched - so a sum total of N msec can elapse between the time when the STA wa= kes to listen for the beacon, send the request and then wait for the frame(= s) to be transmitted by the AP. Note also, that depending on the particulars of the power save buffered fr= ame retrieval scheme - and there are at least four or five to choose from -= the STA might only get one buffered frame and then have to ask for the nex= t one, etc. Or it can get two each time, or four or six, or get all at once after a sin= gle request. Other schemes have the STA wake completely instead of requesting - but in s= uch a case, the timing is still the same. FOR MULTICAST: The AP sends all multicast frames immediately after a beacon which is calle= d a DTIM beacon. A DTIM beacon is typically every 3rd beacon, but there is = no specific requirement with respect to how often this happens. So - if a STA receives MCAST traffic, it only needs to wake for the DTIM be= acon and then continue to listen because the AP will transmit all MCAST fra= mes IMMEDIATELY after the DTIM beacon. In the MCAST case, there is no waiting for MAC access to the medium on the = part of the STA, and the AP sends the MCAST without waiting either - they j= ust follow the DTIM beacon. - Jouni _______________________________________________ Efficientnd-dt mailing list Efficientnd-dt@ietf.org https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Thu Jun 12 10:19:28 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072E61B27BA for ; Thu, 12 Jun 2014 10:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 tG3JJxKVv_2W for ; Thu, 12 Jun 2014 10:19:19 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555A21B2AAE for ; Thu, 12 Jun 2014 10:19:19 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so885311lab.21 for ; Thu, 12 Jun 2014 10:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ai6Vjnneh3Kmj7CGWJlysfMdUrIwP5wK5oxUbc1Mhd8=; b=gEHwJZV79MfW9QGM54fOzGImLjlv67hFkT8GbUEl1btILj929cHNhqhJKWaJqZeucJ SOM/1x/qzMAW6i1BOGCoTNP7Pw/7CRtuCfNR5cwuq8dK0adesRLUQV36lxzeiyVckYdc NgSwKN4VAIlm2gF30QXjK4ryR3WGMeTkG/Bo6GIuKUEwNPXw180g1NSZfReCDEI1t6nJ MKOUSWOV+BQeFUFsmCwIz4g276AT7FsPDOdQA/Ek+lSQ12PUhVjnd38kwcYGx03xyC/I xFyGnbYwDGzIHwSAvKa6LidaKgsPuLDbwzHo4lFlXG3TRyUsJ+nss6mC10c8ZuYagqEn GeSQ== X-Received: by 10.152.87.136 with SMTP id ay8mr18139244lab.42.1402593557633; Thu, 12 Jun 2014 10:19:17 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id ar1sm28636371lbc.3.2014.06.12.10.19.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 10:19:17 -0700 (PDT) Message-ID: <5399E114.80204@gmail.com> Date: Thu, 12 Jun 2014 20:19:16 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Samita Chakrabarti , "efficientnd-dt@ietf.org" References: <53919145.8060608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/6XvumGIPHKrNGiVc3sCrI-cY1Qc Subject: Re: [Efficientnd-dt] APs from the 29th May telco X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:19:24 -0000 Hi Samita, Unicast does consume more since it follows the "normal" AP-STA delivery when active (with ACKs).. and also the STA polls AP etc i.e., much more message exchanges both up- and downlink. In multicast case, after a beacon the STA just receives multicast messages. - Jouni 6/12/2014 5:54 PM, Samita Chakrabarti kirjoitti: > Hi Jouni, > > Thanks for the write-up on the power-save behavior of unicast and multicast messages for the 802.11 devices. > I think that it is worth documenting. However, from the description below it is not clear to me which mode consumes more power. It seems that one can tune the STA wakeup timing and requsts for buffering in order to save power. But MCAST messages are transmitted with DTIM beacon. > > Can you provide a bit analysis on powersaving on both modes ? As for multicast, the messages are sent on every ports -- right? > > Thanks, > -Samita > > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Friday, June 06, 2014 3:01 AM > To: efficientnd-dt@ietf.org > Subject: [Efficientnd-dt] APs from the 29th May telco > > Folks, > > we had a discussion whether it is possible to filter multicast frames on the Wi-Fi interface without bothering the main CPU.. > > I said to check this from broadcom chips point of view. Normally, this filtering is done by the driver, and support exists for Broadcom chips about 32 L2 MCAST addresses, that is up to 32 48-bit 802.1 group (i.e. > multicast) MAC addresses. In some products (dongles) which comprise, for example, a fully contained WLAN device plus driver operating within a portable system which is attached to a larger system via a USB connector, the same filtering is performed in the firmware. > > Another thing we discussed was whether the unicast is more costly than multicast power save modes and power consumption point of view. Some mumble from our Wi-Fi folks. You probably know this already but just to write it down somewhere.. it at least helped me to understand things better :) Comments are welcome.. > > FOR UNICAST: > > The standard power save mechanism in 802.11 uses a system wherein the STA wakes from time to time to check to see if the AP has anything buffered for delivery to that STA. Typical the wake pattern is some integer multiple of the Beacon interval, and often the integer is 3. > > When the STA receives the Beacon, it checks for a bit in the Beacon which has been assigned for communicating its specific buffer status at the AP - each associated STA is given one bit location for this purpose. > If the STA sees its bit set, then the STA will remain awake and then attempt to gain access to the medium to tell the AP that the STA is awake and wants its packet(s). > > There are various packet delivery schemes, some of which are more efficient than others, but the basic nature is the same - the STA has to wait for a turn on the medium and when it gets its turn it sends a request to the AP and the AP acknowledges the request and then fetches the data from storage and then waits for its turn to get access to the medium and possibly has other frames already in a transmission queue ahead of the one that it just fetched - so a sum total of N msec can elapse between the time when the STA wakes to listen for the beacon, send the request and then wait for the frame(s) to be transmitted by the AP. > > Note also, that depending on the particulars of the power save buffered frame retrieval scheme - and there are at least four or five to choose from - the STA might only get one buffered frame and then have to ask for the next one, etc. > > Or it can get two each time, or four or six, or get all at once after a single request. > > Other schemes have the STA wake completely instead of requesting - but in such a case, the timing is still the same. > > FOR MULTICAST: > > The AP sends all multicast frames immediately after a beacon which is called a DTIM beacon. A DTIM beacon is typically every 3rd beacon, but there is no specific requirement with respect to how often this happens. > > So - if a STA receives MCAST traffic, it only needs to wake for the DTIM beacon and then continue to listen because the AP will transmit all MCAST frames IMMEDIATELY after the DTIM beacon. > > In the MCAST case, there is no waiting for MAC access to the medium on the part of the STA, and the AP sends the MCAST without waiting either - they just follow the DTIM beacon. > > > - Jouni > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt > From nobody Fri Jun 20 07:34:06 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2F1A03C1 for ; Fri, 20 Jun 2014 07:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 a4jl41fHZAkg for ; Fri, 20 Jun 2014 07:34:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AE01B27E8 for ; Fri, 20 Jun 2014 07:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1631; q=dns/txt; s=iport; t=1403274840; x=1404484440; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jr2CxRtlyNdTA6vr0Id0u5HvRs3P0zlDKGuIUGI/bPg=; b=gUkUTnWRAkx+xTj9gccsWGnM60kTCIGmVjmjSUSd0UwDpLxDkxDJamdm a32ihrkS65qndsVhp4ozkNhmJT1QFXbYFADDqBPrfxbveF9WVqqrnZtk/ 9JLwmbzseokCdI7ErLdzIvpMUd5q1dLv1DSs0vCVRORumEZOyj4B7qXHl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUGAPpEpFOtJV2Q/2dsb2JhbABZgw1SWqofAQEBAQEBBQGRa4ZsUwGBBxZ1hAMBAQEEAQEBawsQAgEIGC4nCyUCBAENBYhCDcp9EwSFYokUB4RDBIoGkD6TWoNCgjA X-IronPort-AV: E=Sophos;i="5.01,514,1400025600"; d="scan'208";a="331474749" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 20 Jun 2014 14:33:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5KEXxeW022819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 14:33:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.10]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 20 Jun 2014 09:33:59 -0500 From: "Eric Vyncke (evyncke)" To: Erik Nordmark , Ole Troan , "Bob Hinden" Thread-Topic: [Efficientnd-dt] No 6MAN session planned for IETF90 Thread-Index: AQHPaiHI+ACkQ2+YykGF4Xx54eXMW5s12nwAgETv74A= Date: Fri, 20 Jun 2014 14:33:58 +0000 Message-ID: References: <17A5AD98-783A-4F35-A310-9FA4D55DDF8F@employees.org> <536A8E4C.2080608@sonic.net> In-Reply-To: <536A8E4C.2080608@sonic.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7EB3F2C591DC7941ADF3209BB41E4E89@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/rsgEwwdYk7OxIXNXDTRHJFzx_eo Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] No 6MAN session planned for IETF90 X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 14:34:05 -0000 AFAIK, we did not get any reply... V6OPS is probably a kind of a good alternate plan, isn't it? -=E9ric On 7/05/14 21:49, "Erik Nordmark" wrote: > >Ole and Bob, > >we were planning to have some results from the efficientnd-dt (cc'ed) by >Toronto. >Assuming we do, would it make sense to ask for time in v6ops to present >and discuss? >I don't know what discussions you've had with the v6ops chairs. > >Thanks, >Erik > > >On 5/7/14, 11:25 AM, Ole Troan wrote: >> The chairs have decided to not hold a 6man session at IETF90. >> >> Bob is not going to be in Toronto, because he is sailing to Hawaii (not >>to get their early though), while Ole is on holiday for most of July. >>After discussing the issue with our AD, and looking at the list of >>working group drafts, we have decided to not hold a 6MAN session at >>IETF90. We feel there are not any pressing issues that need >>face-to-face discussion. >> >> We=B9ll continue progressing the documents as we get them as normal, and >>we also encourage the group continue work on the mailing list. >> >> See you at IETF91 in Honolulu! >> >> Best regards, >> Bob and Ole >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >_______________________________________________ >Efficientnd-dt mailing list >Efficientnd-dt@ietf.org >https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Fri Jun 20 07:44:24 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6118A1A036A for ; Fri, 20 Jun 2014 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lujiS2cy4jW6 for ; Fri, 20 Jun 2014 07:44:21 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16991A03A3 for ; Fri, 20 Jun 2014 07:44:20 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so3758826wgg.13 for ; Fri, 20 Jun 2014 07:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=petjI0glNZGB+4t0+1fsR+KkdDp4Nx1AyCco6Zn09jQ=; b=DrzA74jRLnSQ++fAXUL8g5EiUD/kR4BzWjxpIPOak3bKg/l49/YWrs2PYU4Pl8tzn8 AzJ70pYx26/N7XelFpPnR1HUtE9cLroRgiORRUZxRc2QxwBWEeAzT39gCdT3R158PMWX 1IJmkmjb+3fuTlSsdMwZBP/GW/pmuzSHqFsHDHed/s9fko0VvycNMrW/TA6Q3upImGhP QvHEJ9LZPjpExDvm1TdH4MeMBQD/K0cF0d4s8OmhqcnDT1axt6dKL0OEoLYVezsRwCCV w0agKHGtybF55LjAc0sr0lt3ehpYPoMMtELK5XIS2WdvnkmqpULp3I2tZ0uPMRW0sKbw UGBQ== X-Received: by 10.194.222.5 with SMTP id qi5mr4911756wjc.62.1403275456452; Fri, 20 Jun 2014 07:44:16 -0700 (PDT) Received: from [10.0.0.39] ([98.234.222.98]) by mx.google.com with ESMTPSA id l5sm5293858wif.22.2014.06.20.07.44.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 07:44:14 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D341D5FB-E7E8-495F-A582-73A25074C58C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Bob Hinden In-Reply-To: Date: Fri, 20 Jun 2014 07:44:08 -0700 Message-Id: <68DBA015-6388-488E-AC5D-59F1E5436E33@gmail.com> References: <17A5AD98-783A-4F35-A310-9FA4D55DDF8F@employees.org> <536A8E4C.2080608@sonic.net> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/RM7G66E0a2jAAZZJaB7IE8K33-o Cc: Ole Troan , Bob Hinden , Erik Nordmark , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] No 6MAN session planned for IETF90 X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 14:44:22 -0000 --Apple-Mail=_D341D5FB-E7E8-495F-A582-73A25074C58C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 =C9ric, To be honest, I am not sure. If you think it would be useful, please = proceed. Bob On Jun 20, 2014, at 7:33 AM, "Eric Vyncke (evyncke)" = wrote: > AFAIK, we did not get any reply... >=20 > V6OPS is probably a kind of a good alternate plan, isn't it? >=20 > -=E9ric >=20 > On 7/05/14 21:49, "Erik Nordmark" wrote: >=20 >>=20 >> Ole and Bob, >>=20 >> we were planning to have some results from the efficientnd-dt (cc'ed) = by >> Toronto. >> Assuming we do, would it make sense to ask for time in v6ops to = present >> and discuss? >> I don't know what discussions you've had with the v6ops chairs. >>=20 >> Thanks, >> Erik >>=20 >>=20 >> On 5/7/14, 11:25 AM, Ole Troan wrote: >>> The chairs have decided to not hold a 6man session at IETF90. >>>=20 >>> Bob is not going to be in Toronto, because he is sailing to Hawaii = (not >>> to get their early though), while Ole is on holiday for most of = July. >>> After discussing the issue with our AD, and looking at the list of >>> working group drafts, we have decided to not hold a 6MAN session at >>> IETF90. We feel there are not any pressing issues that need >>> face-to-face discussion. >>>=20 >>> We=B9ll continue progressing the documents as we get them as normal, = and >>> we also encourage the group continue work on the mailing list. >>>=20 >>> See you at IETF91 in Honolulu! >>>=20 >>> Best regards, >>> Bob and Ole >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Efficientnd-dt mailing list >> Efficientnd-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/efficientnd-dt >=20 --Apple-Mail=_D341D5FB-E7E8-495F-A582-73A25074C58C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTpEi4AAoJEK7rdBF357uoncUH/22a2NXVaQAs0dcaB91jN9eg AtEFsJ24wejCFeYKQw9pu7IxhJVpQJPfQVbvLE+Aq8R0Byy6gWTw7VJv7MhqRKgx bZz5IfArfURLWhEY4+wih9wtIKGKD/21tdr+vPrUqk+P6AyrnPiMjeFgtTsbzNy7 Gb89S+F6Swh/fP1wQek6vwpYN260/0u0cTHNioUOMTD7HzozW1CNmO1TeRDs/BTa 7tFKvMuouG0euWjNwaWZ41P99P7OJumKFbRspBJe3u/aYFaCzz4GS7VcE2oevbgI A0ZoGw1YkIwSWZoBa7cuFpcZgs1z6bRePPxk9PdKwulWBT+aklT5Xi6xpoUv4XA= =lpqJ -----END PGP SIGNATURE----- --Apple-Mail=_D341D5FB-E7E8-495F-A582-73A25074C58C-- From nobody Fri Jun 20 12:20:18 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E5E1B28DE for ; Fri, 20 Jun 2014 12:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 fp-SY894cIOT for ; Fri, 20 Jun 2014 12:20:15 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CBD1B28E6 for ; Fri, 20 Jun 2014 12:20:15 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.102273394; Fri, 20 Jun 2014 15:20:08 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.114]) by PACDCEXHUB01.cable.comcast.com ([fe80::bdc4:5b5c:ee33:b058%16]) with mapi id 14.03.0181.006; Fri, 20 Jun 2014 15:20:08 -0400 From: "Brzozowski, John" To: "Eric Vyncke (evyncke)" , Erik Nordmark , Ole Troan , Bob Hinden Thread-Topic: [Efficientnd-dt] No 6MAN session planned for IETF90 Thread-Index: AQHPaiHI+ACkQ2+YykGF4Xx54eXMW5s12nwAgETv74D//9qfAA== Date: Fri, 20 Jun 2014 19:20:07 +0000 Message-ID: References: <17A5AD98-783A-4F35-A310-9FA4D55DDF8F@employees.org> <536A8E4C.2080608@sonic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [68.87.16.247] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/ZQcqTWuOkiSmx29MUXp5Mzw9s_g Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] No 6MAN session planned for IETF90 X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:20:17 -0000 SSB0aGluayB2Nm9wcyBtYWtlcyBzZW5zZSwgdGhpcyBpcyBnb29kIGluZm9ybWF0aW9uIGZvciB0 aGUgb3BlcmF0aW9uYWwNCmNvbW11bml0eSBJTU8uDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpKb2huIEphc29uIEJyem96b3dza2kNCkNvbWNhc3QgQ2FibGUN Cm0pIDYwOS0zNzctNjU5NA0KbykgNDg0LTk2Mi0wMDYwDQp3KSB3d3cuY29tY2FzdDYubmV0DQpl KSBqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPg0KRGF0ZTogRnJpZGF5 LCBKdW5lIDIwLCAyMDE0IGF0IDEwOjMzDQpUbzogRXJpayBOb3JkbWFyayA8bm9yZG1hcmtAc29u aWMubmV0PiwgT2xlIFRyw7hhbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+LA0KQm9iIEhpbmRlbiA8 Ym9iLmhpbmRlbkBnbWFpbC5jb20+DQpDYzogImVmZmljaWVudG5kLWR0QGlldGYub3JnIiA8ZWZm aWNpZW50bmQtZHRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0VmZmljaWVudG5kLWR0XSBObyA2 TUFOIHNlc3Npb24gcGxhbm5lZCBmb3IgSUVURjkwDQoNCj5BRkFJSywgd2UgZGlkIG5vdCBnZXQg YW55IHJlcGx5Li4uDQo+DQo+VjZPUFMgaXMgcHJvYmFibHkgYSBraW5kIG9mIGEgZ29vZCBhbHRl cm5hdGUgcGxhbiwgaXNuJ3QgaXQ/DQo+DQo+LcOpcmljDQo+DQo+T24gNy8wNS8xNCAyMTo0OSwg IkVyaWsgTm9yZG1hcmsiIDxub3JkbWFya0Bzb25pYy5uZXQ+IHdyb3RlOg0KPg0KPj4NCj4+T2xl IGFuZCBCb2IsDQo+Pg0KPj53ZSB3ZXJlIHBsYW5uaW5nIHRvIGhhdmUgc29tZSByZXN1bHRzIGZy b20gdGhlIGVmZmljaWVudG5kLWR0IChjYydlZCkgYnkNCj4+VG9yb250by4NCj4+QXNzdW1pbmcg d2UgZG8sIHdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gYXNrIGZvciB0aW1lIGluIHY2b3BzIHRvIHBy ZXNlbnQNCj4+YW5kIGRpc2N1c3M/DQo+PkkgZG9uJ3Qga25vdyB3aGF0IGRpc2N1c3Npb25zIHlv dSd2ZSBoYWQgd2l0aCB0aGUgdjZvcHMgY2hhaXJzLg0KPj4NCj4+VGhhbmtzLA0KPj5FcmlrDQo+ Pg0KPj4NCj4+T24gNS83LzE0LCAxMToyNSBBTSwgT2xlIFRyb2FuIHdyb3RlOg0KPj4+IFRoZSBj aGFpcnMgaGF2ZSBkZWNpZGVkIHRvIG5vdCBob2xkIGEgNm1hbiBzZXNzaW9uIGF0IElFVEY5MC4N Cj4+Pg0KPj4+IEJvYiBpcyBub3QgZ29pbmcgdG8gYmUgaW4gVG9yb250bywgYmVjYXVzZSBoZSBp cyBzYWlsaW5nIHRvIEhhd2FpaSAobm90DQo+Pj50byBnZXQgdGhlaXIgZWFybHkgdGhvdWdoKSwg d2hpbGUgT2xlIGlzIG9uIGhvbGlkYXkgZm9yIG1vc3Qgb2YgSnVseS4NCj4+PkFmdGVyIGRpc2N1 c3NpbmcgdGhlIGlzc3VlIHdpdGggb3VyIEFELCBhbmQgbG9va2luZyBhdCB0aGUgbGlzdCBvZg0K Pj4+d29ya2luZyBncm91cCBkcmFmdHMsIHdlIGhhdmUgZGVjaWRlZCB0byBub3QgaG9sZCBhIDZN QU4gc2Vzc2lvbiBhdA0KPj4+SUVURjkwLiAgV2UgZmVlbCB0aGVyZSBhcmUgbm90IGFueSBwcmVz c2luZyBpc3N1ZXMgdGhhdCBuZWVkDQo+Pj5mYWNlLXRvLWZhY2UgZGlzY3Vzc2lvbi4NCj4+Pg0K Pj4+IFdlwrlsbCBjb250aW51ZSBwcm9ncmVzc2luZyB0aGUgZG9jdW1lbnRzIGFzIHdlIGdldCB0 aGVtIGFzIG5vcm1hbCwgYW5kDQo+Pj53ZSBhbHNvIGVuY291cmFnZSB0aGUgZ3JvdXAgY29udGlu dWUgd29yayBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPj4+DQo+Pj4gU2VlIHlvdSBhdCBJRVRGOTEg aW4gSG9ub2x1bHUhDQo+Pj4NCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gQm9iIGFuZCBPbGUNCj4+ Pg0KPj4+DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QNCj4+PiBpcHY2QGlldGYub3JnDQo+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj5FZmZpY2llbnRuZC1kdCBtYWlsaW5nIGxpc3QNCj4+RWZmaWNpZW50bmQtZHRAaWV0Zi5v cmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lZmZpY2llbnRuZC1k dA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ RWZmaWNpZW50bmQtZHQgbWFpbGluZyBsaXN0DQo+RWZmaWNpZW50bmQtZHRAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VmZmljaWVudG5kLWR0DQoNCg== From nobody Thu Jun 26 07:10:18 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21B1B2B4C for ; Thu, 26 Jun 2014 07:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ESOy46GqBlGO for ; Thu, 26 Jun 2014 07:10:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE87E1B3035 for ; Thu, 26 Jun 2014 06:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=242; q=dns/txt; s=iport; t=1403790027; x=1404999627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C1T3tiEoXzC041e7xBAX3Dzk9BxksV0gzgsL9lvzZ2Y=; b=LolvAcpvqlr66m1UbhJpLadknGoxGmJnSAYjsAumHfzdHAlu/x0ePp3R qR7zZtFbbnWX9RpEdS87mD6ypjm5zMBGuE28qjBmr71UGB1vw/e8NgN+9 ol21VTkcLlsXLN/lHMZbrWNBBMY05ih5Bk92VjKSIDbp0VMqRE6jOBxki I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsGANghrFOtJV2d/2dsb2JhbABagw2BLKodAQEBAQEBBQFsmG0BgQsWdYQEAQEEeRACAQhGMiUCBA6IR8M6F4VkiRwHhEMBBIoMkEyTb4NCgjA X-IronPort-AV: E=Sophos;i="5.01,553,1400025600"; d="scan'208";a="56142575" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 26 Jun 2014 13:40:26 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5QDeQlG001369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 13:40:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.10]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 08:40:25 -0500 From: "Eric Vyncke (evyncke)" To: "Andrew Yourtchenko (ayourtch)" , "Brzozowski, John" Thread-Topic: [Efficientnd-dt] ND design team Thread-Index: AQHPcEwws5CAM+uNSEa6GFFqQ/DhYJtCHwCAgEH+HQA= Date: Thu, 26 Jun 2014 13:40:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <651E91D8F29270429180A7A1CBA9315A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Gvw1r1HlIoPyBiZc-A3k0MV2vYE Cc: Erik Kline , "efficientnd-dt@ietf.org" , "Eric Levy- Abegnoli \(elevyabe\)" , "nordmark@arista.com" , lorenzo Subject: Re: [Efficientnd-dt] ND design team X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 14:10:09 -0000 I am afraid that I have been a very bad person regarding our bi-monthly (or is it bi-weekly in English?) calls... And I have a conflict again today There is nearly no traffic on this alias, it it still the right one? Sorry -=E9ric From nobody Thu Jun 26 07:32:41 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ABE1B3060 for ; Thu, 26 Jun 2014 07:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 SuO5BDnnnt30 for ; Thu, 26 Jun 2014 07:32:35 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCED1B320C for ; Thu, 26 Jun 2014 06:58:20 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.140427395; Thu, 26 Jun 2014 07:58:15 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.114]) by PACDCEXHUB01.cable.comcast.com ([fe80::bdc4:5b5c:ee33:b058%16]) with mapi id 14.03.0181.006; Thu, 26 Jun 2014 09:58:14 -0400 From: "Brzozowski, John" To: "Eric Vyncke (evyncke)" , "Andrew Yourtchenko (ayourtch)" Thread-Topic: [Efficientnd-dt] ND design team Thread-Index: AQHPcEwws5CAM+uNSEa6GFFqQ/DhYJtCDjyAgEHcl4D//8HqAA== Date: Thu, 26 Jun 2014 13:58:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [68.87.16.246] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/L8pTD539C7a9svw5A31DJ1K-5FY Cc: Erik Kline , "efficientnd-dt@ietf.org" , "Eric Levy- Abegnoli \(elevyabe\)" , "nordmark@arista.com" , lorenzo Subject: Re: [Efficientnd-dt] ND design team X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 14:32:40 -0000 SSBiZWxpZXZlIHllcy4gIEFwb2xvZ2llcyBmcm9tIG1lIGFzIHdlbGwsIEkgd2lsbCB0cnkgdG8g c2VuZCBzb21lIHVwZGF0ZXMNCnRoaXMgd2Vlay4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCkpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KQ29tY2FzdCBDYWJsZQ0K bSkgNjA5LTM3Ny02NTk0DQpvKSA0ODQtOTYyLTAwNjANCncpIHd3dy5jb21jYXN0Ni5uZXQNCmUp IGpvaG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbQ0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+DQpEYXRlOiBUaHVyc2Rh eSwgSnVuZSAyNiwgMjAxNCBhdCA5OjQwDQpUbzogQW5kcmV3IFlvdXJ0Y2hlbmtvIDxheW91cnRj aEBjaXNjby5jb20+LCBKb2huIEJyem96b3dza2kNCjxKb2huX0Jyem96b3dza2lAQ2FibGUuQ29t Y2FzdC5jb20+DQpDYzogRXJpYyBBYmVnbm9saSA8ZWxldnlhYmVAY2lzY28uY29tPiwgIm5vcmRt YXJrQGFyaXN0YS5jb20iDQo8bm9yZG1hcmtAYXJpc3RhLmNvbT4sIEVyaWsgS2xpbmUgPGVrQGdv b2dsZS5jb20+LCBMb3JlbnpvIENvbGl0dGkNCjxsb3JlbnpvQGdvb2dsZS5jb20+LCAiZWZmaWNp ZW50bmQtZHRAaWV0Zi5vcmciIDxlZmZpY2llbnRuZC1kdEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbRWZmaWNpZW50bmQtZHRdIE5EIGRlc2lnbiB0ZWFtDQoNCj5JIGFtIGFmcmFpZCB0aGF0IEkg aGF2ZSBiZWVuIGEgdmVyeSBiYWQgcGVyc29uIHJlZ2FyZGluZyBvdXIgYmktbW9udGhseQ0KPihv ciBpcyBpdCBiaS13ZWVrbHkgaW4gRW5nbGlzaD8pIGNhbGxzLi4uIEFuZCBJIGhhdmUgYSBjb25m bGljdCBhZ2Fpbg0KPnRvZGF5DQo+DQo+VGhlcmUgaXMgbmVhcmx5IG5vIHRyYWZmaWMgb24gdGhp cyBhbGlhcywgaXQgaXQgc3RpbGwgdGhlIHJpZ2h0IG9uZT8NCj4NCj5Tb3JyeQ0KPg0KPi3DqXJp Yw0KPg0KDQo= From nobody Thu Jun 26 08:31:00 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4594A1B30B9 for ; Thu, 26 Jun 2014 08:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 THkxuGTBrzsN for ; Thu, 26 Jun 2014 08:30:53 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756CF1B30C9 for ; Thu, 26 Jun 2014 07:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5073; q=dns/txt; s=iport; t=1403793430; x=1405003030; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Uw3m2d7mQnDjZNht05VgF6SfYDer1hpfI4qpWSCJQ+M=; b=EhrRsgzll/znAxTqoki8whFRXJ8ffsgETTnGuNknlRap9AhRYhRJWrlI grymh7cdmz3cI94uT4ZjWehNbgHPs3LDpztzR17cNThJe7zbRFUwtgG9d 69BqumzJTQZFYrywGgRscTqmzzBlVRzdG+NQFFld2XfBFEbZv/XoZ7goX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQGAOourFOtJA2E/2dsb2JhbABQCoMNUlqCbqcuAQEBAQEBBQFskS2HQAEZcxZ1hAMBAQEEAQEBIEsLDAQCAQgRAQMBAQsdAwICAiULFAMGCAIEAQ0FCAEFiDQNpUadUxeFZIhAKzEHBgOCbjaBFgWPN4JXhDWFW5Ipg0JsgUQ X-IronPort-AV: E=Sophos;i="5.01,553,1400025600"; d="scan'208";a="56183727" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 26 Jun 2014 14:37:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5QEb9uu026124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 14:37:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.12]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 09:37:09 -0500 From: "Pascal Thubert (pthubert)" To: "Brzozowski, John" , "Eric Vyncke (evyncke)" , "Andrew Yourtchenko (ayourtch)" Thread-Topic: [Efficientnd-dt] ND design team Thread-Index: AQHPcEwws5CAM+uNSEa6GFFqQ/DhYJtCHwCAgEH+HQD//+N0AP//tkAw Date: Thu, 26 Jun 2014 14:37:08 +0000 Deferred-Delivery: Thu, 26 Jun 2014 14:37:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: multipart/mixed; boundary="_002_E045AECD98228444A58C61C200AE1BD842C66B54xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/9gvMVDXjkuAx3Hjg7fGArzZ3Io0 Cc: Erik Kline , lorenzo , "Eric Levy- Abegnoli \(elevyabe\)" , "nordmark@arista.com" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] ND design team X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:30:58 -0000 --_002_E045AECD98228444A58C61C200AE1BD842C66B54xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgYXR0YWNoZWQgdGhlIG5vdGlmaWNhdGlvbiBmb3IgdGhlIHdvcmsgd2UgdGFs a2VkIGFib3V0IGR1cmluZyB0aGUgY2FsbCB0b2RheSBhYm91dCA2TG9XUEFOIE5EIHZzLiBSUEwu DQoNCkNoZWVycywNCg0KUGFzY2FsIA0KDQo= --_002_E045AECD98228444A58C61C200AE1BD842C66B54xmbrcdx01ciscoc_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Thu, 26 Jun 2014 14:37:06 GMT"; modification-date="Thu, 26 Jun 2014 14:37:06 GMT" From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> CC: roll Subject: FW: New Version Notification for draft-thubert-6lo-rfc6775-update-reqs-00.txt Thread-Topic: New Version Notification for draft-thubert-6lo-rfc6775-update-reqs-00.txt Thread-Index: AQHPi5y88O696LSvcUm4Be3uzHbJWZt4I5YQgAddbDCAAd+NEA== Date: Wed, 25 Jun 2014 06:14:40 +0000 Deferred-Delivery: Wed, 25 Jun 2014 06:15:00 +0000 References: <20140619085905.10564.60750.idtracker@ietfa.amsl.com> In-Reply-To: Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Dear all: This work is an important step for 6TiSCH (and probably ROLL) and I do enco= urage you to participate to the thread on the 6lo mailing list. Abstract: "Work presented at the 6TiSCH and 6MAN working groups suggest a number of enhancements to the 6LoWPAN ND mechanism. This document elaborates on such requirements." As you know, 6TiSCH is only chartered to define the architecture that ties = RPL, 6LoWPAN and other IETF protocols together. At some point, we identify issues and need to go to the relevant groups and= trigger the incremental standardization work. This particular draft lists the issues that we have found and the requireme= nts we have discussed in order to get a 6LoWPAN ND node act as a RPL leaf. We need activity and support on these requirements to trigger work at 6lo (= and eventually ROLL) to perform the necessary adaptations. Cheers, Pascal -----Original Message----- From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com] Sent: mardi 24 juin 2014 03:34 To: Pascal Thubert (pthubert); 6lo@ietf.org Subject: RE: New Version Notification for draft-thubert-6lo-rfc6775-update-= reqs-00.txt Thank you Pascal for putting together this draft. I'll read and provide comments if any. I'll encourage the WG to please read= this draft and comment/add any more ideas/suggestions that you might have= experienced with RFC 6775 implementations or usage scenarios. Thanks, -Samita -----Original Message----- From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthube= rt) Sent: Thursday, June 19, 2014 2:07 AM To: 6lo@ietf.org Subject: [6lo] FW: New Version Notification for draft-thubert-6lo-rfc6775-u= pdate-reqs-00.txt Dear all: Samita suggested that I prepare a draft to discuss proposed updates to 6LoW= PAN ND (RFC 6775) in the light of work at 6MAN and 6TiSCH. I put the reference draft together, please read on. Dear chairs: I'd wish to have a slot in Toronto to introduce the matter if time permits. Cheers, Pascal -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: jeudi 19 juin 2014 10:59 To: Pascal Thubert (pthubert); Pascal Thubert (pthubert) Subject: New Version Notification for draft-thubert-6lo-rfc6775-update-reqs= -00.txt A new version of I-D, draft-thubert-6lo-rfc6775-update-reqs-00.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-thubert-6lo-rfc6775-update-reqs Revision: 00 Title: Requirements for an update to 6LoWPAN ND Document date: 2014-06-19 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-thubert-6lo-rfc67= 75-update-reqs-00.txt Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-rfc6775-= update-reqs/ Htmlized: http://tools.ietf.org/html/draft-thubert-6lo-rfc6775-update= -reqs-00 Abstract: Work presented at the 6TiSCH and 6MAN working groups suggest a number of enhancements to the 6LoWPAN ND mechanism. This document elaborates on such requirements. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo --_002_E045AECD98228444A58C61C200AE1BD842C66B54xmbrcdx01ciscoc_-- From nobody Thu Jun 26 22:54:21 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026651B3159 for ; Thu, 26 Jun 2014 22:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.851 X-Spam-Level: X-Spam-Status: No, score=-12.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 dPCtIHpmYtgZ for ; Thu, 26 Jun 2014 22:54:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D701B2ABE for ; Thu, 26 Jun 2014 22:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9507; q=dns/txt; s=iport; t=1403848454; x=1405058054; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qLtzoxYVmj7nHD7kP4pKdqOUMG7dAYySbIlLobqnNh0=; b=HkqEw4BfIjcVSOpK3XmKed8jZH9tvq/xWaq3PmUUe/xHD9880uWo8Z+J rj2GWN1MSJo17cj19xFCc27ZRy9aNiONLtcis+Ltl1z1q65akeVNN4s5X fxq0t6tboWkL40IyiORldLN50cxuulkl2M1GuKiSNspjC1uMxFUb4B8qJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8GANkFrVOtJA2F/2dsb2JhbABbgw1SqlU3AQEBAQEHilWGAIFVAYc/AYEIFnWEBAEBBAEBAQlCIwgQAgEcEBcEBycKARQHCgIEDgUJCwcCBIghDcJwF4VkhXqCTzEBEBEGAYMtgRYFig2QTIFGiXkEgiaGDIIAgUJsgQs X-IronPort-AV: E=Sophos; i="5.01,558,1400025600"; d="scan'208,217"; a="56379113" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 27 Jun 2014 05:54:13 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5R5sDWH028839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 05:54:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.12]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 00:54:13 -0500 From: "Pascal Thubert (pthubert)" To: "'Jouni Korhonen'" Thread-Topic: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link Thread-Index: AQHPkYFTTRedaIeIBEecVrlm2WdaqZuEdW7n Date: Fri, 27 Jun 2014 05:54:13 +0000 Message-ID: References: <20140626205546.713F21801AE@rfc-editor.org> In-Reply-To: <20140626205546.713F21801AE@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A333C195E6404E90A7064D85BAC5169Dciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/35DMNiY-C9KiBrnPbJP_lQg-FSw Cc: "efficientnd-dt@ietf.org" Subject: [Efficientnd-dt] Fwd: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 05:54:20 -0000 --_000_A333C195E6404E90A7064D85BAC5169Dciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jouni: This looks like another twist in the ML subnet which could be used to backh= aul a RPL network (replacing the LAN) over 3GPP... Then again efficient ND can be the gearbox between the 2 worlds... What do you think? Cheers Pascal D=E9but du message transf=E9r=E9 : Exp=E9diteur: > Date: 26 juin 2014 22:55:46 UTC+2 Destinataire: >, > Cc: >, >, > Objet: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Par= tnership Project (3GPP) Mobile Interface to a LAN Link R=E9pondre =E0: > A new Request for Comments is now available in online RFC libraries. RFC 7278 Title: Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link Author: C. Byrne, D. Drown, A. Vizdal Status: Informational Stream: IETF Date: June 2014 Mailbox: cameron.byrne@t-mobile.com, dan@drown.org, ales.vizdal@t-mobile.cz Pages: 10 Characters: 19965 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-64share-10.txt URL: http://www.rfc-editor.org/rfc/rfc7278.txt This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples. This document is a product of the IPv6 Operations Working Group of the IETF= . INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --_000_A333C195E6404E90A7064D85BAC5169Dciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Jouni:

This looks like another twist in the ML subnet which could be used to = backhaul a RPL network (replacing the LAN) over 3GPP...

Then again efficient ND can be the gearbox between the 2 worlds...

What do you think?

Cheers 

Pascal

D=E9but du message transf=E9r=E9 :

Exp=E9diteur: <= rfc-editor@rfc-editor.org>
Date: 26 juin 2014 22:55:46 UTC+2
Destinataire: <ietf-ann= ounce@ietf.org>, <rfc-= dist@rfc-editor.org>
Cc: <drafts-update-= ref@iana.org>, <v6ops@ietf.org<= /a>>, <rfc-editor@rfc-ed= itor.org>
Objet: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Gene= ration Partnership Project (3GPP) Mobile Interface to a LAN Link
R=E9pondre =E0: <ietf@ietf.org>

A new Request for Comments is now available in online RFC librar= ies.


       RFC 7278

       Title:    &n= bsp; Extending an IPv6 /64 Prefix from
           &nb= sp;       a Third Generation Partnership= Project (3GPP)
           &nb= sp;       Mobile Interface to a LAN Link=
       Author:    &= nbsp;C. Byrne,
           &nb= sp;       D. Drown,
           &nb= sp;       A. Vizdal
       Status:    &= nbsp;Informational
       Stream:    &= nbsp;IETF
       Date:    &nb= sp;  June 2014
       Mailbox:    = cameron.byrne@t-mobile.com,
           &nb= sp;       dan@drown.org,
           &nb= sp;       ales.vizdal@t-mobile.cz
       Pages:    &n= bsp; 10
       Characters: 19965        Updates/Obsoletes/SeeAlso: =   None

       I-D Tag:    = draft-ietf-v6ops-64share-10.txt

       URL:    &nbs= p;   h= ttp://www.rfc-editor.org/rfc/rfc7278.txt

This document describes requirements for extending an IPv6 /64 prefix=
from a User Equipment Third Generation Partnership Project (3GPP)
radio interface to a LAN link and describes two implementation=
examples.

This document is a product of the IPv6 Operations Working Group of th= e IETF.


INFORMATIONAL: This memo provides information for the Internet commun= ity.
It does not specify an Internet standard of any kind. Distribution of=
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 = http://www.ietf.org/mailman/listinfo/ietf-announce
 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

--_000_A333C195E6404E90A7064D85BAC5169Dciscocom_-- From nobody Thu Jun 26 23:24:19 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7A41B3057 for ; Thu, 26 Jun 2014 23:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_TRNFER=2.3, SPF_PASS=-0.001] autolearn=no 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 Mu4fztJ1jF9m for ; Thu, 26 Jun 2014 23:24:16 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83721B3049 for ; Thu, 26 Jun 2014 23:24:15 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w7so3693712lbi.35 for ; Thu, 26 Jun 2014 23:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1hPXXA0Gu/ywg9HGp8Z2uAKdVGsdjpkWOfqNYahdm8c=; b=FpL8+ZH4CFRyESVUufwxuKhGB+/QoQEQGtYR20IKyW6T/hbPhYPFdF2KWEiUkYfdFE ethTnZ7Jty+qWq/B1Esl1+moFufutYPmTipqH7tdOyMQI5gtFkVbQuzomNsPF0eWOnyu Bd6kQ7cpCIUP7u2pcsb1lW4VVhttTSVVrX0uGJKFDzgA8GLlLHLbBK4BOhW/jughUaaD tZliCyIvvaWJPycTxj1CG89FLvHEVA3s7Z/3RhDOgqsL8IG65oyUj3i6vfejSbnrSuqh 4lziUgf+iECZXPACaFQUTTuH8tNM2nxGPCooWIBCrJGC4mamIceoKla3vFEa5lSy6fzq FhkQ== X-Received: by 10.112.150.65 with SMTP id ug1mr14270089lbb.46.1403850253957; Thu, 26 Jun 2014 23:24:13 -0700 (PDT) Received: from [192.168.250.168] ([194.100.71.98]) by mx.google.com with ESMTPSA id i10sm3979579laa.46.2014.06.26.23.24.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 23:24:13 -0700 (PDT) Message-ID: <53AD0E0D.4010209@gmail.com> Date: Fri, 27 Jun 2014 09:24:13 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20140626205546.713F21801AE@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/KvEoLlh84YUT4HfR3UGdxJo6Rfg Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Fwd: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:24:17 -0000 Hi Pascal, This RFC had a specific target i.e. to allow tethering in cellular environment if and when DHCPv6-PD is not available. One could use this to backhaul RPL network but not sure on which part you think efficient ND would be useful? - Jouni 6/27/2014 8:54 AM, Pascal Thubert (pthubert) kirjoitti: > Hello Jouni: > > This looks like another twist in the ML subnet which could be used to > backhaul a RPL network (replacing the LAN) over 3GPP... > > Then again efficient ND can be the gearbox between the 2 worlds... > > What do you think? > > Cheers > > Pascal > > Début du message transféré : > >> *Expéditeur:* > > >> *Date:* 26 juin 2014 22:55:46 UTC+2 >> *Destinataire:* > >, > > >> *Cc:* > >, > >, > > >> *Objet:* *RFC 7278 on Extending an IPv6 /64 Prefix from a Third >> Generation Partnership Project (3GPP) Mobile Interface to a LAN Link* >> *Répondre à:* > >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 7278 >> >> Title: Extending an IPv6 /64 Prefix from >> a Third Generation Partnership Project (3GPP) >> Mobile Interface to a LAN Link >> Author: C. Byrne, >> D. Drown, >> A. Vizdal >> Status: Informational >> Stream: IETF >> Date: June 2014 >> Mailbox: cameron.byrne@t-mobile.com >> , >> dan@drown.org , >> ales.vizdal@t-mobile.cz >> Pages: 10 >> Characters: 19965 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-v6ops-64share-10.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc7278.txt >> >> This document describes requirements for extending an IPv6 /64 prefix >> from a User Equipment Third Generation Partnership Project (3GPP) >> radio interface to a LAN link and describes two implementation >> examples. >> >> This document is a product of the IPv6 Operations Working Group of the >> IETF. >> >> >> INFORMATIONAL: This memo provides information for the Internet community. >> It does not specify an Internet standard of any kind. Distribution of >> this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see http://www.rfc-editor.org/search >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org >> . Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> From nobody Thu Jun 26 23:28:10 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B941B3057 for ; Thu, 26 Jun 2014 23:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 LGFal_xe91f7 for ; Thu, 26 Jun 2014 23:28:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8A21B2FA6 for ; Thu, 26 Jun 2014 23:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3873; q=dns/txt; s=iport; t=1403850485; x=1405060085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EcsqGoVvGT+OeBbYgsU3P9w1FBw0y6Lr0urI4Jo4a9A=; b=joRX+VaFtMGOZ+scE41YuJ2oHPmb/VB2fBjv0oNIXNJjxqP2iPr9aboI m+akgNwPuY3Xs4dI8gh3MKEsyfA2av+qLpK3KuYVgywYU1e2NUw9TVdqE Ysnz0RmTKMZSfEgTcXx0aCxXu4tBhiUlFq8fz0oFcmMImI5OjmAa2mlW/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAIUOrVOtJV2Z/2dsb2JhbABbgw1SqlU3AQEBAQEHilWHVYdAAYEIFnWEAwEBAQMBAQEBCUIjCAULAgEIFBAXBAchBgoBFBECBA4FCQsHAgSIDQMJCA28Gg2GUBeFZIV6fYFSIBIhAgWDLYEWBYoNjk+BfYFGiXkEgiMDhgyCAIFCbIEL X-IronPort-AV: E=Sophos;i="5.01,558,1400025600"; d="scan'208";a="56378847" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 27 Jun 2014 06:28:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5R6S473002656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 06:28:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.198]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 01:28:04 -0500 From: "Pascal Thubert (pthubert)" To: Jouni Korhonen Thread-Topic: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link Thread-Index: AQHPkdDzgxM+/yaV7kSkyzffjDz3vg== Date: Fri, 27 Jun 2014 06:28:03 +0000 Message-ID: References: <20140626205546.713F21801AE@rfc-editor.org> , <53AD0E0D.4010209@gmail.com> In-Reply-To: <53AD0E0D.4010209@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/LxFuJKBUf_cvhlKtiUelEvNswMc Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:28:08 -0000 Efficient ND is the generic way for the RPL root to register the sensors to= the phone.=20 Say the RPL root connects over BTLE for instance... Pascal > Le 27 juin 2014 =E0 08:24, "Jouni Korhonen" a = =E9crit : >=20 > Hi Pascal, >=20 > This RFC had a specific target i.e. to allow tethering in cellular enviro= nment if and when DHCPv6-PD is not available. >=20 > One could use this to backhaul RPL network but not sure on which part you= think efficient ND would be useful? >=20 > - Jouni >=20 > 6/27/2014 8:54 AM, Pascal Thubert (pthubert) kirjoitti: >> Hello Jouni: >>=20 >> This looks like another twist in the ML subnet which could be used to >> backhaul a RPL network (replacing the LAN) over 3GPP... >>=20 >> Then again efficient ND can be the gearbox between the 2 worlds... >>=20 >> What do you think? >>=20 >> Cheers >>=20 >> Pascal >>=20 >> D=E9but du message transf=E9r=E9 : >>=20 >>> *Exp=E9diteur:* >> > >>> *Date:* 26 juin 2014 22:55:46 UTC+2 >>> *Destinataire:* >> >, >> > >>> *Cc:* >> >, >> >, >> > >>> *Objet:* *RFC 7278 on Extending an IPv6 /64 Prefix from a Third >>> Generation Partnership Project (3GPP) Mobile Interface to a LAN Link* >>> *R=E9pondre =E0:* > >>>=20 >>> A new Request for Comments is now available in online RFC libraries. >>>=20 >>>=20 >>> RFC 7278 >>>=20 >>> Title: Extending an IPv6 /64 Prefix from >>> a Third Generation Partnership Project (3GPP) >>> Mobile Interface to a LAN Link >>> Author: C. Byrne, >>> D. Drown, >>> A. Vizdal >>> Status: Informational >>> Stream: IETF >>> Date: June 2014 >>> Mailbox: cameron.byrne@t-mobile.com >>> , >>> dan@drown.org , >>> ales.vizdal@t-mobile.cz >>> Pages: 10 >>> Characters: 19965 >>> Updates/Obsoletes/SeeAlso: None >>>=20 >>> I-D Tag: draft-ietf-v6ops-64share-10.txt >>>=20 >>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt >>>=20 >>> This document describes requirements for extending an IPv6 /64 prefix >>> from a User Equipment Third Generation Partnership Project (3GPP) >>> radio interface to a LAN link and describes two implementation >>> examples. >>>=20 >>> This document is a product of the IPv6 Operations Working Group of the >>> IETF. >>>=20 >>>=20 >>> INFORMATIONAL: This memo provides information for the Internet communit= y. >>> It does not specify an Internet standard of any kind. Distribution of >>> this memo is unlimited. >>>=20 >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> http://www.ietf.org/mailman/listinfo/ietf-announce >>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>>=20 >>> For searching the RFC series, see http://www.rfc-editor.org/search >>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html >>>=20 >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org >>> . Unless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>>=20 >>>=20 >>> The RFC Editor Team >>> Association Management Solutions, LLC >>>=20 From nobody Thu Jun 26 23:47:38 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB8D1B3172 for ; Thu, 26 Jun 2014 23:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_TRNFER=2.3, SPF_PASS=-0.001] autolearn=no 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 dPKCk_JISeZp for ; Thu, 26 Jun 2014 23:47:33 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913F11B3165 for ; Thu, 26 Jun 2014 23:47:33 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id hz20so2651030lab.14 for ; Thu, 26 Jun 2014 23:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iegycYgky2Rd33RMKvQGRvHc1FOEZtqrsZ7jW3xBdC8=; b=wnyvilhwMDspo6Yqo6Gp0nsP5QSyn3SYZ0HdvMmQ06xwGs6SbSFSgUqWYMxarvT2Vi qJ3BK8SR/yoatuTeBKXTAzuWAsu0s2+OilY+PkpiqT+8pWVqTXhaFjdSu629xuIfjIav 7pljUk13cpkE1Omipu+kprJBUAkSFX+BSW+05jpA8S0i0y0O8eW2bmPe3CknfXlKiUNK VLXYU/cw2Ag05iWyAfbvlb57eCUl/fNCqu68RcI39p/qQ7kVCWJP7hOYwVxSw1XKvhIY yQbiUbiyYpIaLeJzaoo3gvPdct28WdARnm39er0oVm9t3t/9UZ5ucCgEQw7WxNJnLipt +FWA== X-Received: by 10.112.129.202 with SMTP id ny10mr14738358lbb.14.1403851651838; Thu, 26 Jun 2014 23:47:31 -0700 (PDT) Received: from [192.168.250.168] ([194.100.71.98]) by mx.google.com with ESMTPSA id tv3sm10426189lbb.49.2014.06.26.23.47.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 23:47:29 -0700 (PDT) Message-ID: <53AD1381.9050004@gmail.com> Date: Fri, 27 Jun 2014 09:47:29 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20140626205546.713F21801AE@rfc-editor.org> , <53AD0E0D.4010209@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/eMzwyKIHAYiS3J9kHuu4j9Fz-Rg Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:47:35 -0000 Hi I get that part but would what you had in mind have any affect beyond the cellular terminal here? Basically anything on the 3GPP link? - Jouni 6/27/2014 9:28 AM, Pascal Thubert (pthubert) kirjoitti: > Efficient ND is the generic way for the RPL root to register the sensors to the phone. > > Say the RPL root connects over BTLE for instance... > > Pascal > >> Le 27 juin 2014 à 08:24, "Jouni Korhonen" a écrit : >> >> Hi Pascal, >> >> This RFC had a specific target i.e. to allow tethering in cellular environment if and when DHCPv6-PD is not available. >> >> One could use this to backhaul RPL network but not sure on which part you think efficient ND would be useful? >> >> - Jouni >> >> 6/27/2014 8:54 AM, Pascal Thubert (pthubert) kirjoitti: >>> Hello Jouni: >>> >>> This looks like another twist in the ML subnet which could be used to >>> backhaul a RPL network (replacing the LAN) over 3GPP... >>> >>> Then again efficient ND can be the gearbox between the 2 worlds... >>> >>> What do you think? >>> >>> Cheers >>> >>> Pascal >>> >>> Début du message transféré : >>> >>>> *Expéditeur:* >>> > >>>> *Date:* 26 juin 2014 22:55:46 UTC+2 >>>> *Destinataire:* >>> >, >>> > >>>> *Cc:* >>> >, >>> >, >>> > >>>> *Objet:* *RFC 7278 on Extending an IPv6 /64 Prefix from a Third >>>> Generation Partnership Project (3GPP) Mobile Interface to a LAN Link* >>>> *Répondre à:* > >>>> >>>> A new Request for Comments is now available in online RFC libraries. >>>> >>>> >>>> RFC 7278 >>>> >>>> Title: Extending an IPv6 /64 Prefix from >>>> a Third Generation Partnership Project (3GPP) >>>> Mobile Interface to a LAN Link >>>> Author: C. Byrne, >>>> D. Drown, >>>> A. Vizdal >>>> Status: Informational >>>> Stream: IETF >>>> Date: June 2014 >>>> Mailbox: cameron.byrne@t-mobile.com >>>> , >>>> dan@drown.org , >>>> ales.vizdal@t-mobile.cz >>>> Pages: 10 >>>> Characters: 19965 >>>> Updates/Obsoletes/SeeAlso: None >>>> >>>> I-D Tag: draft-ietf-v6ops-64share-10.txt >>>> >>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt >>>> >>>> This document describes requirements for extending an IPv6 /64 prefix >>>> from a User Equipment Third Generation Partnership Project (3GPP) >>>> radio interface to a LAN link and describes two implementation >>>> examples. >>>> >>>> This document is a product of the IPv6 Operations Working Group of the >>>> IETF. >>>> >>>> >>>> INFORMATIONAL: This memo provides information for the Internet community. >>>> It does not specify an Internet standard of any kind. Distribution of >>>> this memo is unlimited. >>>> >>>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>>> To subscribe or unsubscribe, see >>>> http://www.ietf.org/mailman/listinfo/ietf-announce >>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>>> >>>> For searching the RFC series, see http://www.rfc-editor.org/search >>>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html >>>> >>>> Requests for special distribution should be addressed to either the >>>> author of the RFC in question, or to rfc-editor@rfc-editor.org >>>> . Unless >>>> specifically noted otherwise on the RFC itself, all RFCs are for >>>> unlimited distribution. >>>> >>>> >>>> The RFC Editor Team >>>> Association Management Solutions, LLC >>>> From nobody Fri Jun 27 00:25:50 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC31B2F23 for ; Fri, 27 Jun 2014 00:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 SlihSTqbpJx7 for ; Fri, 27 Jun 2014 00:25:46 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B0B1B305F for ; Fri, 27 Jun 2014 00:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4504; q=dns/txt; s=iport; t=1403853947; x=1405063547; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5+zaayMnVsnaSB6ScmA3mpISctbthtnCVNTh3j/aHHg=; b=YhmW/BxbAjBD95q8sSlCcwMFoxa+GxlQeKB0RX2Z5232LDSLVvO7cIRP AsVeSp8DVlv5fiNmYJMN4Umnjup6t2VnmCxwWe8oYxCVmOUyOclj0FfhO Ac+cIkDVq5Tl3aTe3x8QXfbn/TG1ejV2nL+SCRiysJGtwNurG+4/0xY5I 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAOQbrVOtJA2G/2dsb2JhbABbgw1SqlU3AQEBAQEHilWHVYdAAYEKFnWEAwEBAQMBAQEBCUIjCAULAgEIFBAXBAchBgoBFBECBA4FCQsHAgSIDQMJCA28LQ2GUBeFZIV6fYFSIBIhAgWDLYEWBYoNjk+BfYFGiXkEgiMDhgyCAIFCbIEL X-IronPort-AV: E=Sophos;i="5.01,558,1400025600"; d="scan'208";a="56383764" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 27 Jun 2014 07:25:46 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5R7PjSm023815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 07:25:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.198]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 02:25:45 -0500 From: "Pascal Thubert (pthubert)" To: Jouni Korhonen Thread-Topic: RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link Thread-Index: AQHPkdDzgxM+/yaV7kSkyzffjDz3vpuE14OA//+23oI= Date: Fri, 27 Jun 2014 07:25:44 +0000 Message-ID: <5384EF0A-A48A-4EC8-814E-5BEC6A4FB954@cisco.com> References: <20140626205546.713F21801AE@rfc-editor.org> , <53AD0E0D.4010209@gmail.com> , <53AD1381.9050004@gmail.com> In-Reply-To: <53AD1381.9050004@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/5bBZ-oXcQ_A6RxfkA51lLGTMLms Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RFC 7278 on Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 07:25:49 -0000 No I do not think so... The value is to abstract north from south... Pascal > Le 27 juin 2014 =E0 08:47, "Jouni Korhonen" a = =E9crit : >=20 > Hi >=20 > I get that part but would what you had in mind have any affect beyond the= cellular terminal here? Basically anything on the 3GPP link? >=20 > - Jouni >=20 > 6/27/2014 9:28 AM, Pascal Thubert (pthubert) kirjoitti: >> Efficient ND is the generic way for the RPL root to register the sensors= to the phone. >>=20 >> Say the RPL root connects over BTLE for instance... >>=20 >> Pascal >>=20 >>> Le 27 juin 2014 =E0 08:24, "Jouni Korhonen" a = =E9crit : >>>=20 >>> Hi Pascal, >>>=20 >>> This RFC had a specific target i.e. to allow tethering in cellular envi= ronment if and when DHCPv6-PD is not available. >>>=20 >>> One could use this to backhaul RPL network but not sure on which part y= ou think efficient ND would be useful? >>>=20 >>> - Jouni >>>=20 >>> 6/27/2014 8:54 AM, Pascal Thubert (pthubert) kirjoitti: >>>> Hello Jouni: >>>>=20 >>>> This looks like another twist in the ML subnet which could be used to >>>> backhaul a RPL network (replacing the LAN) over 3GPP... >>>>=20 >>>> Then again efficient ND can be the gearbox between the 2 worlds... >>>>=20 >>>> What do you think? >>>>=20 >>>> Cheers >>>>=20 >>>> Pascal >>>>=20 >>>> D=E9but du message transf=E9r=E9 : >>>>=20 >>>>> *Exp=E9diteur:* >>>> > >>>>> *Date:* 26 juin 2014 22:55:46 UTC+2 >>>>> *Destinataire:* >>>> >, >>>> > >>>>> *Cc:* >>>> >, >>>> >, >>>> > >>>>> *Objet:* *RFC 7278 on Extending an IPv6 /64 Prefix from a Third >>>>> Generation Partnership Project (3GPP) Mobile Interface to a LAN Link* >>>>> *R=E9pondre =E0:* > >>>>>=20 >>>>> A new Request for Comments is now available in online RFC libraries. >>>>>=20 >>>>>=20 >>>>> RFC 7278 >>>>>=20 >>>>> Title: Extending an IPv6 /64 Prefix from >>>>> a Third Generation Partnership Project (3GPP) >>>>> Mobile Interface to a LAN Link >>>>> Author: C. Byrne, >>>>> D. Drown, >>>>> A. Vizdal >>>>> Status: Informational >>>>> Stream: IETF >>>>> Date: June 2014 >>>>> Mailbox: cameron.byrne@t-mobile.com >>>>> , >>>>> dan@drown.org , >>>>> ales.vizdal@t-mobile.cz >>>>> Pages: 10 >>>>> Characters: 19965 >>>>> Updates/Obsoletes/SeeAlso: None >>>>>=20 >>>>> I-D Tag: draft-ietf-v6ops-64share-10.txt >>>>>=20 >>>>> URL: http://www.rfc-editor.org/rfc/rfc7278.txt >>>>>=20 >>>>> This document describes requirements for extending an IPv6 /64 prefix >>>>> from a User Equipment Third Generation Partnership Project (3GPP) >>>>> radio interface to a LAN link and describes two implementation >>>>> examples. >>>>>=20 >>>>> This document is a product of the IPv6 Operations Working Group of th= e >>>>> IETF. >>>>>=20 >>>>>=20 >>>>> INFORMATIONAL: This memo provides information for the Internet commun= ity. >>>>> It does not specify an Internet standard of any kind. Distribution of >>>>> this memo is unlimited. >>>>>=20 >>>>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>>>> To subscribe or unsubscribe, see >>>>> http://www.ietf.org/mailman/listinfo/ietf-announce >>>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>>>>=20 >>>>> For searching the RFC series, see http://www.rfc-editor.org/search >>>>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html >>>>>=20 >>>>> Requests for special distribution should be addressed to either the >>>>> author of the RFC in question, or to rfc-editor@rfc-editor.org >>>>> . Unless >>>>> specifically noted otherwise on the RFC itself, all RFCs are for >>>>> unlimited distribution. >>>>>=20 >>>>>=20 >>>>> The RFC Editor Team >>>>> Association Management Solutions, LLC >>>>>=20