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

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Mar 2021 13:57:40 +0100

Thanks, Tony, *:

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 ?

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.

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 ?
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).

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 ?

Cheers
    Toerless

On Mon, Feb 15, 2021 at 09:43:41AM -0800, Tony Li wrote:
> 
> 
> > On Feb 15, 2021, at 8:10 AM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > I can't argue with an effort to define the term "semantic routing".
> > However, I would be very concerned by an effort to define goals for it before we have such a definition.  Depending upon the definition, the answer may be that it is a bad idea.
> 
> 
> 
> I???ll go a bit farther.
> 
> In reading this draft, I???m struck by the lack of clear articulation of some of the fundamentals of the architecture. Routing and addressing are functionally tied together and 
> any discussions of modifications to one requires a clear discussion of how it would affect the other function. We learned long ago that overloading functionality on packet fields is a poor design choice,
> and even the early decision to overload identification onto location has had profound and deleterious effects that we have still not overcome.  In fact, you list the impacts of this architectural error
> as things that you???d like to fix: multihoming, mobility, and multipath routing.
> 
> It???s also somewhat concerning when you list Scalability as one of the goals that you are proposing to fix with semantic overloading. It should be clear that any overloading of the address space
> will reduce, not improve, its flexibility and thereby limit, not enhance Scalability.
> 
> If and when there is a clear definition of ???semantic routing??? and a clear proposal on how to move forward, there must also be a clear discussion of the affects of overloading addressing will
> affect routing.
> 
> The original purpose of giving IPv6 128 bits of address space was to ensure that there was continued scalability for the routing system for the next 20 years (which have now expired ;-). In fact,
> what we???ve learned is that transitioning to a new network layer takes a lot longer than what we had hoped and that the lifetime of a network layer is far more than expected. Thus, we should
> be aiming to preserve IPv6 functionality in perpetuity and not simply for the next generation. To this end, we must be very careful about any unintended side-effects from overloading addressing,
> especially with regards to routing scalability.
> 
> We have a fine example of this when we decided that most end sites would be granted a /64 prefix. This effectively took half of the addressing bits off of the table for global routing and since addressing is
> hierarchical, this was a logarithmic decrease in overall routing scalability. Meanwhile, most of the individual sites are domestic networks that will never ever subnet.
> 
> So, please be very clear about the impacts of any proposal that suggests overloading addressing. The impact to the architecture will definitely be non-trivial and thus it bears careful consideration.
> 
> Regards,
> Tony
> 

-- 
---
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Tue, 2 Mar 2021 10:21:04 -0800

Hi Toerless,

> 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.

> interest, maybe working on them would ease the ability to operate multiple semantics,

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.

> 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!

> (alas, corona times are no fun for t-shirt junkies).

And it’s still more than is truly needed. ;-)

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Mar 2021 19:50:51 +0100

Hi Tony,

So spot on ...

And as a quite related data point - few folks thought maybe we could at
least define variable length SIDs and send only what operator needs for the
given SR network deployment. They even wrote this up:
https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-04

Well apparently big vendors decided that this is "bad idea" and no one is
willing to implement it.

Déjà vu ?

Thx,
Robert.

On Tue, Mar 2, 2021 at 7:21 PM Tony Li <[email-masked]> wrote:

> 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.
>
>
> 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.
>
>
> 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!
>
>
> 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
>
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

---

From: Dirk Trossen <[email-masked]>
Date: Wed, 3 Mar 2021 08:22:58 +0000

Tony,

Very well observed, while not agreeing on all points (see later). 

There seems a recurring pattern (roughly every ten years?) of discussing the continuation of the band aid model or thinking architecturally (which could lead to possible radical step sizes rather than small ones). The last recognizable discussion I can recall were the international efforts on Future Internet (NSF FIND, Europe's FI efforts, AsiaFI) with propositions like ICN and others coming from this, preceded by IPng before that. Questions on addressing and routing have always been central in those efforts. 

But it strikes me as odd when I hear about the evil of a flexible addressing structure, as you point out, while we see that we do this, effectively, in the many 'routing extensions based on some additional header information' solutions, i.e., the band aids - the separate draft at https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ discusses this. What we achieve are point solutions, which are all extending 'the semantics of routing' beyond the limited meaning of 'routing based on the IP address only', while opposing that the address structure itself should be extensible. In my view, the band aids show the desire to move beyond a narrow semantics of the Internet address, somewhat oddly aligned with the opposition to discuss more flexibility in addressing.

When you point at the pitchforks coming out when talking about this or even labeling this as 'fixing IPv6', there is a clear danger here. While I can understand and well appreciate the tussle between an engineering community that is chartered with finding 'actual' solutions with constraints like backward compatibility and preserving 'sunk costs' in existing HW, and those who cast aside those constraints to think about larger stepsizes in change, there is a challenge to preserve the right balance between those (often opposing) concerns. We may not want to end up sounding like discussions many decades ago when a 'young Internet' came around and proposed radical changes against all calls of preserving many decades of telecom investment. 

In order for the 'young child Internet' to remain young and fresh, there must be a stage where these discussions can be held. The IRTF is meant to be this place, which is where we saw this discussion could ultimately unfold - unfortunately, the draft was not accepted for the IRTF open meeting discussion at this upcoming IETF. But it cannot be a point discussion only, it should be a continuous discussion due to the central role that addressing and routing plays in the Internet - this is where I disagree with your assessment about the lacking wisdom (since we may miss on the right inputs to gain that very wisdom in this limited community). Instead, we should seek input not only from those being closer to SDOs (and the IRTF has a strong proximity to the IETF so is seen by many researchers as an SDO-type organization) but from those who really care about questioning constraints and limitations but may not be naturally drawn into the IRTF. Continuity of the discussion is key here, not recurring waves (every about 10 years).

Best,

Dirk

-----Original Message-----
From: routing-discussion [mailto:[email-masked]] On Behalf Of Tony Li
Sent: 02 March 2021 19:21
To: Toerless Eckert <[email-masked]>
Cc: King, Daniel <[email-masked]>; Adrian Farrel <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [External] Request for information - Challenges in routing related to semantic addressing

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.

> 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.

> 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 ?

> 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".

> 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.

Regards,
Tony

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 3 Mar 2021 10:00:48 +0000

> On 2 Mar 2021, at 18:21, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Toerless,
> 
> 

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Mar 2021 11:05:19 +0100

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.

Ideas are turned into code, being tested and deployed.

Best,
R.

On Wed, Mar 3, 2021 at 11:01 AM Stewart Bryant <[email-masked]>
wrote:

> should be subject to
> > 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.
> >
> >
> why then have we
> bits and grumble
> addresses, because we are a) not
> > 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
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 3 Mar 2021 10:31:07 +0000

> On 3 Mar 2021, at 10:05, Robert Raszuk <[email-masked]> 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

> On Wed, Mar 3, 2021 at 11:01 AM Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 2 Mar 2021, at 18:21, Tony Li <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > Hi Toerless,
> > 
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/routing-discussion <https://www.ietf.org/mailman/listinfo/routing-discussion>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 3 Mar 2021 13:39:51 +0100

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:
> > > 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.
> > > 
> > > 
> > > And it???s still more than is truly needed. ;-)
> > > 
> > > 

-- 
---
[email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 03 Mar 2021 12:46:09 +0000

i was impressed this paper nade it out of the USA last year:-
https://doi.org/10.1145/3387514.3405875

> > 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
> >
> >
> >
> > >
> > > On Wed, Mar 3, 2021 at 11:01 AM Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >
> > > > 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.
> > > >
> > > >
> such fundamenals of
> > > > 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.
> > > >
> > > >
> > > > 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!
> > > >
> > > >
> > > > 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.
> > > >
> > > 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
> > >
> > >
> > >
> <https://www.ietf.org/mailman/listinfo/routing-discussion>
> >
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 3 Mar 2021 21:20:27 +0000

-----Original Message-----
From: routing-discussion <[email-masked]> On Behalf Of Toerless Eckert

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

I don't know what the actual situation is in most countries. However, for essentially unmetered, cabled Internet access, in the US, it is mostly the case of only one "last mile" access ISP being available to a given household, two in many urban and suburban environments, and infrequently three. Which says to me, competition on the basis of "ATM-like class or quality of service" knobs, provided by your ISP, won't help much, unless everyone uses the same techniques?

Historically, what gave IP the edge over competing standards was, just throw cheaper bandwidth at the problem, available with IP's best effort model, and those tricky and expensive knobs become just an academic exercise. Are we saying that the situation has changed?

Bert

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 4 Mar 2021 11:24:44 +0000

> On 3 Mar 2021, at 21:20, Manfredi (US), Albert E <[email-masked]> wrote:
> 

There will be other last mile providers for a lot of people. 4G can provide acceptable bandwidth (in my case faster than FTTC), there will be 5G, Starlink is rolling out and there are others LEO offerings.

If DSL has to fight back it can offer enhanced services.

I have always thought that there might be a possibility of DSL offering service to multiple ISPs over the same path since all offerings are multipliable at the L2 they use. So you could have the FAANG group offer prioritised direct to the home in parallel with classic worst efforts service.

- Stewart

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 4 Mar 2021 23:10:44 +0100

Thanks, Albert

You touch on more than one point.

I was primarily pointing to a technical opportunity that evolves the more transit
becomes required on paths. That does not mean that the opportunity is picked up
by players.

IMHO, 5G/6G and WiFi will evolve as additional competitive access options the
more they get built out. Yes, some countries such as the USA so far have not created 
regulation for a more competitive market but allowed operators to be quite uncompetitive.
That is also why customers in those markets are being extorted
on pricing (just based on limited personal experience, not a scientific analysis ;-)

Figuring out how to make use-case deployments benefitting from network services
beyond BE is a complicated issue. Vertical integrated services have in the past been
prime drivers. Slicing/virtualized-programmable network may be future enablers.

Cheers
    Toerless

-- 
---
[email-masked]