Re drafts:
https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-scenarios-flexible-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yDi0mFnbU60nFC5PJC%2BAAWVIdSMT%2FY8UO0XIiK3J4iI%3D&reserved=0>
https://datatracker.ietf.org/doc/draft-jia-flex-ip-address-structure/
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-flex-ip-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XB9VFEQiaa0ZMjG5BuF%2FPeQnvFcmGgfY0%2Bye4s7CSoA%3D&reserved=0>
I have a number of comments these drafts, but in this email I would like to
focus on the small address proposal. By this I mean addresses that are shorter
than 64bits.
It seems to me that there are 3 operational reasons for small addresses:
1) That you might be worried about the amount of packet taken up by the
addresses.
2) That you might be worried about the amount of energy required to send a
packet.
3) That you want to use an address that is somehow native to a legacy
application.
… and there are at least to implementation reasons:
4) That you might be worried about the amount of memory in the FIB.
5) That you might wish to optimise out the FIB hardware.
There are two approaches to the case of addresses that are are relatively
short, where for the purposes of this discussion I define “relatively short” as
an address between 8 and 64 bits in length.
One approach is to design and implement a new packet type, be that an original
design, or the repurposing of a suitable existing non-IP design. If that is
what you have in mind it would greatly assist consideration of your work if you
published that design in the IETF, or at least pointed to it as an accessible
document. That would allow us to debate the properties of the packet and or
your address proposal in the context of the packet design. An alternative
approach which needs to be considered is to make the FlexIP address a suffix of
an existing and well known address type such as IPv6. In such a case by
standardising the corresponding IPv6 prefix you may produce implementation
simplifications, or alternatively by making it a prefix well known in the
domain you construct quite an effective leakage prevention mechanism.
Consider the IPv6 suffix case. Validating a well-know prefix before invoking
the address lookup machinery is a simple efficient process using either one of
more compare operators, or some hw technique such as a special register.
Certainly we could build hw to look up a small set of well-known prefixes that
burns a lot less energy than used in a full address lookup. So that brings us
to looking up the suffix and, by definition the table used to do that is small.
In other words most of the efficiency of doing a short address lookup can be
maintained even if the address is the suffix of a longer address provided that
the implementation is optimised for this case.
I think that argument covers much of use cases 3, 4 and 5. This applies to your
Indexes 1..EF, F0, F1 and F2 in your propose address design.
In your F5 case a longest match engine will work by definition on a variable
length address, provided it is short enough that sufficient addresses from the
primary address space can be deployed to this. Note that you can throw the
address length into the longest match engine if you wish and it will simply
consume it and if correctly programmed will return the correct result. Thus any
of the address definitions that do not contain discontinuous substructure such
as the cases with inbuilt segment routing can be looked up in a common hardware
address recognition engine without analysis of the first byte.
Now I think that it is worth looking at case 1 and 2 above and noting there is
some applicability to both the short address cases and the segment routing case
with short addresses that you propose.
Of course it is very difficult to do an accurate analysis these cases because
the packet design that FlexIP is going to be used with is not referenced by the
drafts.
Let us assume a tiny packet:
14B of MAC header (Lora is 13 to 28, Ethernet is 14)
8B of UDP
2B of payload
That is 24B + NW layer (the addresses plus the overhead)
Now consider IPv6 which is pretty minimalist for a connectionless packet apart
from the size of its addresses.
IPv6 is 40B
So total of 64B for the packet which is the benchmark since it is the IETF plan
of record for most applications.
If we reduce the addresses to 1B (the minimum in these drafts) i.e. subtract 32
- 2 = 30 so best case is packet of 34B.
That is a useful saving 47% which might be important in some specialist
applications where bandwidth or radio energy was important, however much
depends on what the practical size of the payload in, and what options or
extensions are in the packet to fulfil the communications needs. So for
example if I were to need an additional 20B of packet option and payload the
saving is reduced to 36% reducing to 20% saving if 100B were needed. A 20%
saving is not worth the cost and complexity of changing the packet.
So, to understand the benefit of reducing the address size and presumably using
it in an as yet undefined packet format it is necessary for the authors to
describe the application for small standalone addresses (as opposed to address
suffixes) in a lot more detail than is provided in the scenarios document, in
particular the size of the transport layer, and the size of the expected
payload. Additionally it is necessary that they describe the details of the
network layer packet and its MAC environment.
Once more detail is know, we will know whether there is a case for small native
addresses or whether we should focus our attention on how to map such addresses
as suffixes of a larger well known address type such as IPv6.
- Stewart
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
