[Anima] GRASP objective details for registrar (was: Re: ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt])

Toerless Eckert <tte@cs.fau.de> Fri, 22 September 2017 23:02 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 620FB13303F; Fri, 22 Sep 2017 16:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RNWT7JVOsnKF; Fri, 22 Sep 2017 16:02:02 -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 A0F6A132705; Fri, 22 Sep 2017 16:01:57 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de []) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A0C1D58C4D2; Sat, 23 Sep 2017 01:01:53 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 873A8B0CC7D; Sat, 23 Sep 2017 01:01:53 +0200 (CEST)
Date: Sat, 23 Sep 2017 01:01:53 +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: <20170922230153.GA32014@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b392cf90-ffcf-d053-0a01-31b510277077@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/RoJBbRfE0cWWDjEECNb8ZNiglFw>
Subject: [Anima] GRASP objective details for registrar (was: Re: 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: Fri, 22 Sep 2017 23:02:12 -0000

Some opinions/suggestions:

a) Name of objective should be "ACP_registrar". The registrar supports multiple
   services, eg: brski-join, est-renewal, and if we had ducklings also est-enroll.

   ACP_*, because it's not AN_* unless we could guarantee we always have intent
    (which we don't), and not ANI_* because we also do not necessarily always have
   BRSKI (but eg: Netconf Zero Touch + ACP).

   But this is terminology. I have an option, but i am happy getting anything that works.
   ultimately i do not care about this part.

b) More importantliy, elements in objective-value should be standardizeable, reuseable, 
   extensible and optional.
   AFAIK, for extensible and optionality, we need to use maps instead of
   arrays in CBOR ({} instead of [] in CDDL).

   For standardizeable, we should define the structure to include standards elements

c) The IMHO most easy and useful standardized options are the ones that
   a) allow for objective services to be aligned with DNS-SD so that
   we have a superset of the service-selection facilities of DNS-SD and
   if desired the same name space.

d) So, for the ACP draft, i think i would want to write down the most simple
   subset of the intended syntax for objective-values and not describe the
   background and also not yet start to worry about IANA registration,
   because that would make sense only once we agree on the need of extensibility.
   Worst case, the following syntax would not be extended in future, then
   we just made it a bit more generic than necessary:

    objective-value = {
        std: {
	    sender-ttl: 255,
	    service: { "brski-join" },
	    service: { "est-renew" },

e) In a separate small document we could detail those GRASP aspects in more detail,
   this doc could update ACP RFC, so we can take more time without holding up ACP RFC.
   And we could then also ask for the IANA registries when we feel that there really
   is enough future add-ons to justify the registry.

   Here is my current definition i would use (aka superset of avove example):

  objective-value  = { *parameter }     ; map of parameters to be extensible and
                                        ; all prameters can be optional.

  parameter       /= std: { *std-param } ; create subset of parameters standardized
                                         ; the std-param names would be an IANA registry.

  ; parameter     /= ...                ; Any parameter specific to an objective.

  std-param       /= sender-ttl: 1..255 ; value of ttl field of flood-message
                                        ; as set by sender. Upon receipt, 
			                ; (sender-ttl - ttl) is the distance of 
			                ; the receiver from the sender.

  std-param       /= service: {         ; Services supported by objective.
                         service-name,  ; Name must be registered according to RFC6335
			 *service-param ; would therefore also useable in RFC2782
		     }                  ; For newly registered service names, do not
		                        ; allocate/register protocol/port numbers. These
					; are learned via other GRASP message elements
  service-name     = tstr
  service-param   /= selection-param
  selection-param /= priority: 0..65535 ; Same semantic as rfc2782. Default = 0
  selection-param /= weight:   0..65535 ; Same semantic as rfc2782. Default = 0

   Aka: pretty much allowing 1:1 mapping of the DNS-SD SRV parameters we need
   (service-name, priority, weight) to GRASP "services". And make "services"
   a sub-element of an objective. And RFC6335 also explains why not to use
   capital letters in "est-renew", "brski-join" (uncommon to use capital letters
   in RFC6335).

   As you see, i did not make sender-ttl part of service, so we may use sender-ttl
   even if some objective does not want a "service:" parameter.

   We may need to add locator options to service-params, thats and example of
   how this is yet incomplete. With just one service indicated the locator
   element of the existing GRASP is sufficient.


On Thu, Sep 21, 2017 at 02:51:48PM +1200, Brian E Carpenter wrote:
> Works for me. Just decide whether you want AN_registrar or AN_join_registrar.

a) OK, let me obsess about terminology a bit:

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...

"objective" to me always implies an action, which i think is why
"XXX_join_registrar" was preferred choosen ?

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. Logically
we could also have EST-enroll, but that one is a no-no (eg: ducking enrollment
without voucher).

So we could call what we named "method" also "action" or "service" and
call them BRSKI-join and EST-renew. But those words do then not imply the
transport stack to use (TLS).

I would like XXX = ACP because XXX = AN seems to imply the network is
autonomic, which i think by definition it is not unless we have intent ;-P.
XXX = ANI would also be wrong if for example we combine ACP with Netconf
Zero Touch and only offer EST-renew but not BRSKI-enroll.

b) I would like the parameters of an objective reuseable, extensible and
optional when not needed. I think that we need to use a map instead of
an array in CBOR to get extensibility and optionality (CDDL 

concerned about the word objective - i am never sure if i will not run
into a service where there is really more than

> > 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
> 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