Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15

Rene Struik <rstruik.ext@gmail.com> Thu, 30 October 2014 03:50 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED071ACFFB; Wed, 29 Oct 2014 20:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 AIsQ5bnqdu-D; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D0F1ACFFA; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id rd18so4263350iec.7 for <multiple recipients>; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=H7iOSqW9Ri32Sl+HXHj8W1QC4ZHZrv/o12X0UQkGMXg=; b=oVY2lvsk7arkcFHl4/rKzPsFQYdGaqpDtFcFQh8guqQ83/eZHbrWlFfCeQasrsdpt1 +UYxZ+3fITdZZBz8aXkajenRDig+NmSDmqyZaWiSV7W7rjH4Nqi2Rc/qrO4XNnTC2qRI FuNnZb+sfzVUmq8pqEeZoKhdot2NaoOu2HNqTc64WpVXFjIm0vXuZHfmV1n3iJnfdIvl SY67yHZdkA+lPTtgFBlr0fVOW4lBVf5SsXQu25QyKdCYTxjxqSuayDGklNigBBIUYDMh T7+mGbDjk+zzwgrFJpByQpavIQEL4vHza5/K7VdbzEcHrqwYArX5O3lJ8J7a1fcWoPcT iC/w==
X-Received: by 10.107.148.200 with SMTP id w191mr16413847iod.28.1414641051100; Wed, 29 Oct 2014 20:50:51 -0700 (PDT)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id qp8sm1250497igb.15.2014.10.29.20.50.50 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 20:50:50 -0700 (PDT)
Message-ID: <5451B594.8090305@gmail.com>
Date: Wed, 29 Oct 2014 23:50:44 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <544FF8FC.5090103@cisco.com> <54500C8F.5030104@gmail.com> <54501D28.4090908@gmail.com>
In-Reply-To: <54501D28.4090908@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/UkyRs7L1ITgxc9BOIVR78_ib4LE
Cc: Benoit Claise <bclaise@cisco.com>, homenet <homenet@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Oct 2014 03:50:54 -0000

Hi Brian:

It is very puzzling to me to see essential deployments that would be a 
test case on viability of the concept of semi-automatic management (in 
casu: constrained networks and devices) being removed from the charter. 
I have not seen any technical justification for ruling this out of order 
(nor do I know who decides on this - consensus?).

If one emphasizes so much the "professionally managed" aspect, this 
seems to suggest that whatever "solution" Anima (or, perhaps, simply the 
co-authors of the three anima drafts mentioned in the draft charter?) 
have in mind may not meet or closely approximate the whole idea of 
"autonous" operation (at least, as I understand this after reading all 
drafts referred to in the draft charter and producing 15 pages of 
comments on this).

I, for one, think we can minimize these differences and define an 
architecture and a set of protocols that mostly only differ in policy 
and configuration settings for "professionally managed" and "highly 
constrained devices and networks". I think I have made this point in my 
extensive comments.

I am happy to make this concrete once the group meets during IETF-91, 
but certainly already declaring things out of order without accompanying 
technical discussion and analysis, effectively stymies this.

During IETF-91, I think we need to spend much more time on discussing 
draft-irtf-nmrg-an-gap-analysis and 
draft-irtf-nmrg-autonomic-network-definitions-04, since improving those 
seem to attack the festering chartering problems at the heart. I would 
happily volunteer elaborating on this during the two Anima meeting slots.

Best regards, Rene

On 10/28/2014 6:48 PM, Brian E Carpenter wrote:
> On 29/10/2014 10:37, Rene Struik wrote:
>> Hi Benoit:
>>
>> -1 on you suggestion #1.
>>
>> I do not think suggesting "constrained networks and devices" to be
>> suddenly out of scope helps: it is one of the main areas where
>> semi-automatic management is imperative.
> Rene has a point. My +1 was with the idea of limiting the initially
> worked-out use cases, and avoiding any direct interference with
> progress in homenet. But understanding the requirements for
> constrained networks is desirable. What I don't know is whether
> those requirements can in fact be met by the same infrastructure
> components that we need for "professionally managed" networks.
> There may simply not be enough overlap between "nimble and
> heterogeneous" and "managed and homogeneous."
>
>     Brian
>
> If one has a bootstrapping
>> solution and configuration negotiation/synchronization protocol that is
>> not useful in constrained settings, what is the point? In my mind, it
>> seems much more prudent to design schemes with constrained networks and
>> devices and failure recovery models that apply there (configuration
>> mismatch due to sleepy devices, malfunctioning data store, etc.), where
>> these would then obviously also fit the less constrained,
>> "professionally managed" networks. Design for the"nimble", so that both
>> "nimble" and "fatter" networks can use this.
>>
>> This also has the advantage that one is forced to think in terms of many
>> potential actors, rather than a few ones, which helps in viewing
>> solutions in terms of heterogeneous rather than homogeneous deployment
>> models.
>>
>> I have done all my reviews of nmrg drafts
>> (http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
>> constrained networks and devices in mind. It would be a shame if one
>> would now narrow down the focus and rule this (future almost ubiquitous)
>> deployment category out of scope.
>>
>> Or, is this a political ploy, so as to avoid a turf war with homenet
>> people?
>>
>> If that is the case, it would be much more prudent to have another BoF
>> to iron out some of these issues. {This may be prudent for reasons I
>> already indicated in the same #00327 message as well - I will  not
>> repeat those arguments here.}
>>
>> Best regards, Rene
>>
>> On 10/28/2014 4:13 PM, Benoit Claise wrote:
>>> Dear all,
>>>
>>> [sorry for double-posting, but we need the specific feedback from the
>>> HOMENET community]
>>>
>>> 1. scope
>>> I finished reading the ANIMA mailing list and, based on the feedback,
>>> Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
>>> specific reusable infrastructure components that support autonomic
>>> interactions between devices" (quoting the charter)
>>>
>>> The charter currently mentions:
>>>      The ANIMA working group will initially focus on enterprise, ISP
>>> networks and IoT.
>>>
>>> Multiple tracks were discussed on the mailing list.
>>>      * keep enterprise, ISP networks and IoT
>>>      * focus on enterprise and ISP networks
>>>      * everything, but the initial focus is enterprise and carrier?
>>>      * professionally-managed networks
>>>
>>> It seems to us that "professionally-managed networks" is what ANIMA is
>>> after. And it's potentially a distraction to try to segment the scope
>>> based on enterprise, ISP, homenet, or IoT. What is IoT after all?
>>>
>>> OLD:     The ANIMA working group will initially focus on enterprise,
>>> ISP networks and IoT.
>>> NEW:    The ANIMA working group focuses on professionally-managed
>>> networks.
>>>
>>> Does it sound about right?
>>>
>>> 2. Overlap with HOMENET
>>> This distinction in point 1 might help regarding the potential overlap
>>> of the solution for distributed IPv6 prefix management.
>>> Btw, the new charter has been adapted:
>>> OLD:  A solution for distributed IPv6 prefix management within a network.
>>> NEW: the solution for distributed IPv6 prefix management within a
>>> large-scale network
>>>
>>> Also, The HOMENET collaboration has been stressed in the charter.
>>>
>>> 3. Others
>>> I believe I took care of the others changes proposed on the mailing.
>>> If this is not the case, let me know.
>>> At this point in time, please provide concrete change to the charter
>>> text if some issues persist.
>>> Charter v15 has just been posted, and you can review the detailed
>>> changes at
>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
>>>
>>>
>>>
>>> 4. Security Advisor.
>>> I have requested one for ANIMA to the security ADs.
>>>
>>> Regards, Benoit
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363