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

[Toerless Eckert <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
[e-mail]