Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options

> FYI - as an editorial note the paragraph explaining flooding is buried in s3.3.5 and could probably be called out more clearly in the text. Perhaps its own section or in the Response section? Similarly s3.9.1 includes the text: "and for terminating flooding as described in FLOODING” which looks like an incomplete reference as if you had already planned to pull flooding out into its own section.

Good points.

BTW I don't fundamentally care whether or not bootstrap uses the GRASP
mechanisms - I just want to make sure that they *could* be used if that
turns out to be optimal.

Regards
   Brian

On 05/12/2015 13:25, Max Pritikin (pritikin) wrote:
> 
>> On Dec 4, 2015, at 5:06 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> On 05/12/2015 12:44, Max Pritikin (pritikin) wrote:
>>> Brian, 
>>>
>>> Are the session-id and the nonce equivalent?
>>
>> Well, I made an implementation choice that when an ASA registers itself
>> with GRASP it gets back a nonce, used to validate future calls, so
>> that no other process can masquerade as the same ASA. And yes, I
>> just re-used the existing Session ID mechanism to assign that nonce.
>> However, each transaction that an ASA initiates will get its own
>> Session ID.
>>
>>> Why is the 30000 a parameter passed into the into the grasp.discover call? This looks like a timeout for how long to wait for a response (GRASP_DEF_TIMEOUT/2)? If so this would provide the 30s behavior but is leveraging a side-effect dubiously. Sufficient for PoC; I’m just asking to understand.
>>
>> Correct. Again, it's just an implementation choice and I agree it's a bit
>> of a kludge. It could be done more elegantly. (Although I must say that the
>> threading support in Python is a dream to use.)
> 
> all goodness. thanks. 
> 
>>
>>>
>>> Toerless’s suggestion appears to be to include the “locator-option” within the discover message. Did you include that? Currently "locator-option” is not part of the [grasp] s3.7.2 Discover Message. Are you comfortable adding that as Toerless argues for?
>>
>> It turns out that we have to do that anyway, for other reasons that Joel Halpern
>> pointed out (since Session IDs are unique per node, not network-wide). That will
>> be fixed in the next GRASP draft. But in any case, the recipient of a LL multicast
>> can know the source address (and interface #) even if they are not in the payload.
>> So this isn't a problem.
>>
>> However, I do think that the "announcement" nature of this is better suited
>> to the unsolicited flooding message than the Discovery message, because then
>> it's natural to include data in the message.
> 
> so rather than add “locator-option” to the discovery message use unsolicited response messages. This makes sense (very similar to mDNS approach!). 
> 
> FYI - as an editorial note the paragraph explaining flooding is buried in s3.3.5 and could probably be called out more clearly in the text. Perhaps its own section or in the Response section? Similarly s3.9.1 includes the text: "and for terminating flooding as described in FLOODING” which looks like an incomplete reference as if you had already planned to pull flooding out into its own section.
> 
> - max
> 
>>
>>    Brian
>>
>>>
>>> - max
>>>
>>>> On Dec 3, 2015, at 9:27 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>>
>>>> On 04/12/2015 14:43, Toerless Eckert wrote:
>>>>
>>>> ...
>>>>>  IMHO, i would let the proxy periodically (30 secs) just announce that its providing
>>>>>  AN enrollment proxy function via link-local IPv6 multicast. 
>>>>
>>>> Here's the Python code to do that with my prototype:
>>>>
>>>> import grasp
>>>> import time
>>>>
>>>> OK, nonce = grasp.register_asa("Boot")
>>>> if not OK:
>>>>   #we've got a serious problem...
>>>>   raise RuntimeError("Can't register as ASA")
>>>>
>>>> obj = objective(0,":Boot")
>>>> x = grasp.register_obj(nonce, obj)
>>>> if not x == "OK":
>>>>   #we've got a different problem...
>>>>   raise RuntimeError(x)
>>>>
>>>> while True:
>>>>   grasp.discover(nonce, obj, 30000)
>>>>
>>>> What this does is register the caller as an ASA called "Boot" that handles the
>>>> objective called ":Boot", and then LL multicast a discovery message every
>>>> 30s. That will tell the others that it's there. It's running in another window
>>>> as I type. I didn't write the handler code for the receiving end yet though,
>>>> so I just get output like this twice a minute:
>>>>
>>>> CBOR->Python gives:  [1, 1248700, b'$\x06\xe0\x07S\x07\x00\x01(\xcc\xdcL\x97\x03g\x81', ':Boot', 0, 6, 0]
>>>>
>>>>> Maybe with port-number
>>>>>  and protocol (EST over IPv6 link-local ) as parameters so it's extensible.
>>>>
>>>> If you want parameters, we'd need to use the (synch) flooding method
>>>> instead. Maybe I'll write that code next week; it will be very similar to
>>>> the discovery case. I don't think there are any real problems here.
>>>>
>>>> Python+CBOR is fun. Thanks, Toerless, for pushing the CBOR idea.
>>>>
>>>>  Brian
>>>>
>>>> _______________________________________________
>>>> Anima-bootstrap mailing list
>>>> Anima-bootstrap@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>>>
>>
> 