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

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

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FFE129445 for <anima-bootstrap@ietfa.amsl.com>; Wed, 1 Mar 2017 17:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luBpwUg7JmYT for <anima-bootstrap@ietfa.amsl.com>; Wed, 1 Mar 2017 17:07:06 -0800 (PST)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CA9129431 for <anima-bootstrap@ietf.org>; Wed, 1 Mar 2017 17:07:06 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id w189so16109764pfb.0 for <anima-bootstrap@ietf.org>; Wed, 01 Mar 2017 17:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=a4a/NxAZGx3i9m/LZrt1iOVgdG5ei/EWxtNLd7pmZCE=; b=daJIKbjEpmabqhEjD/mK6IeVf5kVQ4+D+48ZB5CF+7K+51qje93JHEudP7wkJWqrRq KR3oSPIiKODw3HlOa3w1kOKgljcC3AlXDiGMGcmyd0M4D8ckEMKmfGpFqx0X/Zz9xaWh iKpvv6I7tVdYPt+mcMjgPoyBTtUYz1VS9qh6BDMbfZ6hd10fWJn4qAfwc6zbnR/actlM tLhSNAPuCV6Fox9251UX7J0CfkSCvClmfezaz16vzXIfUc08lhWKjSgVIrvHrfHUpga8 /uuxvFIFdI3QdIMsptSvZkT94mUmmeV66v6Fm5ZeA3NzDVygZBQGBCculIjxeqCdjTXT xrGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=a4a/NxAZGx3i9m/LZrt1iOVgdG5ei/EWxtNLd7pmZCE=; b=g9Xh09n2FxrK8dchhBvSKaFsoyQ4SDr5k/M0w442WSzEJyFxuOQLrY12rZHW8Xy1bs EHQyN6EsIDnsX0EFDGxQ94i1it7XJ0T1xCIjVu3B+8FDUvUuTgeEfeO3zG6dYMxRBIeP /uFKKAdAAIP5XbtEe/bQpRyemekW5DIjDdQElq7q8/i9af7CgFaZG6ZFs18/KiH3kZ+A 2w48lce6wFbvMhLRw2ZuzuO0g5/VXIgaKu8AAkaBqBgPYZjBMFsnnyhiW2S5eop16DMa QQuUePpIhfEceF6XS7/0a08IiczEm7+n88ocjlYCIFJDNFfm2xwPl5rP0x68KM/Q28hR T6PA==
X-Gm-Message-State: AMke39nnIUIfdJ5VGwo6BObAwPR0Fxue5l90+qgP3vM7DPnCBWWg0H+a3blJQtH9UuIbGw==
X-Received: by 10.99.228.69 with SMTP id i5mr12501566pgk.63.1488416825925; Wed, 01 Mar 2017 17:07:05 -0800 (PST)
Received: from ?IPv6:2406:e007:6663:1:28cc:dc4c:9703:6781? ([2406:e007:6663:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d72sm6366097pfb.21.2017.03.01.17.07.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 17:07:05 -0800 (PST)
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, 2 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
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 01:07:07 -0000

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>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>