Re: [Anima-signaling] Two definite proposals for GRASP protocol change

[Brian E Carpenter <[e-mail]>]

Hi Carsten,
On 11/01/2016 02:38, Carsten Bormann wrote:
> Hi Brian,
> 
> looking over the CDDL again, I'm stumbling over the presence and absence
> of an initiator in the messages.
> 
> First of all, the overall pattern
> 
>      message /= [MESSAGE_TYPE, session-id, ?initiator, *option]
> 
> (3.7.1) is ambiguous in that an initiator looks just like an option, so
> you cannot write a general parser that understands this pattern.
> (This is OK since the specific messages define whether an initiator is
> present or not, but it still feels a bit odd.)

You are correct. That general pattern is not in the definitive CDDL
in Section 6 "CDDL Specification of GRASP". I was just looking for a
way to express the general form of the messages. Would it be better to
just say it in words at this point, without using pseudo-CDDL?

> More odd to me is that the session-id only makes sense in conjunction
> with the initiator, but the latter is not always given.  I can't quite
> make rhyme and reason out of when it's there and when not.  Maybe that
> should be explained in the text (beyond what's in 3.6), including how
> the initiator is implied when not present in the message (source IP
> address of UDP packet?).

The issue only arises at all because of the need to relay discovery
and flood packets from one interface to another. In all other cases
the source address of the packet is fine for disambiguating sessions.
And in my implementation, the issue doesn't even arise for relayed
discovery messages, because it proved easier to launch a new discovery
session than to propagate the old one.

You know, I'm going to look at my code again. If I can do the same trick
for flood messages when they are relayed, we just wouldn't need the
stupid initiator field at all.

> Maybe I'm just confused that discovery pairs
> with response, and not request.  Oh, and there is a certain danger that
> implementation errors in this space are not caught until two initiators
> happen to use the same session-id.  (Protocols with infrequent cases
> where certain protocol behavior becomes important for correctness are
> harder to test.)

True, but during testing I had the opposite problem: responses being
delivered to the wrong thread, which was detected because the session-ids
did not match. That pointed to a quite serious implementation blunder.
> 
> (I also have a suspicion that the protocol might not react well when
> responses are sent from IP addresses different than to which the request
> was sent.  It is harder to get this right with UDP than it should be.)

Yes. That's one reason my implementation is lazy and only supports
TCP for unicast sessions.

> 
> Editorially, I'm not sure I have said that, but I'm not a big fan of the
> non-parsable ("fragmentary") pieces of CDDL in the CDDL fragments.
> They make it a bit harder to extract all the fragments and check
> automatically whether they are consistent with the overall structure in
> section 6.  (They also make we want to quibble over the exact
> fragmentary syntax to be used.)  Instead of
> 
>      initiator /=   ; defined below
>      objective /=   ; defined below
> 
> how about:
>      ; initiator and objective are defined below
> 
> (But then, saying four times that initiator and six times that objective
> is defined below doesn't make a lot of sense either.)
> 
> All this is more in the sense of food for thought than in the sense of
> "Houston, we have a problem".

I certainly don't have a closed mind on that. However, it would be a bit
annoying for the reader to be told many times "Please refer to section 6
for the detailed format." Maybe we should see what the WG thinks.
> 
> Grüße, Carsten
> 
> 
> 
> Brian E Carpenter wrote:
>> On 11/12/2015 03:50, Carsten Bormann wrote:
>>> ... and looking at the CDDL after extracting it manually:
>>>
>>> MESSAGE_TYPE is what kind of thing?
>>>
>>> Assuming this might need to extensible, I think specifying something like
>>>
>>> MESSAGE_TYPE = 0..255 ; a constant defined below
>>>
>>> might help (alternatively: 0..99, if you want to keep them separate from
>>> option numbers).
>>
>> Yes, thanks.
>>
>>> MESSAGE_TYPE = M_DISCOVERY / M_RESPONSE / M_REQUEST / M_NEGOTIATE /
>>> M_END / M_WAIT
>>>
>>> (We might also define `option` and `OPTION_TYPE`, where the former
>>> includes the ip locator options as well as the options built from type
>>> numbers.)
>>
>> Might be cleaner.
>>
>>> s/tstr/text/g, I'd say.
>>
>> Yes
>>
>>> What does it mean to use the same objective-name with different
>>> objective-flags?
>>
>> You use D when only conducting discovery, and N or S when also
>> conducting negotiation or synchronization respectively. It's possible
>> these flags are not really needed - to be frank I will know that when
>> I have completed coding my prototype. If I never need to test the flags
>> they can be removed.
>>
>> Regards
>>    Brian
>>
>>> Grüße, Carsten
>>>
>>>
>>> Carsten Bormann wrote:
>>>> Brian E Carpenter wrote:
>>>>> 1)
>>>>>
>>>>> I invented the PEN field so I think I can also kill it. My proposal is that we take
>>>>> this out of the protocol itself. We state that an objective's name is ":whatever" if
>>>>> it's generic and "vendorString:whatever" if it's vendor specific. The formal
>>>>> definition of vendorString is that it's a unique UTF-8 string not including ":".
>>>>> The format MAY be an FQDN, an email address, or a PEN (represented as a decimal
>>>>> number).
>>>> With the last sentence, there is some hope of uniqueness.
>>>>
>>>> (Of course, we have about a million ways of doing this already in the
>>>> IETF; URNs etc., but the above selection sounds good.)
>>>>
>>>> There is no need for the initial : if you stipulate that generic
>>>> (registered) objectives cannot contain a :.
>>>>
>>>>> As far as GRASP is concerned, an objective name is now simply a string.
>>>>> Simpler protocol, simpler code.
>>>> Sounds good.
>>>>
>>>>
>>>>> 2)
>>>>>
>>>>> Add a global IP address in all Discovery and Response messages, which is
>>>>> a valid address for the initiator, to avoid the remote chance of clashing
>>>>> session IDs. 
>>>> 1) I may not have a global address yet at the time I build such a
>>>> message, right?
>>>>
>>>> 2) Because people will start using these fields for all kinds of things
>>>> (starting side conversations etc.), I'd rather be careful about adding
>>>> mechanism that implies some semantics (here: that of an IP address).
>>>>
>>>> Better to mix in more of this information into a session ID (which needs
>>>> to be long enough to make clashes after a reboot unlikely).
>>>>
>>>>
>>>>> I'm happy. My Python code for GRASP discovery is beginning to work.
>>>>> This doesn't look much, but it's telling me there is something in the
>>>>> discovery cache:
>>>>>
>>>>>>>> discovery_cache[0].asa_locators[0].locator
>>>>>     IPv6Address('2406:e007:6917:1:28cc:dc4c:9703:6781')
>>>>>>>> discovery_cache[0].objective.name
>>>>>     ':Boot'
>>>>>>>> discovery_cache[0].objective.disc
>>>>>     True
>>>>
>>>> Nice!
>>>>
>>>> One thing I'd like to see is extractable CDDL.
>>>>
>>>> 1) Right now, I can't use the usual XPath expression
>>>>
>>>>    //artwork[@type='CDDL']/text()
>>>>
>>>> because the artwork elements don't have type attributes.
>>>>
>>>> 2) The "fragmentary CDDL" concept does not work if the extracted CDDL is
>>>> to be useful to run checks over it etc.  So, I'd change constructs of
>>>> the form
>>>>
>>>>      option /=      ; one of the options defined below
>>>>
>>>> into
>>>>
>>>>      ; use
>>>>      ;    option /= ...
>>>>      ; to define choices for the options.
>>>>
>>>> (BTW, please have a look at
>>>>
>>>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-07#appendix-B.1.5
>>>>
>>>> for a way to combine a general format with specific choices.)
>>>>
>>>> Grüße, Carsten
>>>>
>>>> _______________________________________________
>>>> Anima-signaling mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima-signaling
>>>>
>>>>
>>
>> _______________________________________________
>> Anima-signaling mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima-signaling
>>
>>
>