Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol

John Strassner <strazpdj@gmail.com> Thu, 12 March 2015 01:22 UTC

Return-Path: <strazpdj@gmail.com>
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 897A91A89A5 for <anima@ietfa.amsl.com>; Wed, 11 Mar 2015 18:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 NZt0Y6WgjrxU for <anima@ietfa.amsl.com>; Wed, 11 Mar 2015 18:22:34 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 837021A899B for <anima@ietf.org>; Wed, 11 Mar 2015 18:22:33 -0700 (PDT)
Received: by wesw55 with SMTP id w55so13063868wes.3 for <anima@ietf.org>; Wed, 11 Mar 2015 18:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HazN+XjJ3A2GFagnNShhDYrG7iulyj0BSYKcNb9/1yc=; b=dVY5YVOqVUo2XoqCTV7/Got1PN9cO/xfNR8xa5jkoTRSYVcW+TlIfL8TTYauIlwzxq ZnyNWFJCAXUJk/XaO3eUFRZhmdJPoRhyV2M0NyqEfEztUxsoRCFqeszde4Xbi4nSjy88 Q2KlVvcC4dbvUImZG4/CGF4KXIUSpNntpCcImYA3KhKdFMdi6V6tyeNtsnVFfdDpZuw2 bWOM60OJhT47BZPQGs2JFIIa2HT9rC6XMyVkV9FtNbMW+cL4r/iWrNY72ZibHdAhzX/Q a4Dn7WVQuDOT0Ktd9+ALlm3ceDXHckZONogoT2ur4NBkLsZZ83oPV8dxYqovBfeauaYS 5smA==
MIME-Version: 1.0
X-Received: by 10.180.126.69 with SMTP id mw5mr129399952wib.12.1426123352203; Wed, 11 Mar 2015 18:22:32 -0700 (PDT)
Received: by 10.27.85.139 with HTTP; Wed, 11 Mar 2015 18:22:32 -0700 (PDT)
In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com>
References: <5D36713D8A4E7348A7E10DF7437A4B923B059AD6@nkgeml512-mbx.china.huawei.com> <54FE67C3.9010804@gmail.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22EF05CD@xmb-rcd-x14.cisco.com>
Date: Wed, 11 Mar 2015 18:22:32 -0700
Message-ID: <CAJwYUrETOW_i4vqUWodXQxkbCqGtp_iqTyZQkQKBZx=KNbtQrw@mail.gmail.com>
From: John Strassner <strazpdj@gmail.com>
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, John Strassner <strazpdj@gmail.com>
Content-Type: multipart/alternative; boundary="e89a8f839f1bd0691105110d37bb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/8bMVdQ7D9hhho0jWm7w_e6TF2cQ>
Cc: Anima WG <anima@ietf.org>, John Strassner <John.sc.Strassner@huawei.com>, "Liubing (Leo)" <leo.liubing@huawei.com>
Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol
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, 12 Mar 2015 01:22:38 -0000

Hallo Michael,
it's been a long time. :-)

I understand, and agree, with your first point.

Regarding the second point, I understand your point about fully autonomic
nodes. In addition, I think the WG should be commended for worrying about
legacy elements and processes from the outset.

First question: could I characterize your approach as having three types of
nodes: fully autonomic, autonomically-aware, and autonomically-unaware? An
autonomically-aware node is one that fully autonomic nodes can communicate
with, and which understands (perhaps after translation) what functions are
required of it and what functions it can offer. An autonomically-unaware
node is a dumb rock (e.g., a hub).

Then, I could say that an autonomic function is either be supported
directly by a fully autonomic node, or built from a set of nodes (some of
which are not capable of performing autonomic functions).

Second question: performing an autonomic function is a set of behaviors.
What's important is the end result, not the individual behaviors. So, as
long as each individual behavior can be rigorously defined (e.g., using a
software contract, where the behavior satisfies a set of pre- and
post-conditions as well as a set of invariants), then (in theory) they
should be able to be composited together.

Thoughts?


best regards,
John



On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mbehring) <
mbehring@cisco.com> wrote:

> John,
>
> Adding to Brian/Sheng my view, there are two important points to note:
>
> 1) What you see now is just the start. In this first phase we're not
> actually standardising any autonomic service agents (as we call them), but
> we're preparing an infrastructure for such agents. Meaning, such agents can
> count on all the "mechanics" to talk to other agents: Addressing, routing,
> security, simple discovery, negotiation, etc. We call this the autonomic
> networking infrastructure, and our goal is to make this infrastructure
> "self-managing" itself, specifically, it should self-configure.
>
> This infrastructure is not complete, as you correctly point out. But all
> of the functions you mention (e.g., knowledge exchange) first of all
> require a solid communications infrastructure.
>
> In the WG charter you see the elements of the infrastructure, and a couple
> of use cases for autonomic service agents. In this first phase the
> intention is to validate the autonomic networking infrastructure with those
> use cases. See also the UCAN BoF notes, where more use cases were
> discussed. Again, we're looking at simple use cases to start with, and work
> bottom-up.
>
> 2) We are not trying to define fully autonomic nodes, but autonomic
> functions. In other words, we expect nodes to be partially managed in the
> traditional way, and some functions to be autonomic. In the future there
> may be cases of fully autonomic nodes.
>
> As we take on new use cases, we define their requirements, and address the
> delta in the autonomic networking infrastructure, bottom up. With the
> reference model we need to make sure that we're not going down a track that
> will make future use cases impossible or hard to support. This is of course
> the main challenge. Your input would be very valuable in this process.
>
> What are your thoughts?
>
> Michael
>
>
> > -----Original Message-----
> > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
> > Carpenter
> > Sent: 10 March 2015 04:41
> > To: John Strassner
> > Cc: Liubing (Leo); Anima WG; strazpdj@gmail.com
> > Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-
> > protocol
> >
> > Hi John and everybody,
> >
> > Replying to some comments received privately, on the list with
> permission:
> > On 09/03/2015 22:55, Sheng Jiang wrote:
> > > Hi, authors of draft-carpenter-anima-gdn-protocol
> > >
> > > The below are some comments from my colleague, Dr. John Strassner.
> > Although I personally think your protocol designs have the ability to
> meet
> > his requirements for knowledge exchanging among autonomic nodes, it is
> > better you could discuss directly and maybe include some
> > modification/clarification in the future version. I also encourage you to
> > discuss this in ANIMA mail list openly.
> > >
> > > Best regards,
> > >
> > > Sheng
> > >
> > >> -----Original Message-----
> > >> From: John Strassner
> > >> Sent: Friday, March 06, 2015 6:43 AM
> > >> To: Sheng Jiang; John Strassner
> > >>
> > >> Dear Sheng,
> > >>
> > >> I read the charter and am starting on the drafts.
> > >>
> > >>>> autonomics require the ability to share and exchange knowledge in
> > >>>> an interoperable fashion. I fail to see how this is even discussed
> > >>>> in ANIMA.
> > >>>
> > >>> BTW, the ability to share and exchange knowledge in an interoperable
> > >>> fashion looks like GNDP (Generic Discovery and Negotiation Protocol)
> > >>> in ANIMA. This protocol is designed to support information discovery
> > >>> and bi-direction negotiation.
> > >>
> > >> It appears that GDNP covers some, but not all, of what I am talking
> about.
> >
> > Indeed, it isn't claiming to cover everything. The idea is that draft-
> > behringer-anima-reference-model will evolve to show how things fit
> > together, which will help us to identify holes.
> >
> > >> However, the following statement from the GDNP draft is misleading,
> > >> if not just plain wrong:
> > >>
> > >> "In order to fulfil autonomy, devices that embody autonomic service
> > >> agents need to be able to discover each other, to synchronize state
> > >> with each other, and to negotiate parameters and resources directly
> > >> with each other."
> > >>
> > >> First, autonomic networks are not necessarily autonomous. Autonomy,
> > >> in its most generic form, is the ability to have the power for an
> > >> entity to govern itself. If every network element governs itself
> > >> without regard to other, higher level principles, you don't even have
> > >> a network. :-)
> >
> > Sure. That is the role for what we call "intent" which is defined in
> draft-irtf-
> > nmrg-autonomic-network-definitions but is not yet in Anima scope.
> >
> > >> Second, the three concepts mentioned in the above excerpt
> > >> (discoverability, synchronization of state, and parameter
> > >> negotiation) are necessary but clearly not sufficient to have
> > >> autonomic operation. I was talking about the ability to exchange
> > >> knowledge (e.g., all or part of an information model) between
> > >> entities. It doesn't appear that this is covered in ANIMA yet, though
> I
> > haven't read all of the materials.
> >
> > My personal view is that this is going to be resolved topic by topic.
> > In GDNP-speak that means that it will be resolved by individual Objective
> > definitions, and GDNP will just act as a neutral carrier. (You can quite
> fairly
> > argue that this means we are ducking the problem for now.) Another way to
> > say this is that each type of autonomous service agent will solve this
> > problem for its own target parameters.
> >
> > Now, again IMHO, this is why we state in GDNP that the format of the
> value
> > of an objective "...might be inherited from an existing management or
> > configuration protocol, the objective option acting as a carrier for that
> > format.  The data structure might be defined in a formal language, but
> that
> > is a matter for the specifications of individual objectives.  There are
> many
> > candidates, according to the context, such as ABNF, RBNF, XML Schema,
> > possibly YANG, etc.  The GDNP protocol itself is agnostic on these
> > questions."
> >
> > My expectation is that some objectives will need a formal information
> > model and that others won't, and that there's no reason we couldn't
> inherit
> > existing IMs when they are relevant. But that whole question is also out
> of
> > charter scope for now. As you know better than most people, John,
> defining
> > an IM can become a very laborious business and for now we want to get
> > started on simple cases that don't need it.
> >
> > >> If you cannot exchange knowledge, you will never be autonomic in the
> > >> computer science sense.
> >
> > You will find very similar words in draft-irtf-nmrg-an-gap-analysis.
> >
> > <snip>
> >
> > Regards
> >     Brian
> >
> > >> regards,
> > >> John
> > >>
> > >> Dr. John Strassner, Ph.D.
> > >> CTO, Software Laboratory, CRD
> > >>
> > >>
> > >> Futurewei Technologies
> > >> US R&D Center
> > >> 2330 Central Expressway
> > >> Building A, office A2-2143
> > >> Santa Clara, California   95050
> > >>  Office:  +1.408.330.4923
> > >>  Email:   john.sc.strassner@huawei.com
> > >>
> > >>
> > >> Best regards,
> > >>
> > >> Sheng
> >
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
>



-- 
regards,
John