Re: [Int-area] Introductions of 2 new drafts in Intarea wg

[Dirk Trossen <[e-mail]>]

Luigi, Yihao, all,

Thanks for initiating this work. For some comments, please see inline.

Best,

Dirk

From: Int-area [mailto:[e-mail]] On Behalf Of Luigi Iannone
Sent: 18 November 2020 07:39
To: Jiayihao (Network, 2012 Lab) <[e-mail]>
Cc: Yanshen (2012 NGIP) <[e-mail]>; Dangjuanna <[e-mail]>; Chenzhe (Z) <[e-mail]>; [e-mail]; Sheng Jiang <[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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.

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?

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.

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).


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.

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?

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?

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.

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.

Also, how is address order decided? From my understanding it depends on the order of domains packets travers, right?

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.

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?

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.


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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/int-area