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

From: Geoff Huston <[email-masked]>
Date: Fri, 2 Apr 2021 07:03:14 +1100

> On 15 Feb 2021, at 9:40 pm, King, Daniel <[email-masked]> wrote:
> 
> Hi AB, 
>  
> Thanks for scanning and commenting.                                                                                   
>  
> The I-D has bubbled for a while after seeing various discussions on contextual and semantic routing I-Ds, mostly clean-slate approaches. Although the initial literature review highlighted some common objectives across proposals and implementations, I struggled to find anything that defined "semantic routing" and goals that we could use/reference. I likely missed prior research that provides a useful definition. If not, then I agree that having the IRTF research community document a description for "semantic routing" and common goals, would be beneficial.
>  
> BR, Dan. 
>  

I take it you are referring to an approach being used in one of the largest IPv6 deployments: https://meetings.ripe.net/see3/files/Ian_Farrer-The_Terastream_Native_IPv6_Network_Architecture.pdf - Slides 15-17. If so, then I’d suggest this has already headed well beyond research into operational deployment!

regards,

   Geoff

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 2 Apr 2021 10:15:02 +0200

Geoff, 

> On 1 Apr 2021, at 22:03, Geoff Huston <[email-masked]> wrote:
> 
> 
> 

Are you saying that the operator can give whatever semantic they wish to their addresses? We do not care?

Even so, isn’t Terastream just a specific solution for a specific use case? 

There is much more to be explored and discussed IMHO.

L.

> regards,
> 
>   Geoff
> 
> 
> 
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Apr 2021 12:08:23 +0200

Luigi,

> their addresses? We do not care?

That shipped has already left the harbour ... about 30 years ago. The
moment policy routing was introduced which allowed match on IP address or
recently its portion means that operator can apply whatever semantics to
the addresses as it seems to fit his needs.

The gap between router itself applying such semantics vs need to
explicitly configure it is IMO irrelevant.. Modern OS have so much
flexibility in defining packet processing pipelines that spending time on
what network elements can or can not (should or should not) be doing is
frankly a waste of time :)

Cheers,
R.

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Apr 2021 07:28:41 +1100

> On 2 Apr 2021, at 7:15 pm, Luigi Iannone <[email-masked]> wrote:
> 
> Geoff, 
> 

well yes. For almost every value of “we”. As I recall, the motivating observation for these folk was that it was faster to place policies in a place that was processed by the router’s packet forwarding logic than it was to place these policies in a router’s filter list processing logic.

> Even so, isn’t Terastream just a specific solution for a specific use case? 

I dunno. The argument about preferring faster and cheaper tends to more than an isolated case.

> There is much more to be explored and discussed IMHO.

That may be true, but my point was that this is not a matter “in the abstract” and one that is already in use. I was pointing out that there is one large network infrastructure operator has openly talked about the use of address structure in a way that this thread calls “semantic” addressing. There may be other similar use cases. Similarly, I'm aware of some (many?) ways to use the 64 bit interface identifier, some of which embed one-off tokens in the field in an extreme case of privacy addressing.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 3 Apr 2021 07:29:38 +1100

> On 2 Apr 2021, at 9:08 pm, Robert Raszuk <[email-masked]> wrote:
> 
> Luigi,
>  
> That shipped has already left the harbour ... about 30 years ago. The moment policy routing was introduced which allowed match on IP address or recently its portion means that operator can apply whatever semantics to the addresses as it seems to fit his needs. 
> 
> The gap between router itself applying such semantics vs need to explicitly configure it is IMO irrelevant.. Modern OS have so much flexibility in defining packet processing pipelines that spending time on what network elements can or can not (should or should not) be doing is frankly a waste of time :) 
> 
> Cheers,
> R.
> 
>  

I agree with Robert - that ship left the harbour decades ago!

Geoff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 2 Apr 2021 22:47:51 +0200

>
> Similarly, I'm aware of some (many?) ways to use the 64 bit interface
> identifier, some of which embed one-off tokens in the field in an extreme
> case of privacy addressing.

Indeed and I am also aware of such use cases.

See I am actually not sure what this discussion is all about :)  Orthodox
v6-ers claim that you only can assign IPv6 addresses to the interfaces. And
frankly this is ok. Except since early moments router's interfaces were
both physical and logical. And in the latter case logical interface is
nothing else then instantiation of some semantics. It can be simple
loopback, it can be virtual tunnel termination, it can be dial-up, it also
can be service chain anchor. In modern slide decks it is called SR
endpoint.

So last 64 bits give you great place to express to the destination which
attracts traffic to such address on how you want this packet to be handled.

Such indication can be implicit or explicit - I think some people do not
like to see it explicit. But honestly it should be in best interest of the
IETF to make it as explicit as folks want to disclose it for better
interoperability across vendors, wider adoption, solicitation of more
comments etc ... .

Happy Easter Holidays to all,
Robert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 2 Apr 2021 16:54:00 -0400

In my experience, there is a significant difference between what an 
operator chooses to do in their network and what it makes sense to 
discuss in a a standards body.

To use a different example, the IETF considered changing the IPv4 
recommendations to allow for the use of class E addresses.  for a number 
of good reasons, we decided not to do that.  I am told that at lest one 
operator who rolls their own stuff sufficiently has chosen to use class 
E inside their network.  they are clearly free to do that.  We are not 
the protocol police.  But that does not mean we should standardize it 
either.

I believe something very similar can be said of Terastream.

Yours,
Joel

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 6 Apr 2021 10:05:55 +0200

> On 2 Apr 2021, at 22:29, Geoff Huston <[email-masked]> wrote:
> 
> 
> 

That is fine… it means that is time to look for another ship ;-)

On a more serious tone….  The fact that one problem has solved (or ignored) decades ago does not represent an argument not to revisit the very same problem trying to find a better solution now.

We should not underestimate our capacity to innovate ;-)

L.

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 6 Apr 2021 10:11:21 +0200

> On 2 Apr 2021, at 22:54, Joel M. Halpern <[email-masked]> wrote:
> 
> In my experience, there is a significant difference between what an operator chooses to do in their network and what it makes sense to discuss in a a standards body.
> 
> To use a different example, the IETF considered changing the IPv4 recommendations to allow for the use of class E addresses.  for a number of good reasons, we decided not to do that.  I am told that at lest one operator who rolls their own stuff sufficiently has chosen to use class E inside their network.  they are clearly free to do that.  We are not the protocol police.  But that does not mean we should standardize it either.

Agreed.

I do not think that is the intent.

I think it is more about discussing routing/addressing and the challenges of the next decades  

It is worth discuss it

Ciao

L.