Hi Adnan, Thank you for the question! In our architecture, the edge network follows a strict hierarchical tree structure. The root represents the entire edge network, each tree node represents a lower level network, and each branch represents a section of prefix. Thus, while we allow each lower level network to have multiple gateway routers (aka LGR), they must own and advertise one same subnet prefix. Only if we guarantee this, we can safely prune the destination address prefix off from a packet when it enters into this lower level network (or augment the source address with this prefix when a packet exits this lower level network).
In general, we assume one edge network is totally under a single operator. If not, then each operator should own a separate lower level network. In your scenario, node A and B should be in two different lower level networks, and they can communicate using the approaches we laid out. Hopefully I understand your question correctly. If not, please feel free to elaborate it. Thanks! Best regards, Haoyu From: Adnan Rashid <adnanrashi...@gmail.com> Sent: Thursday, November 11, 2021 4:07 PM To: Haoyu Song <haoyu.s...@futurewei.com> Cc: Uma Chunduri <umac.i...@gmail.com>; Kerry Lynn <ker...@ieee.org>; int-area@ietf.org; Alexander Pelov <a...@ackl.io>; 6...@ietf.org Subject: Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses Hi Haoyu, Consider if you have multi tenant network, then will your scheme work? If yes then how can node A from Service Provider-A can communicate with node B from Service Provider-B and both are under the same border router or edge node? Regards, Adnan Rashid On Thu, Nov 11, 2021, 20:10 Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> wrote: Thanks Uma, those are really great use cases. I would like to include them in the new revisions. My feeling is that a universal scheme like this can benefit many applications/networks (some yet to be explored) and won't introduce unnecessary conflicts and burdens to well-developed HC techniques for 6loWPAN and LPWAN. We look forward to collaborations and suggestions on where we should land this work. Please let me know if you are interested. Best regards, Haoyu From: Uma Chunduri <umac.i...@gmail.com<mailto:umac.i...@gmail.com>> Sent: Thursday, November 11, 2021 9:08 AM To: Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> Cc: Kerry Lynn <ker...@ieee.org<mailto:ker...@ieee.org>>; int-area@ietf.org<mailto:int-area@ietf.org>; Alexander Pelov <a...@ackl.io<mailto:a...@ackl.io>>; 6...@ietf.org<mailto:6...@ietf.org> Subject: Re: [Int-area] [6lo] Short Hierarchial IPv6 addresses Great discussion and inputs from many header compression experts. >So maybe for the networks or applications where low latency is a critical >requirement in addition to the bandwidth efficiency, we could find such >context-less scheme more compelling. I can with certainty give 2 such examples where I was involved multiple times w.r.t IPv6 usage: 1. A subset of mIOT UEs (this is a huge swath of UEs we are talking about) which needs low latency, high bandwidth and is sensitive to battery power. For example, a V2X UE, cares for low latency and high bandwidth but is not necessarily constrained by low battery power (though saving is always good). However, an AR/VR UE (advanced handset or 5G enabled headset) cares for all 3 (high BW, low latency and battery). 2. Another one is with LEO satellite constellations and communication from the end points. Here also only a subset of use cases/devices cares for all 3. regards! -- Uma C. On Wed, Nov 10, 2021 at 2:26 PM Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> wrote: Hi Kerry and Alexander, Thank you very much for the information. It seems the existing standards serve their purpose well. But Kerry did mention an interesting point: both these networks have low data rate and are insensitive to latency. So maybe for the networks or applications where low latency is a critical requirement in addition to the bandwidth efficiency, we could find such context-less scheme more compelling. This is very helpful discussion. Thanks a lot! Best regards, Haoyu From: Kerry Lynn <ker...@ieee.org<mailto:ker...@ieee.org>> Sent: Wednesday, November 10, 2021 9:04 AM To: Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@futurewei.com>> Cc: Alexander Pelov <a...@ackl.io<mailto:a...@ackl.io>>; Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>>; int-area@ietf.org<mailto:int-area@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org> Subject: Re: [6lo] Short Hierarchial IPv6 addresses On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song <haoyu.s...@futurewei.com<mailto:haoyu.s...@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 also good to know that SCHC already supports direct device communications. How about 6loWPAN? Same? It is important to note that there are several 6lo data links that employ RFC6282 header compression including RFC8163, which is wired. (Indeed, I believe 6282 is a common denominator of published 6lo RFCs.) So, from my perspective, I'd like your proposal to show why RFC6282 _won't_ work for your application. Re: quantitative research results for the comparative energy costs of different 6lo design tradeoffs, I believe these studies do exist and folks in t2trg might be able to point you to specific papers. Most (all?) 6lo data links are characterized by low data rates, so it's important to consider the latency win of IPv6 header compression as an additional consideration. Regards, Kerry <snip> _______________________________________________ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=04%7C01%7Chaoyu.song%40futurewei.com%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340866448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bF%2BNjIh%2BUAzrpghrC1B3Ej1S%2BSbMRY16OC9MKb46V%2B4%3D&reserved=0> _______________________________________________ 6lo mailing list 6...@ietf.org<mailto:6...@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%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340876398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2bSTwq6a3am%2B5D4iIAnFD0tqHpGJgd1TzqkuajUL%2Bzg%3D&reserved=0>
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
