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

   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

Reply via email to