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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 23 September 2017 19:43 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 10D6A132C2A; Sat, 23 Sep 2017 12:43:10 -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, SPF_PASS=-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 oS6WgiMCrM_p; Sat, 23 Sep 2017 12:43:09 -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 CDE1F13295C; Sat, 23 Sep 2017 12:43:08 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EA612009E; Sat, 23 Sep 2017 15:47:56 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D7C27806CE; Sat, 23 Sep 2017 15:43:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: Toerless Eckert <tte@cs.fau.de>, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org
In-Reply-To: <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com>
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>
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: Sat, 23 Sep 2017 15:43:07 -0400
Message-ID: <13482.1506195787@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/ssxQyXUwiyn8DnMnEyEqpIewdx8>
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 19:43:10 -0000

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*.

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.

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