Re: [External] Request for information - Challenges in routing related to semantic addressing

[Toerless Eckert <[e-mail]>]

Robert,*:

I would very much hope that there will still be competition in the Internet access,
even if i also believe this will require more and more regulation given how the
economics of scale work against a competitive market, but i think more and more
countries are awakening to that challenge, for example through models of
non-provider owned access fibers.

So, when there are multiple access-provider and multiple edge-cloud providers,
i hope there is enough inter-provider interop requirements to keep IETF relevant,
but not enough to have the (IMHO) service-killing transit domain in the game.

Aka: IMHO, the non-profileration of anything but best-effort service into "Internet"
is really because of transit. If the future dominant paths e.g.: in metro areas
would become:

(subscriber/edge-cloudA) -- network-providerA -X- network -providerB -- (subscriber/edge-cloudB)

Then we might actually have a better chance to grow interdomain services beyond BE
and make good lemonade out of the lemon that the IETF protocols and Internet model
is loosing relevance on the global backbone side (at least on total traffic count).

Cheers
    Toerless

On Wed, Mar 03, 2021 at 10:31:07AM +0000, Stewart Bryant wrote:
> 
> 
> > On 3 Mar 2021, at 10:05, Robert Raszuk <[e-mail]> wrote:
> > 
> > Hey Stewart,
> > 
> > If by structural changes you mean that the Internet is shifting to Google's, FB's, MS's etc private backbones ? Of course this will provide path out of this. There is no rough consensus there. 
> 
> Yes.
> 
> I agree that you do not need consensus on the private backbones although economics or the emergence of a dominant player may define one for us. It is not clear whether the IETF will be in that game, but on its current trajectory I fear that it will not.
> 
> You do need a degree of convergence in the edge if this is to work efficiently and there are other players such as 3GPP who have a vested interest in solving the problem in a common and efficient way so as to provide the connectivity needed to support the 6G vision. 
> 
> Whether this is one solution or a series of competing solution is unclear. So long as the phone can adapt, and they have proved remarkably adept at doing so, and you can build a continuous path from the network side SDR to the MEC server that is all that is needed, and we fall back to the backbone case where economics and the dominance of the participants is the driver, but commonality is not required.
> 
> - Stewart
> 
> 
> 
> > 
> > Ideas are turned into code, being tested and deployed. 
> > 
> > Best,
> > R.
> > 
> > 
> > On Wed, Mar 3, 2021 at 11:01 AM Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > 
> > > On 2 Mar 2021, at 18:21, Tony Li <[e-mail] <mailto:[e-mail]>> wrote:
> > > 
> > > 
> > > Hi Toerless,
> > > 
> > > 
> > >> You meantion locator and identifiers as unresolved. Do you think this should be subject to
> > >> more work in IETF and/or IRTF (routing) ? If so, how ?
> > > 
> > > 
> > > Not at this point, no.
> > > 
> > > We are not yet wise enough.
> > > 
> > > We looked carefully at this. One option was fixing the architecture. The other was a band-aid. We recommended fixing the architecture. The community decided that the band-aid deserved all the effort. 
> > > 
> > > The band-aid has yet to deliver anything meaningful and the architecture is not fixed.  Pretty clearly, the pain level has not reached the threshold where we will act wisely and in our own best interests. If only there was some group that was responsible for the architectural oversight of the network. But alas, there isn???t.
> > > 
> > > 
> > >> You mention architecture fundamentals and routing / addressing ties. Do you think there
> > >> such fundamentals that would transcend what i would call different "address semantics",
> > >> e.g.: unicast, multicast, ICN ? I am asking because if there where such fundamenals of
> > >> interest, maybe working on them would ease the ability to operate multiple semantics,
> > >> add and/or extend them.
> > > 
> > > 
> > > Yes, an architecture has to define all of the uses of the addressing field and explain how routing will make use of the address in each and every case.
> > > 
> > > 
> > >> You mention protocol field / address overload. I completely agree, but why then have we
> > >> not attempted to work to easier extend instead of overload packet header / addresses ?
> > > 
> > > 
> > > Because extensibility at the network layer is seen as Evil.  We decided long ago that it was impossible to have extensible addresses, despite the fact that we had working hardware. Instead, we kludge to add more fields onto the network header, requiring MORE bits to be sucked into hardware, and much more complexity than if we had just made the address field flexible. And we do so in a way that is wholly incompatible with existing hardware AND wastes gigantic amounts of bandwidth.  Good job guys!
> > > 
> > > 
> > >> E.g.: I look at TSVWG L4S carving out even more semantic out of 2 ECN bits and grumble
> > >> about printing a t-shirt "40 years of IP and all we have for QoS is still 8 bit".
> > >> (alas, corona times are no fun for t-shirt junkies).
> > > 
> > > 
> > > And it???s still more than is truly needed. ;-)
> > > 
> > > 
> > >> Personally, i wish we would never ned to overload semantics of addresses, because we are a) not
> > >> wasting address space (as you point out) and can b) amend adress space, when needed for new semantics.
> > >> Now: Why do we not amend our protocols to allow for that ?
> > > 
> > > 
> > > Because touching the architecture is the third rail.  It is our sacred cow. Pitchforks and torches come out as soon as you talk about fixing IPv6.
> > > 
> > > Our grandchildren will hate us because we cannot get past our own myopia.  We ossified the inferior and declared it inviolate.
> > > 
> > > Regards,
> > > Tony
> > 
> > 
> > Spot on Tony.
> > 
> > The question that I have in the back of my mind is whether the de-facto structural changes that are taking place in the Internet will provide a path out of this stranglehold.
> > 
> > - Stewart
> > 
> > 
> > 
> > _______________________________________________
> > routing-discussion mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/routing-discussion <https://www.ietf.org/mailman/listinfo/routing-discussion>
> 

> _______________________________________________
> routing-discussion mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/routing-discussion


-- 
---
[e-mail]