Re: [Anima] Use of M_FLOOD for discovery of Proxy

If the BRSKI team agree that you want a flood (i.e. unsolicited announcement)
for pledge<->proxy and discovery+synchronization request (i.e. solicited
announcement) for proxy<->registrar, I will suggest complete text for these,
and implement a Python demo version.

So, BRSKIsts please confirm what you want.

Regards
   Brian

On 17/06/2017 12:01, Toerless Eckert wrote:
> On Mon, Jun 12, 2017 at 11:38:52AM -0400, Michael Richardson wrote:
> [reordering]
>> So, let's leave this part, which is
>>     https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1
> 
> 1. I think those sections are incorrect wrt to the GRASP format. Here is whats in BRSKI -06:
> 
>     proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address,
>     transport-proto, port-number ] ]
> 
>     ipv6-address       - the v6 LL of the proxy
>     transport-proto    - 6, for TCP 17 for UDP
>     port-number        - the TCP or UDP port number to find the proxy
> 
> The definition of M_FLOOD from grasp-13 is:
> 
>   flood-message =  [M_FLOOD, session-id, initiator, ttl,
>                   +[objective, (locator-option / [])]]
> 
>   objective = [objective-name, objective-flags, loop-count, ?objective-value]
>   objective-name = text ;see section "Format of Objective Options"
>   objective-value = any
> 
> This means that we do not need to have a locator in the proxy objective because
> the flood message already has the locator element outside the objective.
> 
> The second problem with -06 is that we need to be able to indicate different protocol
> stacks, eg: TLS or (later) CoAP. 
> 
> In draft-carpenter-anima-ani-objectives, the proposal for the proxy-objective was therefore:
> 
>     assistant-objective = ["AN_join_assistant", F_SYNCH, 1, method]
> 
>     eg:
>                           ["AN_join_assistant", F_SYNCH, 1, "BRSKI-TLS"]
> 
> Aka: The objective needs F_SYNCH, that standard objective parameter, the second parameter
> is also mandatory loop-count (must be 1 for DULL)  and then "BRSKI-TLS" would be the value of
> the proposed "method" parameter.
> 
> This is what i did put into the proposed -07 diffs that we are reviewing.
> 
>> {note subject line change}
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>     >> 3.1.1.  Proxy Discovery Protocol Details
>>     >>
>>     >> The proxy uses the GRASP M_FLOOD mechanism to announce itself.  This
>>     >> announcement is done with the same message as the ACP announcement
>>     >> detailed in [I-D.ietf-anima-autonomic-control-plane].
>>
>>     bc> Can we make it:
>>
>>     bc> This announcement SHOULD be done with the same message...
>>     bc> That's only an optimisation, really.
>>
>> Agreed.  I think we all agree that the announcement of the proxy
>> (and the search for ACP peers) is something that M_FLOOD is good for.
>>
>>
>>     bc> (After the discussion back in Berlin, we added a feature to
>>     bc> M_FLOOD to allow arbitrary locators to be attached to a given
>>     bc> flood message. I thought that was what the BRSKI team wanted
>>     bc> at that time. Seems not.)
>>
>> yes, we asked for two locators to be attached to a flood message so that we
>> could announce ACP and Proxy in the same message.  Given the experience
>> with rate limiting that you experienced, this seems doubly prudent since
>> this M_FLOOD will occur outside any ACP, and will have to traverse any
>> number of layer-2 devices.
>>
>> (This will be worse at the beginning of ANIMA deployment, as the layer-2
>> devices will not be ACP aware, but will get better as more devices get with
>> the program...)
> 
> 2. If we send the M_FLOOD for BRSKI and ACP periodicially once every 30 seconds,
> i don't think that we should be worried about sending one instead of two packets.
> 
>>From grasp-13 it seems that i can only put a single grasp-message into a single
> UDP packets. And i can only put a single objective into a single grasp-message.
> 
> I don't think i want a single objective to announce both ACP and BRSKI. Those
> are features of two different ASA. How would i implement this.
> 
>  
>> As there is no dispute about it, I think.
>> If it should be named AN_PROXY, that's fine.
> 
> i have no strong opinion about the term, you pick ;-).
> 
> Cheers
>     Toerless
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>>
>>
> 
> 
> 
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 