Apologies, the below should read " then the question arises how much of an ephemeral nature we see in the relations between a client and an egress ", of course.
-----Original Message----- From: Dirk Trossen Sent: 26 January 2022 10:21 To: 'Geoff Huston' <g...@apnic.net>; Stewart Bryant <stewart.bry...@gmail.com> Cc: int-area@ietf.org; architecture-disc...@ietf.org Subject: RE: [Int-area] Continuing the addressing discussion: what is an address anyway? Geoff, Stewart, all, Linking in the arch-d list, following Eliot's intention to widen the audience for input. Let me come back to your statement "My point is that the semantic construct of an “address” does not limit or predetermine which of these models your network must use, nor does a network’s choice of switching architecture necessarily redefine the semantics of an IP address.", also relating to ephemeral nature you outlined in your original post. Key to me is at which level of the system the ephemeral nature you identified exists, which may help us teasing apart the different 'scopes' of what an address may be. If I follow your alternative perspective below that "a packet's IP address is a token that helps the network determine which egress interface is to be used for the packet to be kicked out of the network ", then the question arises how much of an ephemeral nature we see in the relations between a client and an ingress. If most traffic goes to your closest CDN, you pretty much have a stable relation, while the ephemeral nature is purely one between the client and DC-internal service endpoints; QUIC's sessionIDs aim at that aspect, enabling transport-level connectivity changes (within the DC, e.g., for load balancing or resilience reasons). The work in SIGCOMM2021 on "The Ties that un-Bind: Decoupling IP from web services and sockets for robust addressing agility at CDN-scale" (https://conferences.sigcomm.org/sigcomm/2021/files/papers/3452296.3472922.pdf) build on this observation, leading to the radical notion that a single IP address may enough "to rule them all" (the web services). But what if there is an ephemeral relationship nature in the network itself? What if my intended communication partner may not be bound to a single location, even distributed as possible destinations over many? We have models like anycast that describe a relationship with a stable identifier, resulting in a possible ephemeral relationship with a choice of network location associated with that anycast address. But is that relationship ephemeral during a transaction or across several; I'd argue that the former is handled with approaches in QUIC? If it's the latter, do I agree on the resulting semantic, often found in anycast mapping, that it remains stable even across transactions? This brings me to Stewart's statement regarding "Thus in my mind the address field in a packet is an opaque instruction that is looked up in some large table and causes the forwarder to take some set of actions that are referenced by the table." and the nature of that lookup and action. It poses questions on how stable the table content is (i.e. how frequently will routing impact the result of my lookup for a given address, but also what is the result of that routing anyway?). Also, how simple is the lookup: 1. Is it a one-to-one mapping, leading to unicast choices? 2. Is it a one-to-many choice? 3. Is it a one-out-of-many-possible choice, which covers the anycast choice above? This third choice has a raft of questions that also link the scope of the network choice with the semantic of the overall relationship the client may want to establish. In other words, is the choice in item 3 determined via routing, falling back to option 1 as a result of delivery, or is it random over all choices possible or using some other scheduling mechanism (e.g., RR, weighted RR)? How do I deal with affinity across packets if there is indeed a dynamic ephemeral nature? How do I deal with choices being made that may differ based on semantic meaning outside of the 'network location' choice, i.e., what if choosing a location depends on the service I'm invoking? The choices, most likely, are accompanied by metadata enabling them. Do they form part of the address or are they just that, metadata? Depending on the choice of metadata, it changes the nature of the address in the sense of how packet delivery is done and therefore how a network node "addresses" the possible destinations. Best, Dirk -----Original Message----- From: Geoff Huston [mailto:g...@apnic.net] Sent: 25 January 2022 20:42 To: Stewart Bryant <stewart.bry...@gmail.com> Cc: int-area@ietf.org; Dirk Trossen <dirk.tros...@huawei.com> Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway? > On 26 Jan 2022, at 5:47 am, Stewart Bryant <stewart.bry...@gmail.com> wrote: > > There is both a topological view of an address and a protocol view. > > The topological view is some place in the network, be that a node or an > interface. > > The protocol view is that it is an instruction, for example to deliver the > packet to the place identified by the address field lookup. In IP this was > originally an interface somewhere in the network. In MPLS we generalised and > abstracted this to make the label an instruction what sometimes said deliver > the packet closer to some network object, but sometimes was an instruction to > do something else. > > In SRv6 they designed a hybrid of this with the prefix having the original IP > meaning, and the suffix providing some other instruction together with some > parameter such as send the packet to this VPN. > > Thus in my mind the address field in a packet is an opaque instruction that > is looked up in some large table and causes the forwarder to take some set of > actions that are referenced by the table. > Stewart, There is an alternative view here that inverts this perspective. From the perspective of the network, a packet's IP address is a token that helps the network determine which egress interface is to be used for the packet to be kicked out of the network! MPLS, next hops addresses, encapsulation, virtual circuits are all somewhat isomorphic from such a perspective. The differences lies in the amount of work the network performs on acceptance of the packet. In some models it performs an initial lookup to select the egress point and then uses this initially computed egress tag to guide the packet’s journey through this network (MPLS, virtual circuits, encap). Other models, including hop-by-hop destination based stateless forwarding, perform this same egress point computation at every internal switching point. My point is that the semantic construct of an “address” does not limit or predetermine which of these models your network must use, nor does a network’s choice of switching architecture necessarily redefine the semantics of an IP address. Geoff _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
