OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [amqp] Addressing Model Blog Post


On Mon, Nov 12, 2018 at 5:00 PM Rob Godfrey <rgodfrey@redhat.com> wrote:


On Mon, 12 Nov 2018, 19:00 Clemens Vasters <clemensv@microsoft.com wrote:
My key point is that I donât want to constrain the scope naming model to a particular notion of naming authority or model for how the legitimacy of such an authority and of assigned names might be determined.Â

Names are names.

+1 - this is why I argue that the AMQP spec define the address with a normal "/" separated URI path, without special syntax/semantics for leading components.Â
Â
If you hit 8.8.8.8 and thereâs an Internet network access paywall, that paywall completely owns that address until you put down money. You are 100% at the mercy of your next hop router for what 8.8.8.8 means.

Similarly, an address like /(foo)/bar/baz can be interpreted at the mercy of the system - all you have is normal TLS/SASL trust in who your talking to. Whether the leading component is /(foo)/ or /foo/ means nothing . Whether the routers that deliver the message use /(foo) or /(foo)/bar or /(foo)/bar/baz to identify an "endpoint" (whatever that means - host, cluster, serverless-foggy-spatula, etc.) to process the message is irrelevant and should not (cannot) be constrained by the syntax of the address. A Clemens router is free to assign special meaning to the first component , a Dispatch router is free to use ann arbitrary path prefix or path pattern in its routing rules. The user shouldn't have to know or care.

If you need interenet-scale unique addresses, then use the existing internet-scale URI authority (IP or DNS) - we're not going to reinvent or replace those //onramp.net/foo/bar/baz. Use existing IP/DNS techniques to scale access to onramp.net, then make sure your on-ramps use a consistent AMQP naming/routing strategyÂto scale message routing within your system. That's what every massively successful internet-scale protocol does (e.g HTTP, E-mail) and while they're not AMQP, I think addressing analogy is very strong. HTTP uses a simple URI path, e-mail succeeded with a free-format string address

Sure ... The only point I'm trying to make is that in a "global" system there must be some way to appeal to an authority (which may be via the security/authorisation layer) to verify that the named is not being "spoofed" and which (as a side effect) also guarantees some sort of uniqueness (so we can't all self identify as 'messaging' or 'amqp')... I'm not saying that the name says anything about routing topology other that that you're immediate counterparty will have to know the next step for the name. I'm specifically not saying that the name/scope in anyway must correspond to DNS.

-- Rob

Â


Von: Rob Godfrey <rgodfrey@redhat.com>
Gesendet: Montag, November 12, 2018 6:03 PM
An: Clemens Vasters
Cc: Alan Conway; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post
Â


On Mon, 12 Nov 2018 at 17:53, Clemens Vasters <clemensv@microsoft.com> wrote:
I believe the authority is exactly the next party Âyou talk to and nobody else. If that party doesnât know what to do with a name, it routes to some upstream Ââdefault gatewayâ or simply fails out.

I disagree that there need to be central authorities at all. If the container behind the next hop feels like it can act in the role of foo.bar.example.com and itâs authorized to do so by an assumed overlaid security layer and rule set, it can go right ahead and handle the message.

You still need a *naming* authority for the scopes - you are just delegating that naming authority to the security authority ... I'm not saying you need to connect to that authority at any point, but you need some way of being able to prove ownership of a scope.Â
Â

Scope names are like IP addresses. They are not like DNS A/AAAA records.

IP Addresses are still assigned by an authority. I can't just claim to be 8.8.8.8 and expect that to be respected when connecting to the internet.ÂÂ

-- Rob
Â
Â

Von: Alan Conway <aconway@redhat.com>
Gesendet: Montag, November 12, 2018 5:03 PM
An: Rob Godfrey
Cc: Clemens Vasters; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post
Â


On Thu, Nov 8, 2018 at 4:19 PM Rob Godfrey <rgodfrey@redhat.com> wrote:


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.

Brings us back to "who is the authority" for AMQP domains.Â

I'd like to support the case where DNS Is the authority thusly:
GIve amqp://foo.net/x/y we allow
- client connects to foo.net and uses AMQP address "//foo.net/x/y" i.e. including the authority from the URL.
- client connects to foo.net and uses relative AMQP "/x/y" - server may be able to pick up foo.net from virtual host and route elsewhere for link addresses, but message to:Â addresses can't be changed so in that case the client must use an absolute address.

In the case where the on-ramp IP or authority is different from the AMQP authority, the client must in any case be aware of two addresses, so it connects to amqp://on-ramp.net but sends to //foo.net/x/y



--
_____________________________________________________________________________

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]