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

Brian E Carpenter <> Tue, 18 October 2016 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 833E8129739 for <>; Tue, 18 Oct 2016 12:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SxJwgorztdv3 for <>; Tue, 18 Oct 2016 12:46:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89654128E18 for <>; Tue, 18 Oct 2016 12:46:21 -0700 (PDT)
Received: by with SMTP id s8so1774990pfj.2 for <>; Tue, 18 Oct 2016 12:46:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sQCYXLHErruorb5k6Spm9GBoo/GtEKOqKHM0bfaLnvg=; b=Zg+5gl1mhlT8VuZVMujC8Md4dHPX3V7W5NAle6YtERG6Txa1m5+P42s95/TshOApT5 GFyIZeXVnHCDIIVe313/KzajNEdmYwMhrL5cw692EfFdJqs/G5EzJVF1evMBvh+6duII lFdCA8DQ+4DAZhr2VJSnvobfYua30v7UJ1SGKbPkDsBaFObrGZHBKaxscUUxLirEbzNk WE6EVYwBU6zoMWPA2XG7ijxfcNVwaAxPJl+J1hAg4Tpchw+XNbWXYelnGhG9Y1F1bpPp FX3JV0KOTiZI26sWfI10xc0+aAxIyFrfEDoZJj48eXjEYa4ZO4yzSJWym3bvTyHE0zEX xrwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=sQCYXLHErruorb5k6Spm9GBoo/GtEKOqKHM0bfaLnvg=; b=hzqaQjaaVRjeY1p+dwnasDG21XKJclCmjfm48BnBbL3BKAUto7LcFneY8QEM4qKoK8 ZbgdX97S6699qXbm9YD8fYptFBbMkyscNT6ZLCUXl5paRIS7ai11ZMx8trPasJ7lOA3K g1eMaJSO9jrW8YkCdFpSYy9av1kgEaq1ZsU8dZdDHaT2FHeFqYuXlbl+sK369c23wC6D R/pE5KVsbwY+6e7pmuqs2sQq+m5xqm1icCOU7FH/qfwoDKnF37E5SwQZcGTzvKsbUxtu OOtwb9WwxYn5KAksioiCakflI5LMPiHTQ4ZZ3qTTHsPBV4V9f2XnbInbenxAcrUCmlVH axFw==
X-Gm-Message-State: AA6/9Rl/5sBhhSdgNU/RiRiRbEyxB0Srv6y307CwzHGNk8UsaUUwjgM0NuvSEGffLmFJ6Q==
X-Received: by with SMTP id x75mr3714523pfd.6.1476819981113; Tue, 18 Oct 2016 12:46:21 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id o82sm57879930pfk.24.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 12:46:20 -0700 (PDT)
To: "Michael Behringer (mbehring)" <>, "Max Pritikin (pritikin)" <>
References: <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 19 Oct 2016 08:46:20 +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: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [Anima-bootstrap] peer and domain [was BRSKI State Machine]
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Oct 2016 19:46:22 -0000

On 18/10/2016 21:03, Michael Behringer (mbehring) wrote:
>> -----Original Message-----
>> From: Brian E Carpenter []
>> Sent: 18 October 2016 01:18
>> To: Max Pritikin (pritikin) <>; Michael Behringer
>> (mbehring) <>
>> Cc:
>> Subject: peer and domain [was BRSKI State Machine]
>> 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.
> "peer" is an entry in the adjacency table. Yes, there may be several on an interface, of several different domains. The adjacency table discussion tries to capture that. 

Fair enough. But anyway my comment still applies: a node that is joining the ACP,
or simply updating its ACP adjacencies, will discover all available neighbors...

>> 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.
> Now we're getting into a muddle with ANIMA vs non-ANIMA modes. (And you're right - this is important to sort out). Let's see whether we can sort that. 
> Up front: This is the ANIMA WG, and we're primarily defining the behaviour of an ANIMA node. This is, IMO:
> - There is an adjacency table, that observes what nodes are seen on each ANIMA-capable interface. 
> - This table is fed by discovery (primarily). 
> - Depending on the state of the node, and the state of an adjacent node, different things will happen. 
>   (see my presentation on the reference model, last IETF - all described there)
> For ANIMA, we need to settle on MUST discovery methods. 
> In ANIMA, we will ALWAYS build an ACP to other nodes of the same domain. 
> The adjacency table links BRSKI and ACP automatically: Once I discover a node which is in the same domain, I attempt to set up an ACP connection with that node. 

Sure. And I think I can model that with GRASP - it simply needs an objective
that includes the domain and node credentials, right?

> Outside ANIMA, GRASP can be used in many other ways; BRSKI can be used to derive LDevIDs and nothing else. 
> Do we agree? 

I think so. But I won't know so until I see what the ACP's API looks like.
Remember that GRASP needs to create unicast and multicast sockets, so in an
ACP regime those sockets need to be provided by the ACP.


> Michael
>> Rgds
>>     Brian