Re: [amqp] Addressing Model Blog Post

[Rob Godfrey <rgodfrey@redhat.com>]

On Thu, 8 Nov 2018 at 20:20, Alan Conway <aconway@redhat.com> wrote:

On Thu, Nov 8, 2018 at 12:14 PM Clemens Vasters <clemensv@microsoft.com> wrote:

Â

I want to make a car on the road addressable (that is conceptually the target container) and then use the node structure to allow for addressing different aspects of that car. The car is roaming across a wild mix of 3G/4G/5G networks including international roaming and never has a stable IP address. So Iâll give the car a rendezvous point in its general proximity that acts as a proxy and from where it can pick up messages (that is the container that actually gets routed to) as the car gets back on the network, and that rendezvous point may shift.

Â

When I want to send messages to that car, I connect to the edge of the car overlay network, find a path to whatever the right target container is (how that happens is indeed out of scope) and then direct messages to the nodes in that container. ÂÂ

Â

I need a name for the onramp, a name for the car whereby itâs obscured whether thatâs the actual car or just a container acting as an intermediary for it, and a name for the map service in the car.

+1 - you need a hierarchical name that includes all those parts. But you don't (IMO) need to syntactically differentiate what the different parts of the name refer to - let the routers do that at runtime.

That allows your proposal of //(scope)/foo/bar but doesn't mandate it. That way you don't have to decide between //(ford.car)/steering and //(car)/ford/steering up front, you can use //car/ford/steering consistently and configure the network to deliver based on how things are deployed.

So to me the issue is in the case of messaging between two different domains, where the precise details of routing within the domain should not be exposed across the domain boundary (and thus also not impact routing externally if the internal rules are changed).ÂÂ

Within a single organisation or a single centrally controlled messaging network it is fine to have knowledge of the topology / routing be distributed to many routers. Where we a talking about being able to send messages across organisational boundaries this would not be appropriate. As such I would expect that within the domain "foo" you can set up any routing scheme you like, and distribute the knowledge about that scheme amongst your routers... but for someone from bar sending a message to foo/address1 via the onramp amqps://messaging.bar then the amqp endpoint as messaging.bar can not be required to parse beyond foo/ to know the next step.

I believe we need a way to identify the "domain" (or scope) and the domains must be uniquely identifiable (thus we need to appeal to some naming authority). Ideally one should be able establish trust that a particular intermediary "speaks" for a given domain using some sort of PKI infrastructure. I don't really care if the address syntax is //<domain>/path or /(<domain>)/path, that is a fairly uninteresting syntax decision (I think the (<domain>) variant may lead to an easier implementations within large domains (i.e. large organisations). ÂIn a global (or multi-organisational) heterogeneous messaging network I do believe that we need a way of differentiating the "global" part (the domain) from the "internal" part.

-- Rob

Â

Â

Â

Â

Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 18:01
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post

Â

Â

On Thu, Nov 8, 2018 at 11:32 AM Clemens Vasters <clemensv@microsoft.com> wrote:

We canât just use the path because we really have three addressing realms:

• IP network space
• Inter-Container overlay network
• Intra-Container node space

Â

I don't think we do have 3 addressable realms - the structure of the inter-container network should not appear in user addresses.

Â

Consider the IP analogy: I can connect to an IP address x, may packets carry only the address x. My packets pass through many IP routers, which have their own IP addresses, but I know *nothing* about them, in fact they may change during the course of a single connection. It's up to the routers to decide "who's next" for a given address, it's not up to me to choose the route in my IP address.

Â

Of course if your implementation wants to start every path with"(scope)" I've got no problem with that, but I don'tÂthink we need to force that convention on everyone. For example, dispatch router is configured with routing rules that match arbitrary path prefixes and patterns, there's no need for special syntax.

Â

Â

The node space (the path) is something we canât futz with for backcompat reasons if nothing else.

Â

Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 17:29
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post

Â

Â

On Thu, Nov 8, 2018 at 10:56 AM Clemens Vasters <clemensv@microsoft.com> wrote:

While the authority does not have to have a DNS mapping, thatâs the general assumption.

Â

If you want reach a place on an overlay network, you first need to be able to connect the edge of that overlay network and then route within that overlay network. Those are two address spaces.Â

The goal of the URI construct is to be able to express both the edge address and address inside the overlay network in one address. If you just want the overlay network address, you use amqp:(scope)/foo

Â

OK I buy that, butÂI'm starting to feel that inventing something we can't name is a Hint from the Universe.Â

The URI framework already has a way to specify hierarchical scopes that are not part of the authority - the path.

Â

Why is "amqp://foo.net/(a.b)/c/d" preferable to "amqp://foo.net/a/b/c/d? The former does not provide any information that clients can use, it is harder to construct/parse and it seems to imply knowledge of the internal routing of messages that clients really should not have. If (scope) is not an authority, a host name, or a container ID, then it is simply part of a hierarchical string to be interpreted by AMQP entities, it has no special meaning that deserves special syntax. If you restructure your application something that was (a.b)/c might end up more like (a)/b/c or (a.b.c) - better to expose an unchanging "a/b/c" to clients.

Â

Â

Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, 8. November 2018 16:51
An: Clemens Vasters <clemensv@microsoft.com>
Cc: Rob Godfrey <rgodfrey@redhat.com>; oasis-amqp-list <amqp@lists.oasis-open.org>
Betreff: Re: [amqp] Addressing Model Blog Post

Â

I feel that the distinction between domain name and scope identifier is a hack. Why not follow internet tradition and make an AMQP address is a classic URI

Â

  Â[amqp:][//authority][/path][?query]

Â

The authority (aka host) *is* the scope identifier. In an AMQP context (link or message to:/reply-to: address) we mandate dropping the redundant amqp[s]: prefix, which is pretty close to the last addressing draft I read.

Â

Introducing a new scope-id adds some flexibility, but also more complexity. Re-using the URI authority (aka DNS domain name, aka virtual host name) means we can re-use a lot more existing DNS, virtual host and URL technology that is already mature and well understood.

Â

A URI authority does not *have* to have a DNS IP mapping. If it does it is a connectable URL, if not it can still be used by apps that have a pre-existing connection to an AMQP router. Whether connectable or not, it can be used for AMQP-smart routing just like a separate scope-id could be. Virtual host names can be associated many-to-many with IP addresses, and once messages hit an AMQP router they can further be associated many-to-many with AMQP containers, on the same or different IP hosts. HTTP already does this.

Â

To bootstrap an application with amqp://myhost.net/foo, the client connects to myhost.net and links to //myhost.net/foo for possible further routing, or to the relative address /foo if it is a direct connection to the final container (many existing AMQP apps will do this) For a non-connectable //myscope.net/foo, the client needs a pre-existing connection but the routing information is the same.

Â

I can't imagine any routing scenario where you don't have virtual host names to map your AMQP scope-ids flexibly to the proper IP "on-ramps". Also re-use of virtual host plays well with existing router apps (like Qpid Dispatch) which already use virtual host to effectively "fill in" missing scope/authority from "relative" addresses used by existing clients. In fact using a combination of AMQPÂ URI authority and virtual host (if different) gives essentially your amqp://vhost/(authority)/ but without the awkward 2-stage UIR.

Â

On Thu, Nov 8, 2018 at 1:15 AM Clemens Vasters <clemensv@microsoft.com> wrote:

This morning I donât like âareaâ anymore, either. Scope is good.Â

Â

(Oh how I hate naming things)

Â

---

Von: Alan Conway <aconway@redhat.com>
Gesendet: Donnerstag, November 8, 2018 12:36 AM
An: Clemens Vasters
Cc: Rob Godfrey; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post

Â

Â

On Wed, Nov 7, 2018 at 6:59 AM Clemens Vasters <clemensv@microsoft.com> wrote:

AMQP nodes and containers are introduced in the core AMQP specification. This specification introduces a further concept: areas.

An area identifier is a string that follows DNS naming conventions. Area expressions are matching conditions that can be evaluated against area identifiers for routing or filtering.

Area identifiers are used for routing messages or links across AMQP container boundaries, potentially with one or more containers acting as routing intermediaries. Instead of having to handle container-ids for all potential routing targets, routing intermediaries can evaluate area expressions to determine which container to direct the message to.

An area identifier is a structured name that represents a logical routing target or source scope. The term area reflects that the addressed scope has further internal structure in form of nodes, and therefore an area never identifies a singular, specific target or source.

While area identifiers follow DNS naming conventions, but they do not have to be registered in DNS and they donât have an associated IP address. They are just names describing logical scopes in a system, and the DNS-like structure helps expressing hierarchical relationships, structuring routing scopes from very broad to more scoped areas.

While the identifier of a container MUST be unique and stable within an AMQP network, areas are more flexible. A container MAY have any number of associated area aliases. Reversely, an area alias MAY be associated with several containers.

Â

Â

How about "scope identifier"? "area" doesn't really give me the idea of a namespace or name domain, and you used "scope" 5 times while explaining what "area" means.

--

_____________________________________________________________________________

Red Hat GmbH,Âwww.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill