IETF Logo Mail Archive

[Anima] proxy discovery of registrar

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 August 2017 00:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5611D13167B for <anima@ietfa.amsl.com>; Tue, 1 Aug 2017 17:38:45 -0700 (PDT)
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 vo96aH0uEn3J for <anima@ietfa.amsl.com>; Tue, 1 Aug 2017 17:38:43 -0700 (PDT)
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 45DF7129B25 for <anima@ietf.org>; Tue, 1 Aug 2017 17:38:43 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9DCE2E009 for <anima@ietf.org>; Tue, 1 Aug 2017 20:40:31 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F383480B17 for <anima@ietf.org>; Tue, 1 Aug 2017 20:38:41 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
X-Attribution: mcr
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: Tue, 01 Aug 2017 20:38:41 -0400
Message-ID: <9024.1501634321@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/7TeGBva6d7-qz4iVvt3_BYbcRpo>
Subject: [Anima] proxy discovery of registrar
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 00:38:45 -0000

Brian, I opened issue https://github.com/anima-wg/anima-bootstrap/issues/23
to close the question about how the BRSKI proxy finds the Join Registrar.

1) Toerless needs to remove that text from ACP document.  It does not belong.
   BTW, I was reviewing https://www.rfc-editor.org/cluster_info.php?cid=C325
   and GRASP is going to wait for the ACP document. Ick.  I thought it was
   just CDDL.
   The more speculative text that can be removed from the ACP document, the
   faster it will progress.

2) M_FLOOD vs M_DISCOVER.  Your issue
   https://github.com/anima-wg/anima-bootstrap/issues/22 point 3, about how
   we did things wrong is well taken.

   I think that I prefer to use M_DISCOVER to find the Registrar, as the
   information about it is most likely cached in a nearby node.

   Toerless has instead written the M_FLOOD mechanism.
   We started a thread a few weeks ago about this... what happened to it, I
   would have to look.  In either case, I would like to please discuss this
   in the context of the BRSKI document, not the ACP.

Brian, we selected M_DISCOVER/M_NEG_SYN method because:
  a) we didn't think the location of the Registrar would change frequently,
     or perhaps ever. Of course the responses have TTLs, so it's not really
     a big deal.

  b) your experiences with mcast at IETF98 has made me concerned that we
     should not use flooding if we don't have to.
     OTOH, the proxy is going to discover the registrar over the ACP,
     and we won't have any L2 switches directly in the path to like we
     had at IETF98.


The process is supposed to be:
    proxy: M_DISCOVER--->
                   neighbor: M_DISCOVER--->
                                           registrar
                          <--- M_RESPONSE--
                   neighbor (caches)
        <--- M_RESPONSE--

I think. I don't know anymore...

Do we want:
   o  a discovery objective option (Section 2.10.1).
   o  a negotiation objective option (Section 2.10.1).
   o  a synchronization objective option

??

I think that I concluded we needed the third option, which is why I think
that I wound up into M_REQ_SYN.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email