Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy

Toerless Eckert <tte@cs.fau.de> Mon, 27 February 2017 18:29 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 8A26912999E for <anima-bootstrap@ietfa.amsl.com>; Mon, 27 Feb 2017 10:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GvVxvHS5adD1 for <anima-bootstrap@ietfa.amsl.com>; Mon, 27 Feb 2017 10:29:50 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B302412999D for <anima-bootstrap@ietf.org>; Mon, 27 Feb 2017 10:29:50 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 034C358C540; Mon, 27 Feb 2017 19:29:45 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E01D9B0B873; Mon, 27 Feb 2017 19:29:44 +0100 (CET)
Date: Mon, 27 Feb 2017 19:29:44 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <20170227182944.GA5096@faui40p.informatik.uni-erlangen.de>
References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> <18032.1487866082@obiwan.sandelman.ca> <d75d84f5-d4e3-2fe1-a636-3dfbbefc5784@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d75d84f5-d4e3-2fe1-a636-3dfbbefc5784@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/2Ky1Jhr8sXOTqBw9GIbYfkUFLog>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, anima-bootstrap <anima-bootstrap@ietf.org>
Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy
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: Mon, 27 Feb 2017 18:29:52 -0000

> > What if the Registrar needs to be aware of the Join Proxy (prior to it making
> > use of it), and may need to do some (local) configuration or load balancing
> > in the decision to provide service to that proxy.
> 
> That seems a bit disjoint from "proxy needs to find registrar". And it definitely
> sounds like a two-way conversation, which would more naturally be modelled as
> a negotiation. Can you change that from a "what if?" to a more specific
> requirement that we can model?

+1. would like to see an exaple use-case requirement for this. If there is one, it would
make discovery procedures more complex because so far we are assuming that the easiest
scalable solution is for (large number of) proxies to discovery (few) registrars.

Toerless

>     Brian
> 
> > 
> > This seems to be a clear case where discovery ought to be used.
> > 
> >     > (Also, using link-local examples is an oversight, surely: this should
> >     > be an ACP address, e.g. fdab:dead:beef::1234, I think.)
> > 
> > Yes, exactly. It should be an ACP address.
> > 
> >     > The could be sent all in one Flood message, or in separate ones,
> >     > possible from different sources if there were actually two registrars,
> > 
> > It seems like Flood responses and Responses ought to be interchangeable.
> > 
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> > 

-- 
---
tte@cs.fau.de