Re: [arch-d] [Int-area] Continuing the addressing discussion: what is an address anyway?

[Toerless Eckert <[e-mail]>]

Dave,*:

On Wed, Jan 26, 2022 at 10:36:00AM -0500, David R. Oran wrote:
> I wade in here with more than a little trepidation, especially with my “ICN taint” where there are no classic “flows” and in fact no source addresses to apply semantics to, and only weak notions of destination addresses in the sense that content names at layer 3 may have a binding only to a single location in the network because that’s what you wanted when you constructed the name.
> 
> After reading the semantic routing docs, I am still befuddled about why one would want this capability in an underlay when it is already very common to employ a level of indirection by recursing at layer 3 to construct flexible overlays.

"why one would want this capability"  sounds like equally applicable to ICN then,
aka: why have any other semantic than "unicast/anycast" ? Given how i assume you
continue to believe in ICN, i think the very same answer could be given for
other semantics. 

I for once never thought that the "one semantic fits all" approach was very useful.
When ICN initially was pitched for content, it made a lot of sense to me. When
it was pitched to become the one-semantic-fits-all to replace unicast packet
forwarding (IP), i felt this was again one of those theoretical attempts to replace
something quite well suited to the task (IP unicsat) with something more complex
as opposed to figure out what a beneficial and necessary set of semantics in the
network are that you want to build concurrently.

When we started to have DoS attacks over the Internet in the 90th/2000th because of
address spoofing or other undesired traffic, i always joked that one could
easily get rid of IP unicast in the Internet and just use IP Multicast/SSM,
just with a single receiver. Given how that is join based from the receiver,
there would never be these IP unicast attack vectors. So obviously much better ;-).
But of course, joking because of the much higher underlying forwarding/state
complexity.  ICN on the other hand didn't seem to be just joking.

> One might want semantics other than an attachment point in an overlay, but we already have that, and can similarly recurse existing routing protocols to construct the desired topologies. So, I’m in the uncomfortable position of not seeing the need for any of this either as a native IP capability, nor going forward as an alternative to architectures like ICN which natively provide flexible semantics through the use of hierarchical or attribute-based names at L3.

If you go to IEEE 802.1, then IP is an overlay. So it just depends
on where you're coming from. Of course, application developers will
build multi-hop forwarding logic nowadays most likely on URLs, as
we also see in IoT (MQTT andd any othrer type of buses / forwarding
meshes). 

Designing semantics at "L3" i think is a great compromise between
eliminating link-player specifics and avoiding creating dependencies
against application specific. Aka: best / broadest reuseability
(including software...high-speed hardware implementations) and 
applicability.

Of course, you can build one new L3 semantic as an overlay on a
different semantic L3, and that should by now be a day 1 consideration
for any new semantic - as opposed to ICN where AFAIK it came way to
late in the game, even though we already learned the native vs.
overlay lesson from IP multicast in the 90th - and started to
re-build overlay components (AMT) as early as 2001.

Building L3 solutions that with as little as possible effort
allow themselves to be deployed hybrid overlay vs native is still
IHMO a broadly unresolved issue. Everybody faced with on instance
to build out comes up with their own cut between automation and
nerd-knobs.

But in the end, the overlay vs. native issues is IMHO orthogonal
to the definition of appropriate/useful semantics.
> 
> If the goal is to try to decouple the IPv6 packet format from conventional notions of forwarding and routing, given the movement toward user-programmable switches and routers, we can do that without introducing the notion of semantic routing. As a extreme endpoint of this argument, consider the following:
> 
> - Programmable switches can do match operations on any set of contiguous bit fields in a packet if they are in the first 256 bytes of the incoming buffer.
> - The extracted and matched bit fields can be used as input to a lookup table, or a cascaded sequence of lookup tables, or even something with FSM computation as long as the cycle count and memory accesses are highly limited.

It would be great if we could drive these considerations into some type
of guideline RFCs that defines what is and what is beyond reasonable
expectations of what todays forwarding planes are supposed to be able to
do. For example i think we still do have differences of opinions between
vendors whether or not a particular sized chain of TLV is or is not
feasible (assuming they are in the first 256 bye). Applicable to the
question of IPv6 extension header chains or actual parameter TLV inside
an extension header.

I for once would love if we had something like an IETF forwarding plane
reference pseudocode machinery embodying the capabilities and limitations,
such that one would simply need to write the desired forwarding code
in that machine spec to avoid the ongoing bickering we otherwise have
about what type of forwarding plane extension is or is not apropriate.

> Given this, there is no need, other than for standards compatibility, to assign any fixed semantics to ANY of the fields in an IPv6 packet, be they the “addresses”, the hop limit, ports, or anything else. In fact it may be that the **only** thing about the overall packet structure that demands precise standardization is how you demultiplex incoming frames/packets to the program that is assigned to handle them. Then if you don’t want to have source addresses and want to treat the concatenation of SA/DA (in any order or even segmented in pieces) as one single key to the forwarding operation, that’s just fine.

It certainly would help if every "user" who wants a new/improved
semantic could easily get that as a programmable slice hop-by-hop
onto a programmable switch network such as a metropolitan size
SP network. I think there are a couple of more issues than what
you describe though:

1. the actual actions you can drive from the parsed packet header,
  e.g.: QoS via programmable PIFO, EIFO or the like

2. The problem of high-speed forwarding cost effectiveness.
  For this one, i think as much as possible standardization
  of packet headers help (similar to evolving from VM to containers).
  Aka: someones new semantic header would clone&extend/modify a common
  header, so each slice program only needs deltas, and over time
  more broadly used deltas would be merged.

> In this “endgame”, both routing and forwarding is simply defined by the program (or programs) you load in the devices. There’s no need to have conventional “protocol standards” beyond agreement among packet generators and packet parsers as to what the format of the packet is. IPv6 is just fine for this - there are enough bits to do a lot of stuff, even ICNish stuff as we’ve seen with the hICN effort (https://datatracker.ietf.org/doc/draft-muscariello-intarea-hicn/)

Well, the IPv6 base header with 2 * 128 bit addresses and 8 bit QoS
is a kind of painful red herring. I just remember 2? painfull
years when we (then Cisco) tried to figure out how to make use
of those bits for BIER so as to not see them go to waste. 

> I don’t intend this as a flame; I’m seriously skeptical of the utility of using protocol standards as a way to achieve different routing functionality given where the technology is today and where it’s moving.

I just think your thinking is more programming bottoms up, as
has been mine. The semantic view is a bit more top down. Both
are required IMHO, and the interesting place is where those meet.

Cheers
    Toerless

> DaveO.
> 
> On 26 Jan 2022, at 1:24, Eliot Lear wrote:
> 
> > [copy architecture-discuss]
> >
> > Geoff,
> >
> > This is a pretty good characterization.  In fact, it's exactly where we went in the NSRG nearly 20 years ago, just after MO first kicked out 8+8.  For people's reference, we looked at naming at different levels, including at L3, in DNS, URNs (which were relatively new things then), HIP, etc.  There were then several efforts in both the IRTF and IETF to deal with portability of connectivity in transport.  I think QUIC gets a lot of that right.  QUIC – at least at the moment – as some limitations for local use (either you have certs or some sort of prearranged bidirectional authentication).  I think it's a fair engineering assumption that those will be kinked out.
> >
> > With all of that having been said, I go back to Dirk's note: what properties do we need at L3?
> >
> >  * If QoS is still a thing, then admission control has to be part of
> >    the story.
> >  * There is a tussle between endpoint privacy and the endpoint itself
> >    being a threat.  In the latter case, the endpoint has to be
> >    identified.  But to whom?
> >
> > As you describe, a lot of routing has moved up a layer.  Sort of.  But not all.  CDNs need to be well aware of topology, and that comes from L3, perhaps with additional OOB info.
> >
> > So... what's missing from L3 at this point that we need, and is it even a good question to ask?  I ask that because I have seen recently a retrenching AWAY from IPv6.  If that is happening, what makes us think that any new L3 beyond IPv6 would ever get adopted?  OR... what is missing from IPv6 that would cause people to move?
> >
> > Eliot
> >
> > On 25.01.22 12:38, Geoff Huston wrote:
> >>
> >>> On 25 Jan 2022, at 6:19 pm, Dirk Trossen<dirk.trossen=[e-mail]>  wrote:
> >>>
> >>> All,
> >>>  Thanks for the great discussion, following our side meeting at IETF 112, so far.
> >>>  I wanted to turn the discussion to a key question which not only arose in the side meeting already but also in the discussions since, namely “what is an address anyway?”.
> >>>
> >> In this world of NATs it seems that we treat addresses as no more than temporary ephemeral session tokens and we've passed all the heavy lifting of service identification over to the name system. These days you and I could be accessing the same service yet we could b e using entirely different addresses to do so. Or I could be accessing the same service at different times, and again be using different addresses each time. I find it somewhat ironic that we see increasing moves to pull in IP addresses as part of the set of personal information in some regulatory regimes, yet what the larger network sees of end clients is a temporary NAT binding to a public address that may be shared by hundreds if not thousands of others.
> >>
> >> And IPv6’s use of privacy addressing achieves a similar outcome in a different way. And QUIC’s use of the session token inside the encrypted envelope even makes the binding of an address to a single session fluid, as the same QUIC session can be address agile on the client side.
> >>
> >> So perhaps an address these days is just an ephemeral transport token and really has little more in the way of semantic intent.
> >>
> >> Geoff
> >>
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/int-area
> >>
> 
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> DaveO



> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss


-- 
---
[e-mail]