Re: [amqp] Global addressing model - brain dump

[Alan Conway <aconway@redhat.com>]

Of the options presented I like @container and (container), I don't like any of the others.

I lean towards (container). It is less likely to confuse or clash, and semantically it suggests "containment".

The conventional use ofÂ@ is "something@somewhere", so "@somewhere/something" looks a bit weird to me, but I can live with it.

Either way we need an escape syntax for existing paths:

For () I'd suggest "/((foo)/x" to mean address="/(foo)/x", no container is implied

For @ I'd suggest "/@@foo/x".

Note that means container names can't start with the reserved character, but I think legacy container names is less of a problem than legacy addresses.

On Wed, Sep 19, 2018 at 2:47 AM Clemens Vasters <clemensv@microsoft.com> wrote:

Forgot one key point thatâs not as immediately related to present conflicts:

Â

An implementation may have good reason for wanting to use @ and other delimiters inside the container _expression_, which really is a logical routing criterion and might be structured. For instance, if I may want to route a notification event to amqp:(clemensv@microsoft)/notifications and that might resolve to all containers at Microsoft associated with me.

Â

Von: amqp@lists.oasis-open.org <amqp@lists.oasis-open.org> Im Auftrag von Clemens Vasters
Gesendet: Mittwoch, 19. September 2018 08:20
An: Justin Ross <jross@redhat.com>; Conway, Alan <aconway@redhat.com>
Cc: amqp@lists.oasis-open.org
Betreff: AW: [amqp] Global addressing model - brain dump

Â

Thank you, Justin and Alan.

Â

Justin:

Â

I had considered the notation variants you enumerate, and a few more, before I landed on the parens.

Â

The reason why I didnât use @ or [] was that theyâre both used in the network-address section (user segment and IPv6), which may be a source of confusion/errors for folks who look at a container-addressing URI without knowing the spec well and then confidently conclude that the // must be missing. The parens notation for container addressing Âamqp:(ctr)/node seems very clearly distinct.

Â

The other reason for not using a simple prefix like @ or ! was for there to be a seemingly greater risk that existing AMQP products may use simple prefixes like these (in addition to the precedent $) for their own special magic names or even allow them for user-named entities. The parens break the prefix pattern and â(queue)â seems slightly too weird to use/allow as an entity name.

Â

Since the amqp URI format from the early drafts is in active use, limiting the amount of breakage we cause with a final spec is something I think we need to care about.

Â

I would indeed like/prefer @ if we could convince ourselves that the concerns above are nothing to worry about.

Â

Clemens

Â

Von: amqp@lists.oasis-open.org <amqp@lists.oasis-open.org> Im Auftrag von Justin Ross
Gesendet: Mittwoch, 19. September 2018 03:45
An: Conway, Alan <aconway@redhat.com>
Cc: Clemens Vasters <clemensv@microsoft.com>; amqp@lists.oasis-open.org
Betreff: Re: [amqp] Global addressing model - brain dump

Â

I had a similar impression - it looks good. It works to existing conventions well, and it opens an avenue for container-based routing.

Â

What are the options we can consider for the notation? The parens sort of work for me, but I'd like to consider a larger set of candidates first.

Â

{ amqp | amqps } : [ //user:key@ip-endpoint/ ] [ @container-name ] [ [$] node-path ]

Â

amqp:@foo/news/eu

amqp://example.net/@foo/news/eu

Â

{ amqp | amqps } : [ //user:key@ip-endpoint/ ] [ \[container-name\] ] [ [$] node-path ]

Â

amqp:[foo]/news/eu

amqp://example.net/[foo]/news/eu

Â

{ amqp | amqps } : [ //user:key@ip-endpoint/ ] [ !container-name ] [ [$] node-path ]

Â

amqp:!foo/news/eu

amqp://example.net/!foo/news/eu

Â

Looking at it now, I have a slight preference for theÂ@ notation, as long as it doesn't collide with other stuff. RFC 3986 seems to allow for it.

Â

Â

Â

On Tue, Sep 18, 2018 at 6:14 PM Alan Conway <aconway@redhat.com> wrote:

This looks pretty sane to me. At first I found it odd to see container in the address but Qpid Dispatch router has a similar concept. It uses "magic" address prefixes to included router-ids in an address so e.g. amqp://host:port/$management is the management interface of the directly connected router, but amqp:/_topo/0/foo/$management lets you manage the router with id=foo. Using the standard container-id concept makes sense here - so in your scheme it would be

amqp://host:port/(foo)/$management. Equating router-id and container-id seems like a sensible notion.

Â

On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters <clemensv@microsoft.com> wrote:

For the Management spec I also need the Addressing spec to make progress, so Iâm now taking a fresh look at this.

Â

From the F2Fs I recall that our biggest holdup was that weâve got tension between several distinct goals for addressing expressions:

a.ÂÂÂÂÂ An address _expression_ should enable a âclientâ to find a âserverâ on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target.

b.ÂÂÂÂÂ An address _expression_ should enable a âsenderâ to have messages routed to a âreceiverâ inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the âreceiverâ address is a logical construct that doesnât contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of:

a.ÂÂÂÂÂ resolving the logical address to container name/location OR

b.ÂÂÂÂÂ evaluating routing rules based on filter expressions that indirectly yield a container location

c.ÂÂÂÂÂÂ An address _expression_ should enable a âsenderâ to route messages to a âreceiverâ inside a singular AMQP container, where address expressions correspond directly to node names inside of said container.

Â

We also have amqp/amqps URIs being used in the wild based on the current draft and I donât want to break those.

Â

Hereâs a proposal for an extended URI format that aims to hit all the goals at once:

Â

{ amqp | amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [$] node-path ]

Â

Iâll start the explanation with examples, because theyâll probably tell a whole lot of the story already:

ÂÂÂÂÂÂÂÂ amqps://broker.example.com/queue1 â DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the âqueue1â AMQP node

ÂÂÂÂÂÂÂÂ amqp:(london-branch-34)/atm â Logical AMQP network address of âlondon-branch-34â with path for the âatmâ AMQP node

ÂÂÂÂÂÂÂÂ amqps://megabank.example.com/(london-branch-34)/atm â DNS qualified address of a âgatewayâ into an AMQP network, with logical AMQP network address as suffix

ÂÂÂÂÂÂÂÂ amqp:()/control â Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the âcontrolâ node on the resulting container

ÂÂÂÂÂÂÂÂ somewhere â Local container address of the âsomethingâ AMQP node

ÂÂÂÂÂÂÂÂ $somewhere â AMQP reserved local container address

Â

To start, Iâm splitting up the AMQP notion of container into two distinct concepts: âgatewayâ and âcontainerâ.

ÂÂÂÂÂÂÂÂ A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks.

ÂÂÂÂÂÂÂÂ A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers.

ÂÂÂÂÂÂÂÂ Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container.

ÂÂÂÂÂÂÂÂ Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway.

Â

With the URI format, I am proposing a three-layer addressing model:

ÂÂÂÂÂÂÂÂ With DNS/IP addressing in the ip-endpoint section, you pick an AMQP endpoint as gateway into an AMQP network.

ÂÂÂÂÂÂÂÂ With container-name, you pick the AMQP container you want to communicate with via the chosen gateway. If omitted, the container is thought to be directly associated with âthisâ gateway (like today). If the container-name _expression_ is present but empty, itâs up to the gateway rules/configuration to determine the destination container based on the message/link properties or other criteria.

ÂÂÂÂÂÂÂÂ With node-path, you Âpick the AMQP node you want to route/link to inside the chosen/resolved container.

Â

Â

With a message addressed to amqps://megabank.example.com/(london-branch-34)/atm, a client first resolves the DNS name and IP address to some AMQP gateway instance via DNS and/or a load balancer, connects, and establishes a session â or reuses an existing session to that gateway.

Â

Then, the client will either attempt to attach a link to (london-branch-34)/atm on the gateway-associated container, or identify an already existing link. Alternatively, it might attempt to route to said address via the containerâs anonymous terminus by using it in the âproperties:toâ property.

Â

How the (container-name) destination gets resolved is up to the container. In a simple case, a container might maintain a routing table with {container-name, gateway ip-endpoint} pairs, and will create/reuse connections/sessions to the listed gateways for routing/linking to the respective containers. The routing table may point to intermediary gateways. For link routing, the â(container-name)/node-pathâ _expression_ serves as the link target name in all containers acting as intermediaries. It resolves to node-path on the container that self-identifies as the given container-name.

Â

In effect, you can attach a link to â(container-name)/node-pathâ on any container on a network supporting global addressing, and the container will then patch that link through to the next hop network destination configured for that container name, and until it gets to the target container. For anonymous terminus routing, messages get routed along to the next containerâs anonymous terminus. The ârouting cookiesâ spec then applies for how to establish reply routes.

Â

Â

Thoughts?