Hi Stewart, Behcet, Lin, Thanks for interest and argument on this topic, and glad to talk to you.
In general, at this stage of the discussion, we intend to focus on the communication scenarios and problems arising in those scenarios due to addressing aspects. With this, we would want to come to an understanding that a discussion on addressing is required and worthwhile. In our planned update to the draft, this focus will hopefully become clearer. Discussions on possible requirements for any solutions can follow once that broader understanding has emerged. Specifically, I try to refining questions behind the discussion, and hope it can allay doubts to certain extent. 1. Is it reasonable to have a short address/header for short payload packets? - As mentioned in "http://acticom.de/internet-of-things-iot/";, a typical payload size equals just around 25 bytes per IPv6 datagram. Thus typically the saving rate will be ((14+10+25)-(14+40+25))/(14+40+25)=38%. So typically, a 38% saving may be a good motivation for having a short address. However, we'd like to postpone quantitative analysis after we have a rough consensus on problems due to addressing aspects. 2. Does ROHC already solve the problem of trans efficiency? - ROHC is designed to be used for cellar network, and improve communication efficiency under such circumstance. Technically, it is a header compression mechanism target for L3-L4, and it is indeed work well. For this, any L3 could benefit from ROCH, while specifically, a shorter address format is more moderate for constrained devices. 3. From the two drafts, I cannot figure out what will be the header format for flexIP, are you going to have a separate draft to address this? - The header format could be described either in separate draft or be included in previous draft. The reason we have not provide a header format yet is that the address format itself is already a complex topic, so it's better for us to discuss the address first (as well as the problems and gaps), thus we can have a better understanding if a flexible address structure is a promising way to go. 4. According to the scope, flexible IP will be used for a network connected to IPv6 backbone, is that reasonable to assume the flexible IP size will be less than 128bit because the limited flexIP network should be smaller than whole IPv6 based internet? - Indeed, the network scale of limited domain is supposed to be less that IPv6, but it doesn't mean the address space should be strictly less than 128-bit. If the space of the address is abundant enough, the public key could be embedded without truncation (compare to CGA in IPv6) for certain security purpose. ------- Again, the design about a flexible address structure is indeed very rough and without header format, and a lot of philosophies and lessons can be learned from CLNP. However, based on the feedback from IETF 109, I'd love to first focus on scenarios and problems in terms of addressing, and that is what we are doing when updating the first draft "Problem Statement". Once the problem confirmed, it would be more natural to have requirements and designs that best solve the problem. How's that? :) Thanks, Yihao
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
