Re: [Anima] M_FLOOD vs M_DISCOVERY

[Brian E Carpenter]

Michael,

You show the objective as ["AN_registrar", F_DISC, 255 ]
i.e. with a null value. SHouldn't it include a value field that indicates
the supported method(s)? I've been using values like "BRSKI-COAP" and
"BRSKI-TLS". Just relying on the port numbers seems a bit schlonky.

Regards
   Brian

On 09/01/2017 14:40, Michael Richardson wrote:
> 
> Michael Richardson  wrote:
> bc> Secondly, the methods aren't mutually exclusive. If the "normal"
> bc> method is flooding an objective that I've called "AN_registrar" in my
> bc> toy code, nothing prevents discovery/synchronize being used as a
> bc> backup.
> 
> > Question: should all the internal objectives be AN_ ??
> 
> https://github.com/anima-wg/anima-bootstrap/commit/853dc9334c6dcb0e6a9b199b846960be18a0504c
> 
> I will add this to the other document, and maybe I can learn how to better 
> present
> it.
> 
> This is the latest text I just wrote:
> 
> 
>   
> The registrar responds to discovery messages from the proxy
> (or GRASP caches between them) as follows:
> 
>   
> 
>   Figure 6: Registrar Discovery
> 
>   
> 
>   
> The response from the registrar (or cache) will be a M_RESPONSE with 
> the
> following parameters:
> 
> 
> Figure 7: Registrar Response
>   
>   
> 
> 
> 
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] M_FLOOD vs M_DISCOVERY

[Brian E Carpenter]

Regards
   Brian Carpenter



On 09/01/2017 13:57, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> >> We want to use GRASP to permit the bootstrap proxy to discover where
> >> the Registrar(s) are.  As far as I can see there are really two
> >> options, and they might not be mutually exclusive.
> >>
> >> a) start a multicast M_DISCOVERY which will be propagated forward and
> >> can be answered from caches.  b) listen for an M_FLOOD.
> >>
> >> As I see it there are advantages and disadvantages to each.
> >>
> >> My take before was that M_DISCOVERY was to be preferred in most cases.
> >> I'm really just writing to confirm this belief.
> 
> > As always, it's a tradeoff. My impression after discussions some months
> > ago was the the BRSKI team preferred M_FLOOD, but I have no strong
> > opinion.
> 
> We want M_FLOOD for discovery *OF* the proxy.
> I'm asking about discovery *BY* the proxy *OF* the registrar.

Understood (now, but not when I wrote my toy code or the draft).

> > Firstly, I assume that the registrar/proxy hookup can take place over
> > the ACP, because the nodes involved already have certificates and the
> > ACP has formed itself.  (This will occur as an expanding circle around
> > the registrar, which will proxy for itself on its own link-local
> > interfaces.) So from a security viewpoint, there isn't much difference.
> 
> Agreed.
> 
> > Secondly, the methods aren't mutually exclusive. If the "normal" method
> > is flooding an objective that I've called "AN_registrar" in my toy
> > code, nothing prevents discovery/synchronize being used as a backup.
> 
> Question:  should all the internal objectives be AN_ ??

Personally I think that would be a helpful convention, but I'm not sure
we should have a *rule*.

> > That said, it seems that once a proxy has found a registrar, there's no
> > need for a regular refresh, so discovery seems appropriate. (Don't
> > forget that the discovery cache will time out, but that's standard.)
> 
> > Send comments on
> > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We
> > assumed the flooding model for registrar/proxy there, but described
> > both models for the pledge/proxy hookup.
> 
> I intend to contribute to it this week.

Great. And where the assumptions are false, don't hesitate to say so.

Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] M_FLOOD vs M_DISCOVERY

[Michael Richardson]

Michael Richardson  wrote:
bc> Secondly, the methods aren't mutually exclusive. If the "normal"
bc> method is flooding an objective that I've called "AN_registrar" in my
bc> toy code, nothing prevents discovery/synchronize being used as a
bc> backup.

> Question: should all the internal objectives be AN_ ??

https://github.com/anima-wg/anima-bootstrap/commit/853dc9334c6dcb0e6a9b199b846960be18a0504c

I will add this to the other document, and maybe I can learn how to better 
present
it.

This is the latest text I just wrote:


  
The registrar responds to discovery messages from the proxy
(or GRASP caches between them) as follows:

  

  Figure 6: Registrar Discovery

  

  
The response from the registrar (or cache) will be a M_RESPONSE with the
following parameters:


Figure 7: Registrar Response
  
  




--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] M_FLOOD vs M_DISCOVERY

[Michael Richardson]

Brian E Carpenter  wrote:
>> We want to use GRASP to permit the bootstrap proxy to discover where
>> the Registrar(s) are.  As far as I can see there are really two
>> options, and they might not be mutually exclusive.
>>
>> a) start a multicast M_DISCOVERY which will be propagated forward and
>> can be answered from caches.  b) listen for an M_FLOOD.
>>
>> As I see it there are advantages and disadvantages to each.
>>
>> My take before was that M_DISCOVERY was to be preferred in most cases.
>> I'm really just writing to confirm this belief.

> As always, it's a tradeoff. My impression after discussions some months
> ago was the the BRSKI team preferred M_FLOOD, but I have no strong
> opinion.

We want M_FLOOD for discovery *OF* the proxy.
I'm asking about discovery *BY* the proxy *OF* the registrar.

> Firstly, I assume that the registrar/proxy hookup can take place over
> the ACP, because the nodes involved already have certificates and the
> ACP has formed itself.  (This will occur as an expanding circle around
> the registrar, which will proxy for itself on its own link-local
> interfaces.) So from a security viewpoint, there isn't much difference.

Agreed.

> Secondly, the methods aren't mutually exclusive. If the "normal" method
> is flooding an objective that I've called "AN_registrar" in my toy
> code, nothing prevents discovery/synchronize being used as a backup.

Question:  should all the internal objectives be AN_ ??

> That said, it seems that once a proxy has found a registrar, there's no
> need for a regular refresh, so discovery seems appropriate. (Don't
> forget that the discovery cache will time out, but that's standard.)

> Send comments on
> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We
> assumed the flooding model for registrar/proxy there, but described
> both models for the pledge/proxy hookup.

I intend to contribute to it this week.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] M_FLOOD vs M_DISCOVERY

[Brian E Carpenter]

On 09/01/2017 06:27, Michael Richardson wrote:
> 
> We want to use GRASP to permit the bootstrap proxy to discover where the
> Registrar(s) are.  As far as I can see there are really two options, and they
> might not be mutually exclusive.
> 
> a) start a multicast M_DISCOVERY which will be propagated forward and can be
>answered from caches.
> b) listen for an M_FLOOD.
> 
> As I see it there are advantages and disadvantages to each.
> 
> My take before was that M_DISCOVERY was to be preferred in most cases.
> I'm really just writing to confirm this belief.

As always, it's a tradeoff. My impression after discussions some months ago
was the the BRSKI team preferred M_FLOOD, but I have no strong opinion.

Firstly, I assume that the registrar/proxy hookup can take place over the ACP,
because the nodes involved already have certificates and the ACP has formed 
itself.
(This will occur as an expanding circle around the registrar, which will proxy
for itself on its own link-local interfaces.) So from a security viewpoint,
there isn't much difference.

Secondly, the methods aren't mutually exclusive. If the "normal" method is
flooding an objective that I've called "AN_registrar" in my toy code,
nothing prevents discovery/synchronize being used as a backup.

That said, it seems that once a proxy has found a registrar, there's no
need for a regular refresh, so discovery seems appropriate. (Don't forget
that the discovery cache will time out, but that's standard.)

Send comments on 
https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives
We assumed the flooding model for registrar/proxy there, but described both 
models for
the pledge/proxy hookup.

Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima