[Anima-bootstrap] peer and domain [was BRSKI State Machine]

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 17 October 2016 23:18 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 4D1D31299A6 for <anima-bootstrap@ietfa.amsl.com>; Mon, 17 Oct 2016 16:18:27 -0700 (PDT)
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 WM3xtMxyiCz7 for <anima-bootstrap@ietfa.amsl.com>; Mon, 17 Oct 2016 16:18:24 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 DAD1912957B for <anima-bootstrap@ietf.org>; Mon, 17 Oct 2016 16:18:24 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id r16so60913834pfg.1 for <anima-bootstrap@ietf.org>; Mon, 17 Oct 2016 16:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WkPNnmuGI0bKUbFLQacSRKCCEwikO7h3wvq9FCm/7I8=; b=ddIZVRu4wMOGXNIrwihHDVfcr1Q+Wch1LIMbswuluH1Jz2/9JJGP96Q2pn8YIMFhVs 40/VtmHqbyQQZIb/y9f8AB77wrAx/J4F8GVVb9S/z1tG+10KEyQeZGwP1iPdr74c0bDL 3axLwfVnwxP74Yeq/nQur1cDwJp5H/U/9WSy2OcT1fM+nAcBIZKcfZeFRKUJwthBZ/CZ t/AZ/96Tbt1lMPFP+Ico/28QoSuRl7lavLZYYMWkxKxQo6ZvqLO34NzlVdlZLd8Vi5Wm 7p7djMt7uvutIwPcw33MlYrW2V/IIiobhdR894bRH31XS/mCSjofDbEfWkPegEDsUfNI 69vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=WkPNnmuGI0bKUbFLQacSRKCCEwikO7h3wvq9FCm/7I8=; b=IDNVihuXuVMwoWS25eXmPeyMyg6tQtjYbqKWq5TO9hIEZRMCNcLT8ucGItJxnQevJz +Jt95txvUjCBvfKFIFKNiwxANIDD4iY3T8mF692Lwa/lpW8VN/kv91jeUG3ydZIV+Yqg BGqBPO95b8RPQLp8wM5GUEiwwh02AqV7MEgapiZFQTgo527wwJL2gtlqYsdgtoye5e5/ cjrz8J5nodh03uWmlwnu67rXsVlIL6zl6IczHJg0yZdMcRihSm6E0DZQunU92CanSZmE bI20+6ZOaAK/ZRSI0WGJgFy4PWkh0YU1fyQ71o04lEkjYqCT1uPNhfuroEI0klpGzThZ 01IQ==
X-Gm-Message-State: AA6/9Rl3CyDDnNUaVIHaYQ9xKDdFUuGdrKF6k89FQJ/AwNejPEzLDrddhNsZhSz+UvedpQ==
X-Received: by 10.99.3.77 with SMTP id 74mr34278395pgd.174.1476746304326; Mon, 17 Oct 2016 16:18:24 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id qd12sm50657196pab.22.2016.10.17.16.18.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 16:18:23 -0700 (PDT)
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>, "Michael Behringer (mbehring)" <mbehring@cisco.com>
References: <c41c231f3906477f97f1641617de025e@XCH-RCD-006.cisco.com> <6E2BF711-B34F-40E3-9543-CEB3A9BD89DC@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <71f23615-511f-e087-dc32-a041c295de9c@gmail.com>
Date: Tue, 18 Oct 2016 12:18:21 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <6E2BF711-B34F-40E3-9543-CEB3A9BD89DC@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/J9fQl1rh0uWfJZ1VG4KjsSWzLYc>
Cc: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>
Subject: [Anima-bootstrap] peer and domain [was BRSKI State Machine]
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, 17 Oct 2016 23:18:27 -0000


On 18/10/2016 12:05, Max Pritikin (pritikin) wrote:
...
>> - I think we need to bring out more strongly that the state machine needs to track peer and domain. Because, if there is a failure, the pledge should, depending on the failure of course, not try the same domain again, and probably not the same peer either. This isn't coming out today. 
>> In fact, this is why I liked the "adjacency table" so much that I presented in Berlin (and before): Because there you see much clearer that, if enrolment fails with peer x, you may just move to the next one. As mentioned it's all there, but to a new reader this won't come out clearly, I'm afraid.
> 
> Yeah, I can see your point that this is buried in the text of 3.1.1 where it is implied that there is a list of "services returned during each query” and in failure the list processing "picks up where it left off” but thats pretty subtle. 

What exactly is the "peer" in the above text? I tend to assume it's the proxy.
In that case it seems to me that the discovery process (whether it's mDNS
or GRASP) will discover all available proxies regardless of domain. And then
try them in some order of preference TBD.

Also, all of this needs to work in the absence of an ACP and therefore
of the ACP's adjacency table. That applies to GRASP too, because in order
to perform its various link-local actions, it needs to know which interfaces
it has and which link-local addresses it has. And it learns of its link-local
neighbors as a result of discovery. So while I fully appreciate the value
of the adjacency table, we need to be functional without it.

Rgds
    Brian