Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 23 September 2017 20:59 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 6BCD3132C3F; Sat, 23 Sep 2017 13:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 rGdkhwozT5Jg; Sat, 23 Sep 2017 13:59:01 -0700 (PDT)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 CE022129B7A; Sat, 23 Sep 2017 13:59:01 -0700 (PDT)
Received: by mail-pg0-x22c.google.com with SMTP id j16so2169712pga.1; Sat, 23 Sep 2017 13:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yqXHY6cddYdQ39XmIiOz10Qt1k5ZL07ykTcz2xDm8so=; b=hvOFg0rH9hFceU/mp5/3mU7xKWd9Vsrmqw0wBNwe/78/l4PQO0AEZo7RM9zkiN4G+E pd6quMqWjgjtbLJ5drZ5nU6rIEvcwSwlld0c7rh3ut2TvNB+n9KhIg5CiOdxxhtzcbe9 IKSUJXo3GHUt6hhWnos9wZ6KchD5hX+m0UyQ5/+yUm0iJhngVVWyD4j6vHEudsuCUGQ8 4sRGiMrnskHpymA+2eI4/PipjHLD+HytJiipBsMhW0jQKfyg/QW9hGTmxopbng72Gh/q kmj8sOTrO7GhFF5d2Va5aS/FHqAlD4u+wWlGppmgoz0DWDWcd27uPUKUIF49maS8Ft+p NJ5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yqXHY6cddYdQ39XmIiOz10Qt1k5ZL07ykTcz2xDm8so=; b=qcrrwia/jjcfZKSRF5DC4eAn719LeV9L+QRA2WOp/G6MIMYZdIgj2776jMliLJ9pdC VgsVv2R/+qyhTdkOnDksNnlBOaAWwYjkwQlnHblz8hC41T3BOUSqxHyMwFQQSW/CxKxg r5lbG+IjANNEsQBZCT9AF/pu6P87PzcKFxwP/RCubFnlSSxs2hnrmUi6H4EhOG7zBeKq 4hgjoJLsTM9diQZuRL5n+0gVc9uoA1zjEaEwS3P+7MrMaVacTsi1CHMVvCjtXr1FBnSj 2D2kf+/x+jkk9damRtF0v4OuOVDHlmuUM72HkhikUYEn7OHwyANl8fKarJ8f25RVV30T HP7Q==
X-Gm-Message-State: AHPjjUgu8cLHgSpve9+/QEeuTvb/z32QK8sY1WUpnytoFSWIyoGzVCGp UTRZ7bPX82VRehsvsxjoFNzlpA==
X-Google-Smtp-Source: AOwi7QBEMaSgfRVJ2qJawJ3e0dv7B4lNmkSamVNUTI5RiWD07eNiBvz539Bt7yghEN5QTKTTV9iVUw==
X-Received: by 10.84.129.65 with SMTP id 59mr3033873plb.442.1506200340715; Sat, 23 Sep 2017 13:59:00 -0700 (PDT)
Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q13sm7690708pfi.110.2017.09.23.13.58.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Sep 2017 13:58:59 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Toerless Eckert <tte@cs.fau.de>, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com> <13482.1506195787@obiwan.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <11c60420-0460-9f6e-50ac-e7485d58a5ce@gmail.com>
Date: Sun, 24 Sep 2017 09:58:54 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <13482.1506195787@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wHMEDI6_f1QqatGXwPNjyeldsOE>
Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]
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: Sat, 23 Sep 2017 20:59:03 -0000

On 24/09/2017 08:43, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     >> That way, the recipient can compare sender-ttl with the TTL of the received objective
>     >> and threeby figue out which one is closest.
>     >>
>     >> I fine either way. I just tried to go for the most simple, logical option.
> 
>     > Right, so the question for the WG (are you all listening?) is whether we
>     > want to defend the value of the loop count in limiting propagation of multicast
>     > messages. (Remember that it has another role in negotiation sessions, where
>     > it really is a loop-prevention counter.)
> 
>     > I will note that in testing on looped topologies I have seen looped multicasts
>     > dropped because of the session ID; theoretically that is sufficient, and the
>     > loop count is logically redundant.
> 
> So, this lets one
>     a) notice if the M_FLOOD is forged because the TTL of the underlying
>        packet does not agree.
>     b) figure out which M_FLOOD is closer.
> 
> Given:
>     We have ACP built with P2P tunnels between nodes, and on top of
>     that we run RPL to form a *unicast* routing topology.
> 
> Should a GRASP deamon send M_FLOODs to all P2P tunnels, regardless of whether
> they are active RPL routes?    I would tend to say *YES*.

In practice, I think GRASP will send to all the ACP interfaces flagged
as active in the adjacency table. But that amounts to the same thing.

> Given that, one will expect to see the same M_FLOOD from the same sender via
> multiple paths.  That's fine, and I think it's good.  But, comparing them is
> kind of meaningless, because once you find out who the sender is, the unicast
> routing takes over, and you will take the unicast direction only.
> If one hears announcements from multiple senders, then there might be
> different directions, but the TTL you see in the M_FLOOD may have NOTHING to
> do with what the unicast cost is.

True, in a general topology - the LL multicasts combined with GRASP relaying
will ammount to a spanning tree rooted at the M_FLOOD sender, but the unicast
paths will be set by RPL. There's no reason they will be congruent. They might
be. This is a good point!

   Brian