On 7/13/21, 3:25 PM, "Int-area on behalf of Brian E Carpenter"
<[email protected] on behalf of [email protected]> 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/FUCAM-CL-TR-849.pdf
=> You mean this one: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf
Wassim H.
>
> 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
