Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 11 July 2016 12:15 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 71D0B12D134 for <anima@ietfa.amsl.com>; Mon, 11 Jul 2016 05:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 Xo11KYd15uPd for <anima@ietfa.amsl.com>; Mon, 11 Jul 2016 05:15:40 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 CF47A1288B8 for <anima@ietf.org>; Mon, 11 Jul 2016 05:15:39 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id q132so70872387lfe.3 for <anima@ietf.org>; Mon, 11 Jul 2016 05:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OZ1ODu69eeFrLRXuFS1Qv1IbN1T/1AtTS3bbdxDn+rI=; b=KQQtPD8eZAqEdGIhF8eCIXo6t4LsIri3q/L8tqh8ZRFVbX5jvPyQgXb7c6ttwZvH8r Ea+55rhKblKa5VcdTqyObU3ddFiUYAvug287BybXNDG6hXpZ2kgIx2LMGbhaDApnqUAl x9lAccysgO0eJl5XUxhsG3QW71vMsfKm+jrmq8c2MOd2A+R29rhmYOLPZ2+XV6zLvKZC qwfQfllTVLZzj3Gvg5N1Hm9U/V6ue7kvUYfOl4204qSZJl216Ty1ZvRJRhFbNMmp8N5q aDjMLtVYVBKbDQcNq3jQhqqZQKHX6k3AxLUzjUtX6BYTglSahDEsuDw9v59PIGGD6Za5 1xtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=OZ1ODu69eeFrLRXuFS1Qv1IbN1T/1AtTS3bbdxDn+rI=; b=UVCOByQvCp7V1j+8BBsQ+0zyOBdTjRdkvkrFr5tPCW0rZzTxZHpvhcj2eOjVi68wzO 2ey0ZLZ8NS4g0gdpIP9vfWYpzknqdgXYtQNQyP4ywAV9Rsim9P29Va7VBPNemSB9mgeP Lc4dmMKtkBKrvvZzqr+QwEhdBJkav5Z8Zy+nAITT9tOonWD7i93dVkxdYzdvc5Y0mda8 HeDjpW7eD9XC9Qf162QAjgA2oKQoAwVHTqepx+gtMm/9+jNlM01GHyK90UjquOPANRCr MCM/KTYwSfIt+ftC8Km82IhKIfTytg+24uK2b9eH6l8v9Svk6ixwjzHMwiY0OqD1eeLV BZ7A==
X-Gm-Message-State: ALyK8tKU6KQf5hbffNNp7KaOh8oXHvUWY27ZS/AlWGD73Y0cbNGm6Ypm8cOAwnc3FkvhmA==
X-Received: by 10.25.201.85 with SMTP id z82mr2546741lff.104.1468239337962; Mon, 11 Jul 2016 05:15:37 -0700 (PDT)
Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id o184sm4072349lfb.19.2016.07.11.05.15.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 05:15:37 -0700 (PDT)
To: "Michael Behringer (mbehring)" <mbehring@cisco.com>, Laurent Ciavaglia <Laurent.Ciavaglia@nokia-bell-labs.com>, anima <anima@ietf.org>
References: <20160708153949.32209.45567.idtracker@ietfa.amsl.com> <f71bea03-d9a0-8178-cd3f-91671a66551c@nokia-bell-labs.com> <1fe314ad-d22f-1291-7e85-4e51ccd328a2@gmail.com> <c5cb4a64cc924448a215c263888888e2@XCH-RCD-006.cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <54f47cc8-bd8b-3783-274a-86e98d9e49ea@gmail.com>
Date: Tue, 12 Jul 2016 00:15:36 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <c5cb4a64cc924448a215c263888888e2@XCH-RCD-006.cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/m9xYbCU_AP3iGeS264Bblega8F4>
Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 11 Jul 2016 12:15:42 -0000

On 11/07/2016 19:22, Michael Behringer (mbehring) wrote:
>> -----Original Message-----
>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E
>> Carpenter
>> Sent: 09 July 2016 12:39
>> To: Laurent Ciavaglia <Laurent.Ciavaglia@nokia-bell-labs.com>; anima
>> <anima@ietf.org>
>> Subject: Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-
>> intent-04.txt
>>
>> Hi,
>>
>> Thanks for this. One point raises some questions in my mind:
>>
>>> 5.   Intent splitting (on each node): Intent is split into sections,
>>> one for the ANI itself, others for specific Autonomic Functions.
>>> ASAs are notified if there is new Intent for them.  Some intent
>>> sections may not apply to a particular node.  Now each component
>>> of a node (ANI, all ASAs) know their respective Intent.
>>
>> I am wondering why, in this case, Intent would be broadcasted in a single
>> operation as a single file. Why wouldn't we simply send out each section
>> separately?
> 
> Simplicity. We've discussed many ways of making Intent distribution more granular, optimised, etc. My argument was and is: Let's start simple, and see whether we actually need to make it more granular, optimised, etc. If Intent is really a high level policy, it will change very infrequently, so I think optimisations are not required. Having said this, we should have a "plan b" in case we find later that the simple method isn't good enough.

I'm all for simplicity. However, it might be that sending the sections separately
would actually be simpler. I think we don't know yet.

>> Also, how is the relevance for each ASA known? 
> 
> My proposal: Intent comes in sections; those sections are labelled with the name of the ASA / autonomic function they belong to. Also here, there are many ways to do this, it's a simple proposal which could be optimised in many ways. 
> 
>> And is that the correct
>> granularity of the section? Maybe the granularity should be individual
>> objectives, or certain groups of objectives? I think this needs more
>> discussion.
> 
> On this one I agree!! We should have more discussions on that. Your point from the other mail, that we should try implementing some ASAs would help understand this better.

Yes. There's been an assumption, I think, that one "autonomic function" == one ASA.
We need to be clear if that is an axiom, and we need to think about how ASAs are
named, and if those names need to be registered somehow.

> But: I suggest we make things more complicated only if we really can see why the proposed approach wouldn't work.

Agreed. As far as I can see, if we naively assume that we use GRASP to distribute Intent,
we can flood Intent as long as it fits in one packet; if that doesn't apply, we can
synchronize it via GRASP/TCP. That seems OK for now. Since Intent is supposed to change
rarely, we don't need to optimise performance.

Regards
    Brian

> 
> Michael
> 
> 
>>
>> Regards
>>    Brian
>>
>> On 09/07/2016 03:45, Laurent Ciavaglia wrote:
>>> Dear ANIMA WG,
>>>
>>> FYI: a new version of the I-D has been posted.
>>>
>>> The main update is the addition of a section on Intent Life Cycle
>>> based on the initial text provided by Michael Behringer
>> (https://mailarchive.ietf.org/arch/msg/anima/rk2CgO62nmXFuKOBX-
>> Gtb5v0p5E).
>>> Michael is now also co-author of the I-D.
>>>
>>> *We've asked the ANIMA WG chairs for a slot at IETF96/Berlin to
>>> present the updates on this draft and report on the discussion on
>>> Intent and way forward.** **Your comments are thus highly welcome
>>> before the meet**ing**.*
>>>
>>> Best regards, Laurent.
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject:     New Version Notification for draft-du-anima-an-intent-04.txt
>>> Date:     Fri, 8 Jul 2016 08:39:49 -0700
>>> From:     internet-drafts@ietf.org
>>> To:     Laurent Ciavaglia <laurent.ciavaglia@alcatel-lucent.com>, Jeferson
>> Campos Nobre <jcnobre@inf.ufrgs.br>, Michael
>>> Behringer <mbehring@cisco.com>, Sheng Jiang
>> <jiangsheng@huawei.com>,
>>> Zongpeng Du <duzongpeng@huawei.com>, Michael H. Behringer
>>> <mbehring@cisco.com>, Laurent Ciavaglia
>>> <Laurent.Ciavaglia@alcatel-lucent.com>
>>>
>>>
>>>
>>> A new version of I-D, draft-du-anima-an-intent-04.txt has been
>>> successfully submitted by Laurent Ciavaglia and posted to the IETF
>>> repository.
>>>
>>> Name:        draft-du-anima-an-intent
>>> Revision:    04
>>> Title:        ANIMA Intent Policy and Format
>>> Document date:    2016-07-08
>>> Group:        Individual Submission
>>> Pages:        13
>>> URL:            https://www.ietf.org/internet-drafts/draft-du-anima-an-intent-
>> 04.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-du-anima-an-intent/
>>> Htmlized:       https://tools.ietf.org/html/draft-du-anima-an-intent-04
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-du-anima-an-intent-04
>>>
>>> Abstract:
>>>    One of the goals of autonomic networking is to simplify the
>>>    management of networks by human operators.  Intent Based Networking
>>>    (IBN) is a possible approach to realize this goal.  With IBN, the
>>>    operator indicates to the network what to do (i.e. her intent) and
>>>    not how to do it.  In the field of Policy Based Management (PBM), the
>>>    concept of intent is called a declarative policy.  This document
>>>    proposes a refinement of the intent concept initially defined in
>>>    [RFC7575] for autonomic networks by providing a more complete
>>>    definition, a life-cycle, some use cases and a tentative format of
>>>    the ANIMA Intent Policy.
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>