On Mon, Jun 05, 2017 at 10:56:07AM +1200, Brian E Carpenter wrote:
> > IMHO, the discover multicast message needs to have another message element
> > which is the
> > port number to reply to. Thats assuming the reply is always TCP. If you
> > feel UDP
> > should also be an option then the discovery message should indicate the
> > desired
> > reply mode UDP/TCP and port number.
>
> We could have designed it that way but we didn't, and I don't want to make
> such
> a change in the middle of IESG discussion (unless of course we find a bug).
I have not seen yet a protocol requirement that an instance needs to find
a dynamic port that it can bind to both via UDP and via TCP. Especially
given how this requirement can be avoided by adding a simple signaling element
to the GRASP header of multicast discovery messages.
The main issue is also that unlike a lot of other features in GRASP,
this would be hard to introduce in a backward compatible fashion later:
Just for curiosity: Lets assume the messaging was changed later to:
discovery-message = [M_DISCOVERY, session-id, initiator, ?tcp-reply-port,
objective]
tcp-reply-port = port-number
a) I hope/guess that "old" GRASP implementations would skip/ignore this element
because CBOR is self-identifying and the implementation wouldn't know
this signaling element. Right ?
b) Even if a) is true, an old receiver of M_FLOOD would not be able to
respond.
Wrt to IESG: You have more experience with IESG review. If they have no concern
with
this, i leave it up to you authors how to handle this.
> > In the context of standard socket APIs, a responder can not know for
> > certain that
> > the initiator TCP port is owned by the process that initiated the discovery
> > request. The only mitigation is to
> > a) trust the GRASP daemon on the remote side.
>
> In the ACP, we can do that.
>
> > b) The remote GRASP daemon has bound to the GRASP UDP port, so discovery
> > multicast packets whose source UDP port is also the gRASP port (the
> > destination port must be the GRASP port) are trusted to have come from
> > the
> > remote GRASP daemon. And then the TCP port number in the discover message
> > is trusted.
>
> Yes, in the single-instance case. But that isn't the general case.
I am always talking about multi-instance. The difference is just
which process (ASA or GRASP) is sending the M_DISCOVERY. The TCP GRASP
connection would always be handled only by ASA processes.
> > c) GRASP daemons can use local mechanisms to ensure that the TCP port
> > indicated
> > by an ASA is also owned by the ASA (aka: the interface between an ASA
> > daemon
> > and a GRASP daemon can use a POSIX standard UNIX socket and the gRASP
> > daemon
> > creates that socket and passes it back to the ASA). That way the GRASP
> > daemon
> > knows the TCP socket port number reliably.
>
> If the discovery is executed entirely by the GRASP core, the ASA never knows
> anything about the socket. That's my preferred implementation but it
> isn't required by the protocol spec, obviously.
>
> >
> > This is all convoluted. If you are not a big fan of concoluted explanatory
> > text
> > like what i wrote up above, i can understand it. But i am not a big fan of
> > suggestive incomplete text that you have on the draft right now...
>
> Sure. And changing to to be specific that this is needed for mutiple instances
> in one node is a good idea (and is IMHO a complete explanation of why it's
> needed).
If we try to find a good place outside the main GRASP spec for this type of
explanatory text, which draft could that be ? the ASA guideline draft looked
a bit more higher layer. grasp-api draft ?
> >> No. When you discover an objective, the discovered locator is [address,
> >> protocol, port].
> >> Then there's an option on a flood to tag the flooded objective with
> >> [address, protocol, port].
> >> I just don't see the problem.
> >
> > I am talking about the protocol inside of the UDP/TCP locator.
>
> Yes, that's really the same point that Adam Roach caught. I think
> the next text will be clearer (in the description of "Locator IPv6
> address option", although it also applies to IPv4).
Thanks. I am really looking for textual clarity on two points:
a) when i look at a locator, what context will it be in ?
IMHO: its in the context of GRASP (aka "ACP" for ANI deployments), unless
it is in the objective-value, in which case its an objective local
definition.
b) How do i figure out what protocol is being run on top of of a locator ?
...It's convoluted. semantic of the objective determines it, so if the
objective
has multiple protocol options, then the objective-value has to have some
element to define
it. But there is no standard attribute for this in CDDL defined so far;-(
Aka: if we would define a standard CDDL elemnt "locator-method" that we
would
also use in BRSKI (string) that defines the different possible options for
the
protocol of the locator... that would help.
> > See your own example for BRSKI with GRASP in the ani recommendation draft.
> > What you call method = BRSKI-TLS is what i call the protocol
>
> Sure, but that's relative to a very specialised infrastructure objective.
> I regard that as an almost pathological case that needs a separate spec
> (inside BRSKI, but I havn't had time to look at the latest BRSKI).
I don't think it's pathological. Whenever an autonomic function is (also) using
some non-GRASP
protocol between its ASA, and uses GRASP to negotiate such a protocol, then we
have this
case.
> > Without that line we do not have a normative word for the parameters of
> > GRASP
> > objectives.
>
> Well, OK, but for overall consistency I think it has to be objective-value.
Ok.
> > All locators used outside of grasp-parameters MUST be from the namespace
> > GRASP is
> > running in.
>
> That's more or less what the note in "Locator Options" says. I can make it
> more
> explicit. I'm not convinced it needs a MUST though. Who can guess what people
> will invent in future?
Anything outside the objective-value is part of the GRASP spec, right ?
SO if someone invents a case for such a locator to be in a different namespace,
then
that would have to be defined in an extension/revision to GRASP, right ?
== should be correct and safe to make the statement in the GRASP spec now.
> Hmm. I have a lot of changes stacked up in the XML. I'm quite keen to
> post the draft.
Great.
Cheers
Toerless
>
> Brian
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
