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.carpen...@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+i...@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > > >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
