Re: [Int-area] I-D Action: draft-eckert-intarea-functional-addr-internets-00.txt

[Toerless Eckert <[e-mail]>]

Thanks Brian

I think i agree with most what you write in that memo, and i think
what i am proposing in my draft is not too much misaligned either. Putting
really the function/program/path to get to a particular destination
moves the purpose of the adress field much more away from the
"globally unique" address field that was at the root of IP/IPv6. 

I just picked the word source/destination address to at least keep
vocabulary. And remembering how we couldn't even agree in IETF about
better terminology. E.g.: all hell would break out again if the
destination address field was called "locator". But i'll be happy to
attempt calling the destination address field "forwarding-function" and
the source address field "diagnostic-function".

When it comes to names<->forwarding function, i think there can and
should be various options. Within a limited size family, relative names
seem to work fine "uncle joe" which is only valid relative to a particular
source works fine. Especially when there are multiple joe, but all with
different paths (relationship). Meaning: In many interconnected IoT/
industrial networks i can see that you do not need to bother about any
additional names, but the forwarding-function will suffice. Adding DNS
to embedded networks is often avoided due to "not required".

When it comes to other use-cases, such as Internet or anything too large
or with too many muggles involved, i am all for names. The draft has some
high level outline. In general, i tried to avoid talking about solutions
that require in-forwarding-plane name<->forwarding-function resolution,
because this can be expensive and/or slow. And i think our MPLS/IGP/VPN/BGP
architecture has teached us quite a bit how to move all this work out into
the control plane. But of course, this is in general wide open.

All the writeup in your doc about pessimisn of adoption is even more true
today than when you wrote it. I think the requirement for any new
hop-by-hop network layer are offerings where a third party could buy
a self-programmable hop-by-hop network as they can today buy compute+
networking at cloud DC for softwre routers.

Cheers
    Toerless

On Wed, Jul 14, 2021 at 10:12:20AM +1200, Brian E Carpenter wrote:
> Hi all,
> 
> I think there's a case to be made that layer 3 itself is the problem, not the details of an addressing scheme [1]. (That reference predated QUIC, but I think the main conclusions stand.) A more radical solution like NDN [2] may be needed.
> 
> [1] https://doi.org/10.1145/2602204.2602215, a.k.a. https://www.cs.auckland.ac.nz/~brian/CCR-201404-IPaddrHarmful.pdf
> 
> [2] https://named-data.net
> 
> Regards
>    Brian Carpenter
> 
> On 13-Jul-21 08:00, [e-mail] wrote:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > 
> > 
> >         Title           : Functional Addressing (FA) for internets with Independent Network Address Spaces (IINAS)
> >         Author          : Toerless Eckert
> > 	Filename        : draft-eckert-intarea-functional-addr-internets-00.txt
> > 	Pages           : 30
> > 	Date            : 2021-07-12
> > 
> > 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 datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
> > 
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets-00
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > 
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 

-- 
---
[e-mail]