IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 01 March 2017 16:31 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1BFBE1295D7 for <anima-bootstrap@ietfa.amsl.com>; Wed, 1 Mar 2017 08:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 nDKxBlga3xjb for <anima-bootstrap@ietfa.amsl.com>; Wed, 1 Mar 2017 08:31:41 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA911295C9 for <anima-bootstrap@ietf.org>; Wed, 1 Mar 2017 08:31:41 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05ECAE1EE; Wed, 1 Mar 2017 11:53:59 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DA1E26381A; Wed, 1 Mar 2017 11:31:40 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap@ietf.org
In-Reply-To: <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com>
References: <26901.1488237120@obiwan.sandelman.ca> <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 01 Mar 2017 11:31:40 -0500
Message-ID: <20476.1488385900@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/34va85XDKA5SAuPdxI0g4yifAjo>
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: Wed, 01 Mar 2017 16:31:47 -0000

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?

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.

    > 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 =-

v2.23.0 | Report a Bug | By Email