Toerless Eckert <tte@cs.fau.de> Tue, 14 May 2024 15:57 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E9D2CC180B67 for <anima@ietfa.amsl.com>; Tue, 14 May 2024 08:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.648
X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WkOwwJ02I-ZY for <anima@ietfa.amsl.com>; Tue, 14 May 2024 08:57:33 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A95DC16943E for <anima@ietf.org>; Tue, 14 May 2024 08:57:32 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4Vf1Fz0bSdznkM9; Tue, 14 May 2024 17:57:27 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4Vf1Fy6qVszknfr; Tue, 14 May 2024 17:57:26 +0200 (CEST)
Date: Tue, 14 May 2024 17:57:26 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ZkOJ5k01r9tb3haI@faui48e.informatik.uni-erlangen.de>
References: <869240ad-716a-4cde-9caa-b108e02bd5a3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <869240ad-716a-4cde-9caa-b108e02bd5a3@gmail.com>
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: anima@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: GRASP, NETCONF and YANG
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/12eQMooL5xflLxaQJr_9CuiUvFM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>


Well, we do have the answer that we worked out in our first batch of RFCs,
which is that the ANI with BRSKI, ACP and GRASP provides not only the
secure autonomously established communications fabrics for ASA to
talk to each other, but also that "SDN controller/orchestrars" can use
the ANI to monitor/provision the network reliably and automatically
secured. That monitoring/provisioning would IMHO simply leverage all
existing YANG models and one of the various transports - netconf/ssh/tls
and/or any alternative to that.

What i think is the small incompleteness to that story are the bits and
pieces that draft-eckert-anima-services-dns-autoconfig and draft-eckert-anima-grasp-dnssd
provide. Namely that all ANI devices would discover and autoconfigure themselves
for those components that otherwise can not easily be provisioned with a
chicken&egg problem: time (NTP), authentication (radius/diameter), logging - to
name the most important ones.

Now, when it comes to: 

"If we would start to define useful decentralised ASA that operate without
 a central SDN component - how would the GRASP protocols between them best
 look like ?"

I think that's wide open, because there is not much established tradition for
such decentralized ASA and their communication patterns. It is IMHO after
IETF119 ANIMA meeting not even clear if there is an overwhelming desire to
make such "east-west" communications (as i like to call it) utilize YANG
to model the data - as opposed to CDDL. Check out the recording of the ANIMA
session, i think we had a very good discussion on that topic.

Is my answer missing an aspect you wanted to raise ?


On Fri, May 03, 2024 at 07:51:36AM +1200, Brian E Carpenter wrote:
> Seeing Toerless's comments on draft-ietf-anima-network-service-auto-deployment reminded me of what I think is the largest unsolved issue in the GRASP model. How does GRASP interwork with the NETCONF/YANG approach to network management?
> I don't really know how to answer this, but if ANIMA doesn't answer it soon, we will not see much progress. The question is a bit similar to how GRASP interworks with DNS-SD, but there we have a proposal already.
> It seems time for ANIMA to focus on that, as the current batch of BRSKI-related work is getting mature.
> Regards
>    Brian Carpenter
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima