Subject: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Jul 2021 01:04:11 +0200

Dear Int-area

As attached below, i have written up an idea about why and how variable-length
addresses in the network layer would be useful for many limited domain internetworks,
but also how they could provide a simple and easily extensible framework to
add additional semantics (the likes of multicast, BIER, ICN), and also make it easier 
to express the programmability that SRv6 introduced.

Would very much welcome discussion/feedback, and will be asking for a slot
to present/discuss this int-area 111.

Note that the -00 writeup is mostly inspirational for what i think the cool
things one could do with it are and to explain the concepts.

Obviously, if/when there is interest in this
direction, the harder work of figuring out how to best introduce this
incrementally, and ideally backward compatible into existing networks wold
be the next big set of items to work out.

Cheers
    Toerless

On Mon, Jul 12, 2021 at 01:00:25PM -0700, [email-masked] wrote:
> A new version of I-D, draft-eckert-intarea-functional-addr-internets-00.txt
> has been successfully submitted by Toerless Eckert and posted to the
> IETF repository.
> 
> Name:		draft-eckert-intarea-functional-addr-internets
> Revision:	00
> Title:		Functional Addressing (FA) for internets with Independent Network Address Spaces (IINAS)
> Document date:	2021-07-12
> Group:		Individual Submission
> Pages:		30
> URL:            https://www.ietf.org/archive/id/draft-eckert-intarea-functional-addr-internets-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets
> 
> 
> Abstract:
>    Recent work has raised interest in exploring network layer addressing
>    that is more flexible than fixed-length addressing as used in IPv4
>    (32 bit) and IPv6 (128 bit).
> 
>    The reasons for the interest include both support for multiple and
>    potentially novel address semantics, but also optimizations of
>    addressing for existing semantics such as unicast tailored not for
>    the global Internet but to better support private networks / limited
>    domains.
> 
>    This memo explores in the view of the author yet little explored
>    reasons for more flexible addresses namely the problems and
>    opportunities for Internetworking with Independent Network Address
>    Spaces (IINAS).
> 
>    To better enable such internetworks, this memo proposes a framework
>    for a Functional Addressing model.  This model also intends to
>    support several other addressing goals including programmability and
>    multiple semantics.
> 
>                                                                                   
> 
> 
> The IETF Secretariat
> 

-- 
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Jul 2021 06:57:31 +0100

An interesting draft Toerless.

From a background POV it is worth noting ISO 8473 which is in deployment with multi-type variable length address.

It is also worth noting that SA is different from DA to the extent that it may not belong in the network layer header of the outgoing packet. The SA is arguably a function of the payload and the application. Indeed some MPLS OAM solutions do just that by making the return address implicit in the arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably just a convenience for a simplified method of operating an application.

Stewart

Sent from my iPad

> On 13 Jul 2021, at 00:05, Toerless Eckert <[email-masked]> wrote:
> Dear Int-area
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Jul 2021 07:41:16 +0000

Hello Stewart and Toerless:

Please have a look at RFC 8138. 

You'll find that the header compression already changes the address size on the wire, merges the DA with the SRH as the first step in the list, that the SRH in placed at the very beginning of the transmission header, that the consumed entries are removed on the go (interesting piece that one) so the first bytes are always the DA without any shift, and that the source is mostly elided and pushed deeper in the encoding.

The next EH after the SRH is a HbH EH that contains information such as loop avoidance and Track (think detnet path or MTR) information. See more in https://www.ietf.org/id/draft-pthubert-detnet-ipv6-hbh-04.html.

Clearly as Toerless suggests, the scope is a limited domain, in this case IoT. As you also point out the forwarder only needs to consider things related to its forwarding operation.

When we published the RFC, We claimed that we did that within IPv6 as a compression / encoding sublayer as opposed to an IPvX. 

Interestingly, forwarding in the compressed form is a lot less code complexity for out tiny little objects than the normal IPv6 handling. Now, how big should a silicon forwarder be? How much can we encode in a P4 pipeline? To reach extreme performances, everything is constrained.

Could that be a foundation for your work?

Pascal

> -----Original Message-----
> From: Int-area <[email-masked]> On Behalf Of Stewart Bryant
> Sent: mardi 13 juillet 2021 7:58
> To: Toerless Eckert <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] draft-eckert-intarea-functional-addr-internets-
> 00.txt
> 
> It is also worth noting that SA is different from DA to the extent that it
> may not belong in the network layer header of the outgoing packet. The SA
> is arguably a function of the payload and the application. Indeed some
> MPLS OAM solutions do just that by making the return address implicit in
> the arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably
> just a convenience for a simplified method of operating an application.
> 
> Stewart
> 
> Sent from my iPad
> 
> > As attached below, i have written up an idea about why and how
> > variable-length addresses in the network layer would be useful for
> > many limited domain internetworks, but also how they could provide a
> > simple and easily extensible framework to add additional semantics
> > (the likes of multicast, BIER, ICN), and also make it easier to express
> the programmability that SRv6 introduced.
> >
> > Would very much welcome discussion/feedback, and will be asking for a
> > slot to present/discuss this int-area 111.
> >
> > Note that the -00 writeup is mostly inspirational for what i think the
> > cool things one could do with it are and to explain the concepts.
> >
> > Obviously, if/when there is interest in this direction, the harder
> > work of figuring out how to best introduce this incrementally, and
> > ideally backward compatible into existing networks wold be the next
> > big set of items to work out.
> >
> > Cheers
> >    Toerless
> >
> >> A new version of I-D,
> >> draft-eckert-intarea-functional-addr-internets-00.txt

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Jul 2021 09:50:57 +0200

> Please have a look at RFC 8138. 

Indeed.

For a rather different angle looking at the problem (assuming solutions such as RFC 8138 are not that hard to set up), and for ways that a limited domain could have more than the address encoded in a packet to go with (as RFC 8138 does with RFC 6282 and RFC 6775/8505), maybe also have a look at https://www.ietf.org/archive/id/draft-bormann-t2trg-interconnect-declared-00.html

Grüße, Carsten

---

From: Haoyu Song <[email-masked]>
Date: Tue, 13 Jul 2021 17:38:58 +0000

Hi Toerless,

Thanks for the interesting post!
I'm glad to see that our ICNP paper was cited in the draft. Actually, we have published a more confined draft focusing on the IoT/edge network scenarios where shorter addresses is preferred for the sake of overhead and power. 
https://datatracker.ietf.org/doc/draft-song-ship-edge/
It works in a limited domain, but interoperable with the public Internet. I think it could be a solid starting point to explore more potentials.

Cheers,
Haoyu

-----Original Message-----
From: Int-area <[email-masked]> On Behalf Of Toerless Eckert
Sent: Monday, July 12, 2021 4:04 PM
To: [email-masked]
Subject: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

Dear Int-area

As attached below, i have written up an idea about why and how variable-length addresses in the network layer would be useful for many limited domain internetworks, but also how they could provide a simple and easily extensible framework to add additional semantics (the likes of multicast, BIER, ICN), and also make it easier to express the programmability that SRv6 introduced.

Would very much welcome discussion/feedback, and will be asking for a slot to present/discuss this int-area 111.

Note that the -00 writeup is mostly inspirational for what i think the cool things one could do with it are and to explain the concepts.

Obviously, if/when there is interest in this direction, the harder work of figuring out how to best introduce this incrementally, and ideally backward compatible into existing networks wold be the next big set of items to work out.

Cheers
    Toerless

On Mon, Jul 12, 2021 at 01:00:25PM -0700, [email-masked] wrote:
> URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-eckert-intarea-functional-addr-internets-00.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C3c81596a99d3460cf2e508d94589927c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637617279468801601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ExCIn44YmRXtiKiszaMHFj3imh0jCsNdSoysc72gssg%3D&amp;reserved=0
> Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-eckert-intarea-functional-addr-internets%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C3c81596a99d3460cf2e508d94589927c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637617279468801601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FUkLzyyg7odcV6bzonjqG%2BBR3CcJNGnMVyUbFWM7w6o%3D&amp;reserved=0
> Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-eckert-intarea-functional-addr-internets&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C3c81596a99d3460cf2e508d94589927c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637617279468811569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=0zd8Rddiznht1FkA2CriwibvoF%2F22ZoDprWfamk4ffM%3D&amp;reserved=0
> 
> 
> Abstract:

--
---
[email-masked]

_______________________________________________
Int-area mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C3c81596a99d3460cf2e508d94589927c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637617279468811569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=6wISfAX8txApQpGt4ab8GVIEK3i3QrQyZb1vMooeX%2FA%3D&amp;reserved=0

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jul 2021 10:25:02 +1200

> From a background POV it is worth noting ISO 8473 which is in deployment with multi-type variable length address.

Pretty ugly and limited though, and as I understand it the major (unclassified) deployment, in the airline trade, is trying to migrate away. I have no idea if there are classified deployments, but if so, I expect they use the non-variable GOSIP format.

I think ISO 8473 is a pretty good model of how not to do it.

> It is also worth noting that SA is different from DA to the extent that 
it may not belong in the network layer header of the outgoing packet. The 
SA is arguably a function of the payload and the application. Indeed some 
MPLS OAM solutions do just that by making the return address implicit in the arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably 
just a convenience for a simplified method of operating an application.

My favourite article on that topic is https://www.cl.cam.ac.uk/techreports/FUCAM-CL-TR-849.pdf

   Brian

>> Note that the -00 writeup is mostly inspirational for what i think the 
cool

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 13 Jul 2021 22:42:35 +0000

On 7/13/21, 3:25 PM, "Int-area on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

=> You mean this one: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf

Wassim H.

    cool

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jul 2021 11:16:30 +1200

I am told that the URL below is broken. 

Sorry, my bad. Try https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf

The citation is Marcelo Bagnulo Braun and Jon Crowcroft, SNA: Sourceless Network Architecture, Technical Report Number 849, Computer Laboratory, University of Cambridge (2014), UCAM-CL-TR-849, ISSN 1476-2986.

Regards
   Brian Carpenter
On 14-Jul-21 10:25, Brian E Carpenter wrote:
> My favourite article on that topic is https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf
> 
>    Brian
> 
>>
>> Stewart
>>
>> Sent from my iPad
>>
slot

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 14 Jul 2021 03:27:14 +0200

> Pretty ugly and limited though, and as I understand it the major (unclassified) deployment, in the airline trade, is trying to migrate away. I have no idea if there are classified deployments, but…

Maybe a side-thread better moved over to intenet-history ?
At least let me change the subject.  But i am curious,
because before IPv6 came along i was very
much hoping to see benefits of CLNP to go into IP-NG.

I am specifically a fan of routing host-addresses within a domain
because i think its the mayor reason for Ethernet subnets to eat IP
for breakfast (displaying more and more L3 at the edge). Even back
in the beginning of the 90th i did do IP host routing with RIP for
multi-homed hosts. So i had hoped IPv6 to include this benefit
of CLNP. Or at least a decade later MIF.

No memory of the specific of variable length addressing in CLNP though
I know i had different length addresses in CLNP deployment in the 90th,
but within a university i did (of course?) not recognize any of the
extension/operational benefits that much.

Btw: Completely agree the administrative decision for IETF not to invest
into CLNP given the ownership of the protocol by a politicised SDO,
but re-using good idea instead of NIH would really be nice. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Hesham ElBakoury <[email-masked]>
Date: Tue, 13 Jul 2021 21:50:09 -0700

It looks like almost nobody cares about CLNP anymore.

On Tue, Jul 13, 2021, 6:27 PM Toerless Eckert <[email-masked]> wrote:

> > > From a background POV it is worth noting ISO 8473 which is in
> deployment with multi-type variable length address.
> >
> > Pretty ugly and limited though, and as I understand it the major
> (unclassified) deployment, in the airline trade, is trying to migrate away.
> I have no idea if there are classified deployments, but if so, I expect
> they use the non-variable GOSIP format.
>
> > My favourite article on that topic is
> https://www.cl.cam.ac.uk/techreports/FUCAM-CL-TR-849.pdf
> >
> >    Brian
> >
> > >
> > > Stewart
> > >
> > > Sent from my iPad
> > >
> variable-length
> > >> addresses in the network layer would be useful for many limited
> domain
> > internetworks,
> > >> add additional semantics (the likes of multicast, BIER, ICN), and
> also
> > make it easier
> > >>> Title:        Functional Addressing (FA) for internets with
> Independent Network Address Spaces (IINAS)
> > >>> URL:
> https://www.ietf.org/archive/id/draft-eckert-intarea-functional-addr-internets-00.txt
> > >>> Status:
> https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
> > >>> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets
> > >>>
> > >>>
> > >>> Abstract: