IETF Logo Mail Archive

Re: [Anima] Multicast in the ACP?

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 23 April 2015 14:42 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4421A914D for <anima@ietfa.amsl.com>; Thu, 23 Apr 2015 07:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 NGZ2hhQGvmdJ for <anima@ietfa.amsl.com>; Thu, 23 Apr 2015 07:42:02 -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 929E11A9169 for <anima@ietf.org>; Thu, 23 Apr 2015 07:41:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B8B2203B9 for <anima@ietf.org>; Thu, 23 Apr 2015 10:53:19 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 5141563B86; Thu, 23 Apr 2015 10:41:43 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3C14763784 for <anima@ietf.org>; Thu, 23 Apr 2015 10:41:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
In-Reply-To: <55382705.3060605@gmail.com>
References: <5536EE40.30705@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22F5FE63@xmb-rcd-x14.cisco.com> <5537FFEF.9020308@gmail.com> <10795.1429737994@sandelman.ca> <55382705.3060605@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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-sha1"; protocol="application/pgp-signature"
Date: Thu, 23 Apr 2015 10:41:43 -0400
Message-ID: <15430.1429800103@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/aB9R1HLneyrQzq7ZLEu4XvN8mMg>
Subject: Re: [Anima] Multicast in the ACP?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 23 Apr 2015 14:42:05 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> >> The ACP as described in
    >> draft-behringer-anima-autonomic-control-plane >> is based on a hop by
    >> hop tunnel infrastructure. So far those tunnels >> are all point to
    >> point. I guess you can send a link-local multicast >> packet through
    >> such a tunnel, and it would automatically benefit from >> the security
    >> of that tunnel. But of course there is only one other >> node on that
    >> "link".
    >>
    >> > Right, so we would have to specify a "replicast", where the sender >
    >> copies the message to each ACP tunnel. That seems like a lot of >
    >> overhead.
    >>
    >> http://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/
    >> describes a way to do multicast across that collection of
    >> links... that is if we can ever get it through the IESG.

    > Interesting. That looks like overkill for ACPs that run over
    > non-constrained networks, but it suggests to me that we need a modular
    > approach, so that it could be used in networks that call for it.

Given that the ACP's forwarding plane might be implemented in the control
plane processor, the mismatch between link speeds and available processing
power might cause one to conclude that while the network isn't constrained,
the router is!

I would consider, for instance, implementing the ACP as a user-space
virtual-machine in the control plane processor.  User-Mode-Linux can be
compiled to run on a bunch of POSIX platforms, although Linux and FreeBSD are
the ones most often tested.

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

v2.23.0 | Report a Bug | By Email