Subject: Re: [Int-area] The small address use case in FlexIP

From: Jiayihao <[email-masked]>
Date: Fri, 5 Feb 2021 12:06:04 +0000

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 Feb 2021 14:31:48 +0000

> On 5 Feb 2021, at 12:06, Jiayihao <[email-masked]> wrote:
> 
> - As mentioned in "http://acticom.de/internet-of-things-iot/ <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. 

Sorry, but I think you have to discuss the quantitive aspects of the problem as part of understanding whether this is worth doing or not.

You have to ask if a  38% saving is worth the huge CAPEX and OPEX costs and feed that into the discussion.

If we are going to argue for short packets that is another matter, and that would not simply be an addressing discussion.

For example in a lot of applications the traffic is between a device and a gateway. If we allowed an out of band session setup we could support something like 500K sessions in the network with just a 4 byte network header.

So classic Ether + Classic IPv6 + 25 = 79B
   Reduced address in IPv6           = 49B (0.62 of size)
   4B n/w layer                      = 43B (0.54 of size)

So about 50% is the best we can achieve. Of course many of you will realise that there exists a 4B session oriented packet format and is one that almost every router already supports.

I think that this means that we need to have the conversation about small addresses within a much bigger context in terms of style of network communication and intended outcome and the scenarios document does not really do that analysis, but if the goal is simply minimum address size we do have an approach that we could in principle deploy today between a device and a gateway, and we should explore that.

If the requirements is a connectionless service then we really have to understand how to balance the economic cost of deploying a new packet design against a 38% saving of packet size.

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 Feb 2021 14:46:20 +0000

> - 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 c…

Again I disagree, you cannot entirely divorce the discussions.

The problem has to be solved as a whole and decisions about the packet effect decisions about the address structure. For example if the new packet is much larger than IPv6  the case for short addresses becomes even weaker.

If I look at the address design that you have proposed this is dominated by the short address constraints. If short addresses (in the physical sense rather than a logical sense where they are the suffix of a larger address) turn out to be a trivial efficiency saving, then we would almost certainly use another address design.

For example <len><family><address> as used in ISO 8474 is an extremely extensible format at a cost of a two byte overhead, and would allow the address designers to proceed independently from the packet designers and develop new address types during the deployment lifetime of the protocol. This is unlike the approach in the drafts we are discussing where a lot of discussions are proposed up front and where the development of the address architecture is significantly constrained.

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 Feb 2021 14:58:42 +0000

> - 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 e…

Interesting, what are the advantages in adding the signature of the address in the address as opposed to carrying it in a different field?

The disadvantage is that you bind the address to the signature algorithm which you would not want to do since you would expect to change the signature algorithm during the lifetime of the protocol.

Also would you really want to feed the signature into the longest match engine? Of course you could and there are some advantages in that you look up both the address and it signature, but I think you loose longest match capability and you significantly increase the size of the TCAM or other FIB design memory, and that memory is very expensive as it determines the line rate of the forwarder.

So this points back to the need for a holistic discussion of what we are trying to achieve, the extent to which modifying existing protocols satisfies that need, and whether (given the presupposed need for a gateway) we should be looking for a single protocol, a family of protocols, or an adaptable protocol.

I don’t think we can design the addressing system in the absence of a discussion on those points.

Best regards

Stewart

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 5 Feb 2021 15:12:11 +0000

Stewart, all,

As Yihao pointed out, we are working on an update to the draft to focus the discussion on the communication scenarios and problems arising in those scenarios. In that sense, we agree with your desire for a holistic discussion and see this upcoming update as one of the next towards that.

With that in mind, I suggest that we continue the discussions after this upcoming update since it is not the intention at this stage to propose any solutions or constrain any thinking about solutions but to agree that problems may exist that will need to be addressed.

Best regards,

Dirk

From: Int-area [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: 05 February 2021 15:59
To: Jiayihao <[email-masked]>
Cc: Lin Han <[email-masked]>; [email-masked]; int-area <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-area] The small address use case in FlexIP

On 5 Feb 2021, at 12:06, Jiayihao <[email-masked]<mailto:[email-masked]>> wrote:

Best regards

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 Feb 2021 18:24:52 +0000

Dear Dirk

There may be some material that you can use from

https://tools.ietf.org/html/draft-bryant-arch-fwd-layer-uc-01
And 
https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/

- Stewart

> On 5 Feb 2021, at 15:12, Dirk Trossen <[email-masked]> wrote:
> 
> Stewart, all,
>  
> On 5 Feb 2021, at 12:06, Jiayihao <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Jiayihao <[email-masked]>
Date: Sat, 6 Feb 2021 08:03:55 +0000

Hi Stewart,

Thanks for asking, and indeed the solution is not ready and still rough.

The materials you recommend highly relate to it and provide abundant information. I will read the documents and regard it as a good input for us, probably this will help in shaping a holistic design.

Many thanks,
Yihao

发件人: Stewart Bryant [mailto:[email-masked]]
发送时间: 2021年2月6日 2:25
收件人: Dirk Trossen <[email-masked]>
抄送: Stewart Bryant <[email-masked]>; Jiayihao <[email-masked]>; Lin Han <[email-masked]>; [email-masked]; int-area <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Int-area] The small address use case in FlexIP

Dear Dirk

- Stewart

On 5 Feb 2021, at 15:12, Dirk Trossen <[email-masked]<mailto:[email-masked]>> wrote:

Stewart, all,

Best regards,

Dirk

From: Int-area [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: 05 February 2021 15:59
To: Jiayihao <[email-masked]<mailto:[email-masked]>>
Cc: Lin Han <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; int-area <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] The small address use case in FlexIP

Best regards

Stewart

---

From: "Liguangpeng (Roc, Network Technology Laboratory)" <[email-masked]>
Date: Sat, 6 Feb 2021 15:45:27 +0000

Hi Stewart, Dirk and all,

These drafts are significant work which I don't think there is any conflict view to draft-jia-scenarios-flexible-address-structure. It's hard for most people to reach rough consensus on so many aspects of problem statement at the same time. So it's worth to focus on one of the most obvious ones, like encapsulation efficiency that mainly causes by the long address.

It's observed that 6lowpan approaches have solved problem at some extend, whether shall we discuss a little broad. Which means some scenarios that cannot be covered by current IP or 6lowpan mechanism. The first step may be find them and state the concrete problems, then reach rough consensus. This achievement needs further discussion and potential contributions by everyone here, thus induce to some updates to those drafts.

Best Regards,
Guangpeng

From: Flexip [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Saturday, February 6, 2021 2:25 AM
To: Dirk Trossen <[email-masked]>
Cc: Lin Han <[email-masked]>; [email-masked]; int-area <[email-masked]>; [email-masked]; Jiayihao <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>; [email-masked]
Subject: Re: [Flexip] [Int-area] The small address use case in FlexIP

Dear Dirk

- Stewart

Stewart, all,

Best regards,

Dirk

Best regards

Stewart

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 23 Feb 2021 08:56:28 +0000

Stewart, all,

You may have noticed that we did submit the mentioned update to the draft, available at https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/. I hope this addresses a few points discussed so far.

Best,

Dirk

From: Dirk Trossen
Sent: 05 February 2021 16:13
To: 'Stewart Bryant' <[email-masked]>; Jiayihao <[email-masked]>
Cc: Lin Han <[email-masked]>; [email-masked]; int-area <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Int-area] The small address use case in FlexIP

Stewart, all,

Best regards,

Dirk

Best regards

Stewart