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: > On 13-Jul-21 17:57, Stewart Bryant wrote: >> An interesting draft Toerless. >> >> 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/UCAM-CL-TR-849.pdf > > Brian > >> >> Stewart >> >> Sent from my iPad >> >>> On 13 Jul 2021, at 00:05, Toerless Eckert <[email protected]> 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, [email protected] 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 protected] >>> >>> _______________________________________________ >>> Int-area mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> Int-area mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/int-area >> > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
