Hi Dirk, Luigi, all, Thanks for your suggestions and comments for these 2 drafts. I feedback some of my thoughts inline, and I wish it could answer your questions to some extent. I'll fix them with more details in the next version of the draft.
Many thanks to you, and more comments are welcomed! Yihao ---------------------------------------------------- Luigi, Yihao, all, Thanks for initiating this work. For some comments, please see inline. Best, Dirk From: Int-area [mailto:[email protected]] On Behalf Of Luigi Iannone Sent: 18 November 2020 07:39 To: Jiayihao (Network, 2012 Lab) <[email protected]> Cc: Yanshen (2012 NGIP) <[email protected]>om>; Dangjuanna <[email protected]>om>; Chenzhe (Z) <[email protected]>om>; [email protected]; Sheng Jiang <[email protected]> Subject: Re: [Int-area] Introductions of 2 new drafts in Intarea wg Hi, Thanks for you documents, inline a few comments On 11 Nov 2020, at 18:25, Jiayihao (Network, 2012 Lab) <[email protected]<mailto:[email protected]>> wrote: Dear All, Last week I submitted 2 I-D on Intarea WG under the topic of a flexible IP address structure. I'd like to share the key points of these 2 I-D before it could be discussed at IETF 109. First, we see that increasingly networks expect a direct TCP/IP stack for its global reachability and facility. However, various scenarios naturally face challenges when adopting current IP protocol. As one example, satellite networks introduce routing oscillation due to topology dynamics, leading to low routing efficiency even though it is theoretically possible. The first I-D describe these well-recognized scenarios that prefer a "flexible" IP address structure. By "flexible" in this I-D, we mean that the IP address is constructed as multi-semantics and length variable. [Luigi] I am not a satellite expert, but can you elaborate more on when there will be routing oscillations? Also making an example on how a flexible address approach may help in mitigating the problem? [Yihao]->Basically, the OSPF or BGP work on a static topology, which means the routing tables update only when a new route is going to be announced on that topology. If the topology is keep changing, e.g., the topology of satellite is changing periodical as time goes by, new updates will be initialed through the routing protocol whenever the topology change. I remember that, according to a technical report, around 90% of the time will be used for routing convergent, leading to inefficient routing. Numerous researches prefer a geo-location based routing for performance consideration, but inefficient addressing in IPv6 comes to another problem. Here, we expect that if the address structure is somehow flexible, addressing geo-location information if the address may not be a problem. [Luigi] I read the document, I think it would be nice if in section 3.1 an example is added. To better explain the IoT addressing issue. In the current form only IoT expert can really figure out what are the issues. [Yihao]->Thanks, I will represent the this section with more gap analysis when revising. [Luigi] I like section 3.5 about security. Having addresses with variable length can open interesting opportunities from that perspective. [DOT] I would suggest adding more references from works that point out problems in the various areas of Section 3 to support the possible arguments for a flexible address structure. It seems that the flex address structure draft has some of such references but it may be good to have those in the scenarios draft already. This may then also lead to a concise list of 'problems' with the current address model that can then be targeted in the following discussion on requirements and possible solution(s). [Yihao]-> Thanks, I'll fix the issue. Based on scenarios and the correlated requirements, the second draft describe an instance of a potential "flexible" IP address structure, i.e., FlexIP, and details the considerations behind the design. To still benefit from global reachability, FlexIP is expected to work only in limited domain (RFC8799) and be interoperable with IPv6. The main purpose of FlexIP design is to construct a flexible network address, and such address should be prospective enough to accommodate unforeseeable scenarios and futuristic requirements. [Luigi] The document mention an IPv6 based "backbone". Is there any specific consequence with respect to this assumption? Or is just recognizing the fact that IPv6 plays a central role? [Yihao]-> It is just recognizing the fact that IPv6 is (going to) play the role of the "backbone" [Luigi] The aim of Figure 1 of the document is not that clear to me. Are you just willing to show that between the FlewIP limited domain and Ipv6 a "translator" is necessary? [Luigi] Figure 1 includes two messages: 1) FlexIP works at the edge of the Internet, just like the IPv4; 2) FlexIP connects the IPv6(backbone), indirectly, through a translator. [Luigi] In section 5 it is stated that the address structure is hierarchical, however, it is not clear to what this hierarchy actually is. Can you elaborate more on this? [DOT] I suggest to more clearly outline the concept of the hierarchy, which in envisioned here, along the realization of it. I reckon that Luigi's comment may aim at the same. [Yihao]-> Thanks, I'll fix it. In general, for a 2-layer hierarchy, the address is constructed by 2 segments. If we take international phone number as an example, the first segment is the country code, and the second segment is the local phone number (probably with different length). [Luigi] Section 6 show a few example on how to concatenate and represent addresses, I think would be useful to make a complete example on how communication happens in a toy scenario. [DOT] Agree, examples are good, particularly at this stage of the discussion. [Yihao]-> Thanks, I'll add an example here to detail the process. [Luigi] Also, how is address order decided? From my understanding it depends on the order of domains packets travers, right? [Yihao]-> Yes, we miss some details here. The segments inside the address should be used by sequence, and it should be planed before address assignment. [Luigi] Have you considered having a free form "experimental" address for future experimentation? Something to be used only in private deployment to play with possible future solutions? [DOT] I like this suggestion since it would allow for support explorative work, inviting contributions along the possibilities of the experimental address. [Yihao]-> Great suggestion! I'd like to provide an experimental address structure for experiments. I'll put it in then. [Luigi] The format proposed looks like it supports only addresses but not prefixes. Is this a deliberate choice? If yes, can you elaborate on the motivation? Can prefixes can be represented? So that the proposed encoding could be used somehow also in control plane exchanges? [Yihao]-> Actually we mean to eliminate the concept of "prefixes" to some degree. In FlexIP hierarchy, the first segment could be used as the prefix. A final editorial remark, your IANA considerations section is empty you should ask IANA to create a registry containing all the code points described in section 5, also deciding what should be the policy for allocating new code points in this registry. [Yihao]-> Yes, and thus a design involves IANA considerations, and I plan to introduce it later of the community reach a rough consensus. Thanks L. Attached below are 2 I-D that mentioned in this email. I would be happy if you have any questions on this topic. Warmly welcome! ---------------- Draft 1: Scenarios for Flexible Address Structure https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/ Draft 2: Flexible IP: An Adaptable IP Address Structure https://datatracker.ietf.org/doc/draft-jia-flex-ip-address-structure/ Thanks, Yihao Jia. _______________________________________________ Int-area mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
