On 02-Mar-21 22:20, Toerless Eckert wrote: > 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.
Sure. I co-authored the "limited domains" RFC, right? But when you look at Internet-wide deployment (which is surely the target for ICN, and was the original target for multicast), an overlay seems to impose itself. > 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. When 128 bits runs out, yes. Oh, I should point out that we did have a run at this topic a few years ago: https://tools.ietf.org/html/rfc1888, especially sections 4 and 5. Brian > > 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. > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
