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

["David R. Oran" <[e-mail]>]

Forwarding as suggested by COINRG chair.
Probably best to respond on arch-d if you have comments to avoid 
parallel non-intersecting email threads.

DaveO

Forwarded message:

> From: Marie-Jose Montpetit <[e-mail]>
> To: David R. Oran <[e-mail]>
> Subject: Re: [arch-d] [Int-area] Continuing the addressing discussion: 
> what is an address anyway?
> Date: Wed, 26 Jan 2022 10:43:43 -0500
>
> You should send this to COIN where as you know Adrian is pushing 
> semantic
> routing.
>
> Marie-José Montpetit, Ph.D.
> [e-mail]
>
>
>
> From: David R. Oran <[e-mail]> <[e-mail]>
> Reply: David R. Oran <[e-mail]> <[e-mail]>
> Date: January 26, 2022 at 10:37:00 AM
> To: [e-mail] <[e-mail]>
> <[e-mail]>
> Subject:  Re: [arch-d] [Int-area] Continuing the addressing 
> discussion:
> what is an address anyway?
>
> 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. 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 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.
>
> 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.
>
> 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/)
>
> 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.
>
> 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]>
> <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
> [e-mail]://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