Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

Toerless Eckert <tte@cs.fau.de> Wed, 20 September 2017 17:07 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65C133020; Wed, 20 Sep 2017 10:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 p6Ezw0RF6_in; Wed, 20 Sep 2017 10:07:30 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81962126D0C; Wed, 20 Sep 2017 10:07:30 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D2C1058C4FA; Wed, 20 Sep 2017 19:07:26 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id BA590B0CC3A; Wed, 20 Sep 2017 19:07:26 +0200 (CEST)
Date: Wed, 20 Sep 2017 19:07:26 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org
Message-ID: <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de>
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com> <20170918060429.GC31832@faui40p.informatik.uni-erlangen.de> <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7e70c270-6cf6-58b9-2ce4-d811f9cd1c87@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/-zD6vJVXDimspU-Wwwqb11tIb4g>
Subject: Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 20 Sep 2017 17:07:34 -0000

Thanks, Brian

a) i will fix the ABNF with next update (for Shengs review).

b) Given the order of likely last calls, i will suggest in the bootstrap meeting that we
   define the AN_Registrar objective authoritatively in ACP and BRSKI adds to it the
   "BRSKI" method. BRSKI already should have no issue having ACP as normative reference.
   Lets see how that discussion goes.

c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the
   objective-value structure to include the TTL and method, eg: fixup the following:

> >   objective-value = [ sender-ttl, method-list [, future-extensions]* ]
> >   method-list = [ method ]*1
> >   methd = BRSKI-TLS | EST-TLS | ...
> >   sender-ttl = NUM

   If we do not get further feedback from the WG supporting my simple TTL=255 approach,
   i would rather go with this structure approach, so that we can let the TTL disussion
   take its natural course (figure out it should be 255 over 10 years ;-P). Primarily,
   because i like the idea to show off a bit the flexiblity of GRASP for the objective
   value being a structure. ANd because it would be a good reference for further objectives
   where we want to discover/select closest instance (and we didn't include this into the
   GRASP document proper).

Cheers
    Toerless

> >   (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea)
> 
> Not only do I get the idea, I tested it out many months ago; actually after the
> discussions in Berlin, I think. In my Pythonic world it was very easy, but it is
> indeed a bit more complicated than the 255-N method.
> 
> > 
> > That way, the recipient can compare sender-ttl with the TTL of the received objective
> > and threeby figue out which one is closest.
> > 
> > I fine either way. I just tried to go for the most simple, logical option.
> 
> Right, so the question for the WG (are you all listening?) is whether we
> want to defend the value of the loop count in limiting propagation of multicast
> messages. (Remember that it has another role in negotiation sessions, where
> it really is a loop-prevention counter.)
> 
> I will note that in testing on looped topologies I have seen looped multicasts
> dropped because of the session ID; theoretically that is sufficient, and the
> loop count is logically redundant.
> 
> Otherwise, me happy.
> 
> Thanks again for all the work,
> 
>     Brian