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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Stewart Bryant
> Sent: mardi 13 juillet 2021 7:58
> To: Toerless Eckert <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Int-area] draft-eckert-intarea-functional-addr-internets-
> 00.txt
> 
> 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 <[e-mail]> wrote:
> > 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, [e-mail]
> 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
> >
> > --
> > ---
> > [e-mail]
> >
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area