Re: [6lo] Short Hierarchial IPv6 addresses

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> On Behalf Of Haoyu Song
> Sent: Monday, October 18, 2021 12:11 PM
> To: Michael Richardson <[e-mail]>; [e-mail]
> 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%2Ficnp20.cs.ucr.edu%2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%2520Networks.pdf&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=nEGmDFjRHO2ouowt9an5h1mneyP0WxVhCtezy86mcAg%3D&amp;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 <[e-mail]> 
> Sent: Monday, October 18, 2021 11:26 AM
> To: Haoyu Song <[e-mail]>; [e-mail]
> Subject: Short Hierarchial IPv6 addresses
> 
> 
> Haoyu Song <[e-mail]> 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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ctNHIfM9cKlNOuLsxvxPd63XIsT1tCD5UICXDGTM63I%3D&amp;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 <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XoiNoRafEZc1zZpno7J3iA%2FV%2BujVPIwGCr1HDpGOk9M%3D&amp;reserved=0
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo