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 <[email protected]> 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 <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
