Re: [Anima-bootstrap] agenda and details for Tuesday

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 02 March 2017 01:07 UTC

To: Michael Richardson <mcr+ietf@sandelman.ca>, anima-bootstrap@ietf.org
References: <26901.1488237120@obiwan.sandelman.ca> <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com> <20476.1488385900@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <598a826a-5c6a-589b-8c7f-a3c4f1cfcbbc@gmail.com>
Date: Thu, 02 Mar 2017 14:07:08 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20476.1488385900@obiwan.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/pnmhUpO8lBS9MUIspSS9NQhqxCk>
Subject: Re: [Anima-bootstrap] agenda and details for Tuesday
Precedence: list

On 02/03/2017 05:31, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     >> And this led me to thing that the Registrar discovery probably needs a full
>     >> NEG_SYN, rather than M_FLOOD or M_DISCOVER...
> 
>     > You could do both. Use Flood as the baseline and Negotiate or
>     > Synchronize if the baseline info is insufficient.
> 
> Please remind me if I've gotten the flow wrong, I just re-read section 3.8.4
> and 3.8.5 and 3.8.6 of grasp-09.
> 
> Does it go:
>      Proxy             Intermediate        Join Registrar
> 
>      M_DISCOVERY --> MCAST
>                         M_DISCOVERY--->MCAST
>                               <---- unicast----  M_RESPONSE (I'm here)
> 
>         <----unicast---- M_RESPONSE (he is there)
> 
>      M_REQ_NEG ---------unicast----------------->
>                <---------------------------------
> 
> 
> that is, the intermediate is just caching the location of the Join Registrar,
> and really if we want to do negotiation, we should do it directly?

Yes, once you have discovered the address. (And discovery is only supposed
to return a global-scope address, typically ULA, except for the special case
where the target is on-link and no global-scope address is available.)

> In this context, I don't see much difference, as you say, between M_DISCOVERY
> vs M_FLOOD, except for when it occurs and the need to keep the cache of
> things around.  In either case, the locators that we were discussing ought
> really to only tell the Join Proxy where to find the Join Registrar's
> grasp daemon, not where to find the registration system itself.

Sure. The extra tweak in M_FLOOD is that you MAY attach a specific locator
to the flooded objective, in case you don't want to perform a follow-up
M_REQ_NEG (or M_REQ_SYN).

   Brian
 
> 
>     > I'm not sure if GRASP is Turing-equivalent, but I think you
>     > can probably do anything you want.
> 
> ha. I await the HAL9000 GRASP objective to be defined.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>

[Anima-bootstrap] agenda and details for Tuesday Michael Richardson
Re: [Anima-bootstrap] agenda and details for Tues… Brian E Carpenter
Re: [Anima-bootstrap] agenda and details for Tues… Michael Richardson
Re: [Anima-bootstrap] agenda and details for Tues… Brian E Carpenter