Re: [6lo] Short Hierarchial IPv6 addresses
Alexander Pelov <a@ackl.io> Wed, 10 November 2021 09:30 UTC
Return-Path: <alexander@ackl.io>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2973A0B6E for <6lo@ietfa.amsl.com>; Wed, 10 Nov 2021 01:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20210112.gappssmtp.com
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 jzdepxfGFvzF for <6lo@ietfa.amsl.com>; Wed, 10 Nov 2021 01:30:01 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E533A0B55 for <6lo@ietf.org>; Wed, 10 Nov 2021 01:30:00 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id z26so2005545iod.10 for <6lo@ietf.org>; Wed, 10 Nov 2021 01:30:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gvalMugdUow3ieemGlGDx0eRdMlNVQMmWk1sVkOUZ7Q=; b=kT/rnwElf6o9Q8XwI0K0FEpNZAmhfTzM1n5Vs6e3qZvJmM6kVLwU0QwGxhknrc9SAV s4YcaiUJjPZuoVcyT2rvg80hdYXdNp+QpsjQAr4ojxmW9vGqZVEJN7m2g6YJHFbbULaN 1mPPR8+O01VP2F2SIybizifYc22YtkS/u/+ooo/tpdq1k6dD7U106VMHQEVhxR9KmPnl czO2uVvRYKFU3CxYDKsD4HWd6kxOe8AHYSgBAVksYV8toKd4QPRXu/GprFVUSGfbwv/F 4BVTvh5WP2y6+VB1BiCjz3udbgmLRIhxoI1lbagn6fkxARNjHo1kqSqDumsGJWrCS5E/ Is9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gvalMugdUow3ieemGlGDx0eRdMlNVQMmWk1sVkOUZ7Q=; b=Sfj/N61f9FU1X5XP/H7zEpnRMaHnO8+IpHbR0+dE/GPd1crHwW37SOAEscGRNjdkHC /aJPkg1+D8yNCFHj+kQ4AfUkek/++cH/shCNqtr19sylxdWudRL/JqH7SqkOw8LhOKrE 4Jp5nTa6E5NyBGZxG+1kVVA24AifHhfT8vZUyDuH8SxYZurMbCRRWshdIe4V7y1rbna1 yuL3lZaSnAaOWc0TF9qm2CsDDs2283QW0VDG0XiV+1Wvbl3dfiYfLDpnNijyM0waxb6P MOkEnvuByV2gGNR1IEf0xGJXu0P8QoEKXUSAIWSjfYsnB8bmr1TnLyF9isxqPsxFgTx5 nsKw==
X-Gm-Message-State: AOAM530d4UQhoDwuzbJs/Sm3uw3634dm2XwhHDP9wneCunRv2vxiAkI8 zxGOWxDfW1iGMTHgRUOYAJ1vkVeUWCA1ilCA0tgFjA==
X-Google-Smtp-Source: ABdhPJxWWhCXUaSjqRZIC9S9V2q924a+XvK0EA4nNVj326MtLezjo8vUFrUXa/fBngBEyRwrLnd/PjNFDcNzzSBGLZM=
X-Received: by 2002:a02:85a9:: with SMTP id d38mr10911078jai.71.1636536599179; Wed, 10 Nov 2021 01:29:59 -0800 (PST)
MIME-Version: 1.0
References: <b9d172392013f578cdbd8e7120f6154e.squirrel@webmail.entel.upc.edu> <BY3PR13MB47870F8078E156139DE953769ABC9@BY3PR13MB4787.namprd13.prod.outlook.com> <16151.1634581572@localhost> <BY3PR13MB4787D81E9B56FBBEA62EA28A9ABC9@BY3PR13MB4787.namprd13.prod.outlook.com> <BY3PR13MB4787BBE8A65861E0927E615C9A919@BY3PR13MB4787.namprd13.prod.outlook.com> <5CB1DC41-6BB9-4251-A080-207120F0311E@cisco.com> <BY3PR13MB47875C6A873BBA1FDD9F9E9F9A929@BY3PR13MB4787.namprd13.prod.outlook.com> <CACQW0EovGkJFiiN29Y3yadVQiXLyjHu6jsFJWYvZv+Rwu7JSqg@mail.gmail.com> <BY3PR13MB4787C4DF1D74A7BD79995BD39A939@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB4787C4DF1D74A7BD79995BD39A939@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Alexander Pelov <a@ackl.io>
Date: Wed, 10 Nov 2021 10:29:47 +0100
Message-ID: <CACQW0EoGH77a-8i_h2awhm4c5FUq+q45fgw=7-z3_xsdvEAKKQ@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "int-area@ietf.org" <int-area@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a80ab005d06bde1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/LxhMVKb7LYczCDlIkGx4j-vzUig>
Subject: Re: [6lo] Short Hierarchial IPv6 addresses
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 09:30:07 -0000
Dear Haoyu, Thanks for your reply! See inline On Wed, Nov 10, 2021 at 1:14 AM Haoyu Song <haoyu.song@futurewei.com> wrote: > Hi Alexander, > > > > Thanks for the clarification! It seems you suggest that the bandwidth > efficiency (i.e., the header overhead) is much more important than the cost > of storage and processing in wireless. It would be great if we could find > some quantitative research results. Is there any such info available? > It's always a tradeoff. That (and others) are also the reason you do Header Compression. Otherwise we'd be just sending out raw IPv6 packets. > It’s also good to know that SCHC already supports direct device > communications. How about 6loWPAN? Same? > Yes, by design. > > > Given all these, can short address, if supported, make things a little > better (i.e., further shrink the header size)? > With SCHC you can go down to 1 bit if you want (here I'm pushing the limit of course, but this serves as an illustration). > Or we believe the current schemes are already good enough and we shouldn’t > bother? > I'd say that the schemes that we have are already good enough. > > > Does this scheme benefit the wifi and other types of wireless networks, > assuming no other HC schemes are applied? > Yes, it does apply. You can run SCHC (and 6LO) on any L2 medium - the point is that in some cases the gain is less than the effort. It's always a tradeoff. If you need to reduce the header sizes, I think you already have an extremely rich set of options in the face of 6LO and SCHC. > > > I’m relatively new to this field and I know there were already tons of > work, so any expert opinions and advices are highly appreciated. Thanks a > lot! > > Sure, you are welcome Cheers, Alexander > > > Best regards, > > Haoyu > > > > *From:* Alexander Pelov <a@ackl.io> > *Sent:* Tuesday, November 9, 2021 2:05 PM > *To:* Haoyu Song <haoyu.song@futurewei.com> > *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>; int-area@ietf.org; > 6lo@ietf.org > *Subject:* Re: [6lo] Short Hierarchial IPv6 addresses > > > > Dear Haoyu, > > > > Thanks for the questions. > > > > A couple of thoughts inline. > > > > > > On Tue, Nov 9, 2021 at 10:25 PM Haoyu Song <haoyu.song@futurewei.com> > wrote: > > Copied to INTAREA WG because this was also discussed in it. > > Hi Pascal, > > Thank you very much for the suggestions which are very helpful! The high > level idea is indeed drawn from PSTN and PNNI, the proven technologies. > > Our P4 prototype evaluation shows that the extra router processing is > doable with little impact on forwarding performance. Meanwhile, both data > plane and control plane are significantly simplified (e.g., smaller and > regular FIB, simplified routing protocols) which actually leads to lower > router cost. So from the implementation point of view, I have confidence on > it. > > The scheme is applicable to other environments as well, for example, data > center networks, where east-west low-latency communication is dominant. I > agree with you that the discussion is more an IAB one, but some folks in > INTAREA also suggest I may go to 6lo. This makes me a little confused. I > need more advices on how to proceed with the work, and welcome people who > are interested in this work to join me. > > I also have some questions for the 6lowpan and LPWAN header compression > schemes. Aren't the context storage and compression/decompression > computing a source for resource/energy consumption? Is there any evaluation > results on their impact? > > > > The energy cost of a couple of "for" cycles is negligible compared to the > energy necessary for wireless communications. In a more generic setup, the > Static Context Header Compression will depend on the number of static > contexts you have. If I understand correctly the short address proposal, > that would mean roughly one context per address length. Assuming a subnet > has the same 'address length' would mean a single context would suffice, > which means - unmeasurably-small energy consumption (not to say 0). > > > > If shorter addresses are introduced as an additional feature, it may > improve the situation. Another issue I'm concerned is that in 6lowpan/LPWAN > (maybe I'm wrong) it seems that an end node can only talk with a server > through a gateway. I think it may be needed for end nodes to directly > communicate with each other in many cases. If so, do we need some > context-free compression schemes? > > > > The initial way of working for SCHC was indeed in the Device<->Gateway > paradigm. However, it has become quite obvious that there is a direct > extension in a "SCHC Peer" mode (when the Device and the Gateway are > equally capable for example), where there is no need for intermediate > elements. > > > > So, the short answer is - SCHC already has what you want to achieve in > terms of reducing the bits on the air/wire. > > > > Best regards, > > Alexander > > > > > > > > > > > > > > Sorry for the lengthy email. I just wanted to gain a better understanding > on the situation. Thanks! > > Best regards, > Haoyu > > -----Original Message----- > From: Pascal Thubert (pthubert) <pthubert@cisco.com> > Sent: Monday, November 8, 2021 10:08 PM > To: Haoyu Song <haoyu.song@futurewei.com> > Cc: 6lo@ietf.org > Subject: Re: [6lo] Short Hierarchial IPv6 addresses > > Hello Haoyu: > > If I get your proposal well, this is a bottom up aggregation approach when > IP has been traditionally top down. IP extends the prefix length that the > router looks into as we dive down the hierarchy as opposed to building the > address as you extend the reach in this draft. > > At a high level, there’s a bright and a dark side. > > Bright side: > > It can be made to work as proven by other similar mechanisms like domain > name and PSTN. It simplifies the host knowledge of its domain. > > There’s neat routing technology like PNNI that could possibly do a great > job with bottom up aggregation. > > Dark side: > > 6lo does not need a new compression. We already have a simple mostly > stateless one with 6282 and a more complex stateful with SCHC. Too many > standards kill the standard. > > The scheme moves the complexity from the hosts to the network and I’m not > sure what kind of effort it would take to uplift that. In comparison going > IPv6 looks a minor step. In any case this is not a 6lo discussion, more an > IAB one. > > In short I do not recommend to use 6lo as the forum. You need a larger > audience with routing and operations involved. > > Keep safe, > > Pascal > > > Le 9 nov. 2021 à 00:58, Haoyu Song <haoyu.song@futurewei.com> a écrit : > > > > Hi WG, > > > > In today's session I don't have enough time to finish my presentation. > I think it's important to highlight the difference between our scheme (aka > SHIP) and the compression schemes used by 6LoPAN and LPWAN. Please let me > know if you have further questions or suggestions. > > > > 1. SHIP is hierarchical, extending from edge to core 2. SHIP is > > applicable to all kinds of networks, in contrast to: > > - 6LoPAN: IEEE 802.15 > > 3. SHIP is applicable on arbitrary network topology, in contrast to: > > - HC is applicable on "point-to-point" channel only > > - Compressed packet is not routable unless decompressed first 4. > > SHIP only concerns the IP addresses, orthogonal to the compression > > technique on the other header fields 5. SHIP is solely determined by > > the subnetworks, needing no dynamic context negotiation or static > > context configuration 6. SHIP allows communication between any > > Internet-addressable nodes > > > > Best regards, > > Haoyu > > > > -----Original Message----- > > From: 6lo <6lo-bounces@ietf.org> On Behalf Of Haoyu Song > > Sent: Monday, October 18, 2021 12:11 PM > > To: Michael Richardson <mcr+ietf@sandelman.ca>; 6lo@ietf.org > > Subject: Re: [6lo] Short Hierarchial IPv6 addresses > > > > Hi Michael, > > > > Thank you very much for your comments! > > I said it's orthogonal to RFC6282 due to the fact that this draft only > concerns about the address part. Since each edge node only needs to keep a > shorter address, the power and storage associated with it are both reduced. > It can be combined with shared context between two nodes (as described in > those context based compression schemes) to achieve further compression. In > this sense, I said they are "orthogonal". > > > > Having said that, I think it can also be a standalone scheme. If the > resulting overhead due to the short address can already satisfy the > application need, then there are merits to use this scheme alone, for the > following reasons: > > 1. Because there is no need to maintain the context between peers, the > storage for context and the computing for compression/decompression can > both be optimized, which I think is critical in the low power and low > capacity IoT scenarios. > > 2. There would be no limitation to the network topology (e.g., star). > Edge nodes can talk to each other directly and communicate with Internet > freely. I think this is another advantage that the other compression > schemes are difficult to achieve but the application may desire to have. > > > > Here are some other clarifications to your questions: > > > > 1. Based on our evaluation, while retaining all IPv6 header information, > our scheme can reduce the IPv6 header overhead from 60% to 70% (i.e., from > 40B to 12~16B). I'll add the evaluation in the future draft revisions. > > > > 2. Yes it can be seen as a static compression scheme, in which the most > compression benefit is from the size reduction of the IP addresses. Since > there will be an IPv6 gateway towards external world, some other header > fields within the edge network can also be reduced or simplified. > > > > 3. The edge network below the IPv6 gateway appears to be a subnetwork to > the Internet. Within the edge network, the network is hierarchical and the > routing in it is straightforward. In the following paper, we described how > the conventional and yet simplified version of IGP and BGP can be used > within the edge network for routing. > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ficnp > > 20.cs.ucr.edu > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F20.cs.ucr.edu%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001488608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cl4hClbyFCzSr6JQvHlbDtor3YxrRvMTmCAI0mTetN0%3D&reserved=0> > %2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2 > > 520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%252 > > 0Networks.pdf&data=04%7C01%7Chaoyu.song%40futurewei.com > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001498564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q1WwkK5qVALwX%2FzpDYAkasiH2HG1SEcb62LECRccwLc%3D&reserved=0> > %7C95bdf073 > > 45f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C > > 637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g8JFn7V2%2B3i > > cgPEF7ADTaTcPr9DQNOeZjwyRrZR8i24%3D&reserved=0 > > Thanks to the hierarchical architecture, the forwarding table and the > router function will be greatly simplified, which is naturally beneficial > for power, memory and energy. > > > > Best regards, > > Haoyu > > > > -----Original Message----- > > From: Michael Richardson <mcr+ietf@sandelman.ca> > > Sent: Monday, October 18, 2021 11:26 AM > > To: Haoyu Song <haoyu.song@futurewei.com>; 6lo@ietf.org > > Subject: Short Hierarchial IPv6 addresses > > > > > > Haoyu Song <haoyu.song@futurewei.com> wrote: > >> Title: Short Hierarchical IP Addresses at Edge Networks > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ship-edge%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ship-edge%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001508522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Boyp0fD4%2Fg%2BtO3wiqSP7LDc6i4UpZHB8cEQSbBd%2FIrM%3D&reserved=0> > . > >> Abstract: To mitigate the IPv6 header overhead in edge networks, this > >> draft proposes to use short hierarchical addresses excluding the > >> network prefix within edge networks. An edge network can be further > >> organized into a hierarchical architecture containing one or more > >> levels of networks. The border routers for each hierarchical level > >> are responsible for address augmenting and pruning. Specifically, > >> the top-level border routers convert the internal IP header to and > >> from the standard IPv6 header. This draft presents an incrementally > >> deployable scheme allowing packet header to be effectively compressed > >> in edge networks without affecting the network interoperability. > >> Presenter: Haoyu Song > >> Purpose: gain awareness and interests from the WG, collect feedback > >> and suggestions for the next step > > > > Interesting. I browsed the document quickly. > > > > I'm not sure I understand how it is "orthogonal" to RFC6282. > > It seems to be an alternative. If it was orthogonal, then it would work > on a different basis vector, and I could use both at the same time. > > > > It seems like you are doing a static compression scheme by re-encoding > > the > > IPv6 header to a new format. > > > > I hope to see some table explaining the size of your header compared to > RFC6282. > > > > Since you have assumed some kind of hierarchal network, would you use > RFC6550 for routing, or is it that you don't need any routing due to your > architecture? > > > > -- > > Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT > consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001518479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZaU6SZhq6xC40tlVRRcyheLwwSlOePpDgpMz%2FpjP6Uc%3D&reserved=0> > %2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40fu > > turewei.com > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001528433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xNqTgrhcVd4LFeXUPhq9mTF3dP%2BF0hVzVRCOZb8dleM%3D&reserved=0> > %7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753 > > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&reserved=0 > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001538389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q0JGW%2FYIgBIP80dhv%2B9lBiGULLvoi%2B%2BHBW6DD0LApVQ%3D&reserved=0> > %2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40fu > > turewei.com > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001548347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AHxXzuyoIvlhQcovslbGB2KM8dCuBGkwedil2pq0qnk%3D&reserved=0> > %7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753 > > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&reserved=0 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001558302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IwtcTiNT%2BRz1ulGmMW4FhbNwRmuT%2Bdm%2BRTSs6UzIEJs%3D&reserved=0> > >
- [6lo] Call for agenda items - 6Lo session at IETF… Carles Gomez Montenegro
- Re: [6lo] Call for agenda items - 6Lo session at … Haoyu Song
- [6lo] Short Hierarchial IPv6 addresses Michael Richardson
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] Short Hierarchial IPv6 addresses Pascal Thubert (pthubert)
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] Short Hierarchial IPv6 addresses Alexander Pelov
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] Short Hierarchial IPv6 addresses Alexander Pelov
- Re: [6lo] Short Hierarchial IPv6 addresses Kerry Lynn
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Uma Chunduri
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Haoyu Song
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Adnan Rashid
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Haoyu Song
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Adnan Rashid
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Michael Richardson
- Re: [6lo] Short Hierarchial IPv6 addresses Pascal Thubert (pthubert)
- Re: [6lo] Short Hierarchial IPv6 addresses Haoyu Song
- Re: [6lo] [Int-area] Short Hierarchial IPv6 addre… Haoyu Song