Re: [Anima] GRASP objective details for registrar

Toerless Eckert <tte@cs.fau.de> Sat, 23 September 2017 07:00 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 77D86132F30; Sat, 23 Sep 2017 00:00:04 -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 QBPumZep-lUG; Sat, 23 Sep 2017 00:00:01 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673EB126DFE; Sat, 23 Sep 2017 00:00:01 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A843258C4D4; Sat, 23 Sep 2017 08:59:56 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8F309B0CC88; Sat, 23 Sep 2017 08:59:56 +0200 (CEST)
Date: Sat, 23 Sep 2017 08:59:56 +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: <20170923065956.GC32014@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> <20170920170726.GA18746@faui40p.informatik.uni-erlangen.de> <b392cf90-ffcf-d053-0a01-31b510277077@gmail.com> <20170922230153.GA32014@faui40p.informatik.uni-erlangen.de> <f81e352b-a6af-adce-d60f-aef7c55748c2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f81e352b-a6af-adce-d60f-aef7c55748c2@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wsUYTWFqpvQdRaGGmT0XX50BW1c>
Subject: Re: [Anima] GRASP objective details for registrar
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: Sat, 23 Sep 2017 07:00:04 -0000

On Sat, Sep 23, 2017 at 03:31:44PM +1200, Brian E Carpenter wrote:
> Well, settle the name between the ACP and BRSKI authors

Sure

> >    AFAIK, for extensible and optionality, we need to use maps instead of
> >    arrays in CBOR ({} instead of [] in CDDL).
> 
> I would argue that in many cases of simple objectives this would be a mistake.
> It's a conceptual and practical complication for the ASA writer, unless a
> map (and probably JSON) is already "native" for the problem at hand.
> 
> I am absolutely not against maps for cases where they are the natural
> solution. But if the objective happens to be a simple value, why?

As soon as you want to include discovery parameters such as the sender-ttl
or the dns SRV style weight/prio the map for example.

> All that IANA registration really requires is a name and a reference document,
> so this comes at the RFC stage.

Sure. Its more about feeling safe enough that the idea is right
before asking IANA to maintain a registry. Easier done when there
is more time to revisit the decision.

> >     objective-value = {
> >         std: {
> > 	    sender-ttl: 255,
> > 	    service: { "brski-join" },
> > 	    service: { "est-renew" },
> >         }
> >     }
> 
> Please work with Carsten to get that right, all I can tell
> you is that the tool reports a parse error.

What's the CBOR/CDDL tool you're using, i'll try it myelf first
before yelling for help ;-)

> All the same, DNS-SD is Unicode, so you can in theory use anything for the
> Instance name (human readable part). I agree that the DNS-SD Service name
> is case-folded ASCII. 

I was just trying to follow what seems to be common practice and
minimize the new wheels we're inventing by re--using existing wheels.

> One more comment below...

> > I always think of objectives as services, which would make
> > "XXX_registrar" the right word - it does not prescribe what
> > to do with the service: ignore, consume(join), buy-stock, resell, attack...
> 
> Well, these objectives and probably many associated with a NOC are
> services. But if the ASA is handling some sort of optimisation
> or resource management, the objective really is a parameter.
> It might be a real number or more complicated, but it's not
> a service. Really a GRASP objective is just a container.

Right. Which is why the objective-value structure proposal also hass
the whole "service" element as an optional subelement only.

> > "objective" to me always implies an action, which i think is why
> > "XXX_join_registrar" was preferred choosen ?
> 
> I just tried to copy the terminology in BRSKI.

Yes, pretty sure "join_registrar" was some BRSKI collaborator idea.

> > When we, as i suggest have the same registrar objective used for both BRSKI
> > and EST, we have at least two actions: BRKI-join and EST-renew. 
> 
> Sure, but you can expand the semantics by adding a field to the
> objective-value if you want.

Thats what the objective-value proposal is doing. 

> > concerned about the word objective - i am never sure if i will not run
> > into a service where there is really more than
> 
> Maybe you won't in the NOC space, but if we're optimising usage of 
> radio links in 3D space maybe you will find complex numbers in
> the control loop, and therefore in the objective values.

I hope i did mention initialy in my email that the proposed structure
for objetive-value was primarily for flooded objectives and just trying
to establish a structure that allows to define cross-objective shared
eleemnts - without limiting the objective specific ones. 

Cheers
    Toerless

>     Brian
> 
> > 
> >>  
> >>> 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
> >>
> >> I would go for this:
> >>
> >> objective-value = [ sender-ttl, method-list, *[ future-extensions ] ]
> >> method-list = [ +method ]
> >> method = "BRSKI-TLS" / "EST-TLS"
> >> sender-ttl = 0..255
> >> future-extensions = any
> >>
> >> The "+" prefix means 1 or more in CDDL and "*" means zero or more.
> >> The commas in lists like [+method] are implied. (I checked
> >> this fragment with the CDDL tool.)
> >>
> >> I used strings for the method for simplicity; if you want to save a few
> >> bytes you could use symbols but then they have to be assigned values like
> >> BRSKI-TLS = 0
> >> EST-TLS = 1
> >> and you end up with another IANA registry in your life.
> >>
> >> Regards
> >>     Brian
> >>  
> >>>    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
> >>>
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> Anima@ietf.org
> >> https://www.ietf.org/mailman/listinfo/anima
> > 

-- 
---
tte@cs.fau.de