On 07/06/2017 04:09, Toerless Eckert wrote: > 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 ?
Unexpected optional parameters in the middle are awkward to parse, so although it would be ugly, I'd tend to put it at the end. <pause minutes="35"/> OK, I implemented discovery-message = [M_DISCOVERY, session-id, initiator, objective, ?tcp-reply-port] About ten lines of code affected. I have dummy ASAs running that can mix and match with or without this field in the message. Well, feedback please? Do we want to make a protocol change at this late stage, or leave things as they are with the option to add this later? Now I know how little coding is involved, I am 100% open minded on this question. Brian > 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 > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
