Re: [Int-area] CLNP rants (was: Re: draft-eckert-intarea-functional-addr-internets-00.txt)

[Hesham ElBakoury <[e-mail]>]

It looks like almost nobody cares about CLNP anymore.

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

> On Wed, Jul 14, 2021 at 10:25:02AM +1200, Brian E Carpenter 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.
>
> 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
>
> > 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
> >
> > >
> > > 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
> > >
> >
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>