Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

[Toerless Eckert <[e-mail]>]

Hi Brian,

On Tue, Mar 02, 2021 at 09:08:10AM +1300, Brian E Carpenter wrote:
> There is work on supporting shorter address lengths in limited domains where that is sufficient. I don't think we have a viable use case yet for longer addresses, although we do have a need for 3GPP operators to support prefixes shorter than /64, but that's a deployment issue, not a standards issue.
> 
> (BIER doesn't strike me as such a use case; an overlay is the natural solution and it's roughly what Rick Boivie and others proposed in XCAST 20 years ago, as eventually recorded in RFC5058. I'm fairly uninformed about ICN but again it seems to me that an overlay is the natural solution and blending it into the network layer would be spaghetti engineering.)

How do you come to that conclusion ? IP Multicast where it is business relevant is
also not deployed as an overlay, and neither is BIER in the SP deployments where
the original use-cases come from.

But IMHO underlay vs. overlay is just a red herring: Any hop-by-hop forwarding protocol
ultimately is some form of overlay/underlay to some other and overlays are always
an important tool for early adoption. That does not change the need to support
flexible addrss length in one hop-by-hop protocol so that it can become a common
framwork for multiple semantics.

Of course, if i only use CPU-forwarding overlays, the cost of duplicating system
infrastructure by reinventing the whole protocol stack goes down. E.g.: if i
could build a service out of let's say only BIER, and forwarder and end-points
is all software i own, i could clone everything from IPv6, change length to 256
and call it a day. But we do know that actual solutions need access to all semantics,
as is also obvious from unicast + multicast example.

Whereas BIER duplicated the network header and is therefore a bit like the VM 
approach DCs, where 90% of code is duplicated (OS/libs), the integrated multi-semantic
network protocol is like the container approach in DC.

> It would take but a minute to design a longer-address mechanism for IPv6, although I don't have space to include it in the margin of this email**. But it would take many years for it to be widely implemented and deployed, during which time the Internet would be opaque to such addresses.

Sure. And i think like the VM/container comparison, duplicating everything
at network layer when you need a new semantic might even get you 
started quicker, but over the long term the duplication cost outweights
this. I would argue this is exactly what we also see in the duplication
between IPv6 and IPv4. Of course, no one is to blame for this because there
was a rightfull hope for IPv4 to go away, when we look back at our more
naive selfs of the 1990th (at least thats what i believed, but that was before
i was exposed mayorly to all those 90% of limited domain networks you don't
see if you only "live on the Internet").

> > We've already seen with SRv6 how more flexible use of addresses can help
> > solutions.
> 
> Have we really seen that? How many sites are running production traffic using SRv6?
> In any case, 128 bits seem to be largely sufficient for SRv6 purposes, since the semantics are local.

I think we need to distinguish a bit between the enabling of opportunities
that a technology offers and the ability of specific business models of
operators to absorb and utilize those. Of course we do have more fundamental issues
wrt. to creating new revenue through new technologies than simply building beter
network protocols. But better network protocols are IMHO a key building block.

Cheers
    Toerless

>     Brian
> 
> ** Basically, use a prefix such as fb00::/8 to indicate an extended address.

-- 
---
[e-mail]