From nobody Thu Jun 1 05:58:24 2017 Return-Path: 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 C5F42127977; Thu, 1 Jun 2017 05:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.624 X-Spam-Level: X-Spam-Status: No, score=-12.624 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 38hZ88QRYZph; Thu, 1 Jun 2017 05:58:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF33129BCE; Thu, 1 Jun 2017 05:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3805; q=dns/txt; s=iport; t=1496321901; x=1497531501; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=H/YpkV5ToaLVgmzfLl18yeN3YVIMht2P4tp0uSKRf+M=; b=RGEPgizX/U54pN1S8ZCZG+sB9cr9lioNlhw1oi0Wi0SUFGDvbUM7pMDY ws9/Pkl2KShj/Dro8km0WeDkWj+PX+l0J2sLehT9WC2PBjxYhSkmFSV+W vsDP0wYrVl4XXnf/v/1VyX1+JdRRQcK5FzMXDBea/x4iyYMnAfBXp0Nup E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AAD3DjBZ/xbLJq1dEwEBBQEBAQECA?= =?us-ascii?q?QEBAQgBAQEBhDmBDYNzihlzkF8hlXqCDwclhXgCgzIYAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FIyYmChALGCoCAlcGAQwIAQGKJhCrMhGBIoImi1MBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEOD4hsC4JpgwCBT4MsgmAFiVKNK4cshA2CGXuMCoIGVYgwI4ZLlFcfOIE?= =?us-ascii?q?KMCEIGxWDB4J6gUw+NgGJbgEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,279,1493683200"; d="asc'?scan'208";a="652253023" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2017 12:58:19 +0000 Received: from [10.61.212.77] ([10.61.212.77]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v51CwIr8013223; Thu, 1 Jun 2017 12:58:19 GMT To: Michael Richardson , Anima WG Cc: ibagdona@gmail.com, Zhoutianran , "opsawg@ietf.org" References: <031d87aa-1839-d7af-0723-dd9a2aa7ad0a@cisco.com> <26653.1495506219@obiwan.sandelman.ca> From: Eliot Lear Message-ID: <28cc40ec-f9ea-4528-b45c-82014959cdcb@cisco.com> Date: Thu, 1 Jun 2017 14:58:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <26653.1495506219@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HVddFxNULu280p2nQea6qJ8peAXfxfEIN" Archived-At: Subject: Re: [Anima] dealing with multiple manufacturer services with a single certificate extension X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 12:58:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HVddFxNULu280p2nQea6qJ8peAXfxfEIN Content-Type: multipart/mixed; boundary="LxtlJLrtMur50t2k5g7DKEmijMVjFuaEG"; protected-headers="v1" From: Eliot Lear To: Michael Richardson , Anima WG Cc: ibagdona@gmail.com, Zhoutianran , "opsawg@ietf.org" Message-ID: <28cc40ec-f9ea-4528-b45c-82014959cdcb@cisco.com> Subject: Re: [Anima] dealing with multiple manufacturer services with a single certificate extension References: <031d87aa-1839-d7af-0723-dd9a2aa7ad0a@cisco.com> <26653.1495506219@obiwan.sandelman.ca> In-Reply-To: <26653.1495506219@obiwan.sandelman.ca> --LxtlJLrtMur50t2k5g7DKEmijMVjFuaEG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Michael, Below. On 5/23/17 4:23 AM, Michael Richardson wrote: > I've read through the thread. It took more brain-power that I've had > available of recent. > > Let me ask some clarification questions about the original proposal. > > I generally agree with Max that the /.well-known/ part can be omitted. > > I also prefer passive (static file) initial interactions so that > the initial contact point can be most easily maintained over a period o= f > decades. I was surprised when some proprietary uses like this would po= int at > the www.example.com, rather than something more divorced from marketing= , > like a "bootstrap.example.com". > > So I rather like the mfg-services reply which is essentially a redirect= > which can be updated over the years. > > >> https://example.com/.well-known/mfg/modelname >> >> which would return something like: >> >> { >> "mfg-services" : [ >> "mud", "v1", "https://mud.example.com/Frobmaster3000.json", >> "anima", "v1", "https://masa.example.com/masa-service" >> ] >> } > correct? In this case, the modelname is there to distinguish phones > From printers from home-routers, which might well be very separate > divisions. That was the idea. Think a major consumer product manufacturer that has many different products. This doesn't require the manufacturer to create a domain per product. > >> At the moment, more manufacturers are coming back to me to say that we= >> should just leave these as separate and distinct mechanisms. I think t= hat's >> the simplest approach. > Distinct mechanisms, but common certificates? Or distinct certificates= ? That is- there is a single manufacturer certificate but distinct extensions that both contain URIs but might point to different places (indeed that would be the point). > > >> It seems to me the simplest way to handle this sort of thing is to cre= ate a >> table that MUD/ANIMA controllers simply download when they see the URL= =2E It >> might look something like this: > When you say ANIMA controller, I think you mean the JRC? > Yes. Eliot --LxtlJLrtMur50t2k5g7DKEmijMVjFuaEG-- --HVddFxNULu280p2nQea6qJ8peAXfxfEIN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZMA9qAAoJEIe2a0bZ0nozgyQH+wQAcNxi50ii0AkwRbolE4iy 4I02WFAYXi+xfp8qQrHH+djRxW3Baa5nGORAYeoay8e8w+4HOvaMP4T7Nnbpq5aQ KUY0zL5vjet5rzrE9kyw0vQp+w6t1P/PsiclnS2aj5bYoQltrI7dcK+XXfZhzO6H Sj3PMXOAQ+8Dk09R/XH+dS8/raXMi3zkzghJ9CuDUwWhvmNEdx4OMQmBL7iZSZ9N 8B7DgJdGW6enNsETZgadPW7TViA1RUdhAmGz+li+do/hLzgyrGDc6doK36cUKMFx 0ZV/Ws7Bs7a/YnddjXiYB4v6E7xVfsLVkbK0QFmzDTKvTaPHl2b82OvNw/X3Z3E= =3YUa -----END PGP SIGNATURE----- --HVddFxNULu280p2nQea6qJ8peAXfxfEIN-- From nobody Fri Jun 2 04:32:15 2017 Return-Path: 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 DF0D012EB58 for ; Fri, 2 Jun 2017 04:32:14 -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, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=0.001] 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 e5nR9WjJbKNO for ; Fri, 2 Jun 2017 04:32:12 -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 9055C12EB49 for ; Fri, 2 Jun 2017 04:32:12 -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 E759D58C4B0; Fri, 2 Jun 2017 13:32:07 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id CA62BB0C195; Fri, 2 Jun 2017 13:32:07 +0200 (CEST) Date: Fri, 2 Jun 2017 13:32:07 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Michael Richardson , Anima WG Message-ID: <20170602113207.GA12427@faui40p.informatik.uni-erlangen.de> References: <05b21e01-d856-ded5-87ec-da9d0f983310@gmail.com> <26917.1496083744@obiwan.sandelman.ca> <21a266aa-5650-d6bd-5a2d-a02bfc60eedc@gmail.com> <30412.1496162228@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 11:32:15 -0000 Alexey wrote: > I suggest inclusion of optional transport protocol here to match other > locators and to follow best practices for not encoding transport > information in URIs. >From my side; - I do not understand what "best practices for not encoding transport information in URIs" is. An example would be great. If http://example.com:1234/something-like-this is undesirable because it encodes a transport port number in the URI, then there is a whole universe not following "best practices for not encoding...". Else i wouldn't know what it means. - Aka: I have not seen common data models / user interfaces where IP version, protocol or port are specified together with URIs (but no in URI). If thats the recommended pracice i'd love pointer to prior reference doing that. - I am not sure why "match other locators" (in the GRASP document) is a useful goal. The other locators provide a transport endpoint locator (ipv*addr/fqdn, proto, port), URI provides formost a > layer 4 "protocol" (eg: http: or the like). Its like trying to fit apple and battleships into one class of O_*_WORDS... - So, i would really like an example i would really bother about instead of idontcareschema:irrelevant.example ;-) - If others feel that it "looks" inconsistent enough to bother but that there is no good example why / where / how we'd need those parameters for URI locators, then maybe just emphasize the difference between URI and the other locators by renaming those other locators to one class: O_IPV4_TE_LOCATOR, O_IPV6_TE_LOCATOR and O_FQDN_TE_LOCATOR (TE = Transport Endpoint). On Thu, Jun 01, 2017 at 03:22:30PM +1200, Brian E Carpenter wrote: > On 31/05/2017 04:37, Michael Richardson wrote: > > Brian E Carpenter wrote: > > > > >> Brian E Carpenter wrote: > I have > > >> started the process of going through IESG comments on the GRASP > > > >> draft. Where something is editorial or obviously non-controversial, I > > >> > will not ask for input. But I do need input on some things, and here > > >> is > the first. Please answer quickly; no answer will be taken to > > >> mean that > you don't care... > > >> > > >> > Alexy wrote: >>> uri-locator = [O_URI_LOCATOR, text] > > >> >>> > > >> >>> I suggest inclusion of optional transport protocol here to match > > >> >>> other locators and to follow best practices for not encoding >>> > > >> transport information in URIs. > > >> > > >> > That would become uri-locator = [O_URI_LOCATOR, text, > > >> transport-proto, > port-number] > > >> > > >> > Opinions? Objections? > > >> > > >> If the resource is really at https://example.com:9943/my/path > > >> > > >> what would text, transport-proto be? > > > > > "https://example.com:9943/my/path", Null, Null perhaps. > > > > > Also of course see the thread on Adam Roach's comment. > > > > okay, then give me an example where it wouldn't be null and null? > > funnyschema:funny.stuff > > Who knows what proto and port might be appropriate? I'll buy > Alexy's suggestion, because it really costs nothing. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Jun 2 06:22:29 2017 Return-Path: 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 A7AD812EB81; Fri, 2 Jun 2017 06:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 ZJkDgWLCkNEl; Fri, 2 Jun 2017 06:22:25 -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 6A8F712EA7C; Fri, 2 Jun 2017 06:22:25 -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 628A958C4B0; Fri, 2 Jun 2017 15:22:21 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4DC60B0C195; Fri, 2 Jun 2017 15:22:21 +0200 (CEST) Date: Fri, 2 Jun 2017 15:22:21 +0200 From: Toerless Eckert To: draft-ietf-anima-grasp@ietf.org, anima@ietf.org Message-ID: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] [draft-ietf-anima-grasp-12 review] feedback notes 1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:22:28 -0000 Dear authors: some comments/questions/suggestions for GRASP: P1: 3.8.4: " In a more complex implementation, the GRASP discovery mechanism will find, for each interface, a dynamic port that it can bind to for both UDP and TCP before initiating any discovery. " AFAIK currently, there is no definition of an originator port in the discovery message (initiator = ipv* address), so i can not see how the above mentioned "more complex implementation" could work. How would the responder know the dynamically assigned TCP or UDP port of the initiator ? How would it know whether to respond via TCP or UDP ? P2: In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are PrefixManager and PrefixManager.Params. Looks as if its useful to think of the objective-name space as hierarchical. But i do not find any text to that end in the GRASP draft. I would love to see GRASP objective-names to have at least for the purpose of IANA registration at least one level of hierarchy, which is (.)* and that IANA registrations are only for word1. Otherwise we would end up with a lot more "surplus"? IANA registrations that really only are details of a particular ASA/autonomic-function. P3: 3.8.11 Flood Synchronization Message It would be good to add some text explaining in more detail how to use the M_FLOOD objective. Here is some text explaining how _i_ think it works. I hope i even get it right: As outlined in the overview section, Flood Synchronization messages are used as an efficient mechanism to announce objectives and their parameters (synchronization data) when the objective is needed on many ASA in the network. Instead of creating an ongoing amount of flooded Request messages from every client of the objective, these clients can listen passively for flooded announcements of the objective. GRASP has no mechanism to flush long lived objectives whose announcer has died. ASA that use M_FLOOD objectives should primarily rely on transport layer mechanisms to determine the aliveness of a specific locator of such an objective: determine that an objective locator has become inoperatble due to "unreachable" signaling (eg: ICMP) or timeouts in attempts to establish a connection. Announcers of M_FLOOD objectives should carefully consider the time-to-live for such objectives to avoid that stale entries clog up caches and force a large number of clients to probe (unsuccessfully) a failed objective locator. For an objective with few locators in the network, a periodicity of 30 seconds and time-to-live of 90 seconds may be a good compromise (Supporting loss of as much as 3 out of three M_FLOOD messages). be lost. Note that every periodic announcement needs to have a new session-id to ensure that he new periodic messages is not ignored by GRASPs duplicate elimination mechanism. P4: " If a subsequent Flood Synchronization message carrying the same objective arrives with a different tag, a new cached entry MUST be created" I think this should not say "objective", but "objective-name". Eg: consider that any of the parameters of the objective have changed, then the new entry should also overwrite the old entry (for the same locator). More fundamentally: The orinator of M_FLOOD objectives would periodically send the M_FLOOD and the content of the new M_FLOOD would simply overwrite/refresh the cache content for what was cached with the same tag. Aka: that explanation should be rewritten. One could argue that it gets overwritten because the new M_FLOOD with its fresh time-to-live will have a longer lifetime than the cache entry, but event hat is IMHO to complex. The rule should simply be to update cache entries with fresh M_FLOOD information received (and just ignore duplicates with sesion-id). P5: 6. CDDL Specification of GRASP "objective-name = text ;see specification for uniqueness rules" ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ Which specification (i thought this is the specification), which uniqueness rules ? (uniqueness does not otherwise occur in the doc). P6: The handling of locators in GRASP is somewhat confusing: Except when using the URI locator, there seems to be no consistent encoding in GRASP what protocol to use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly encoded in the *any part of an objective. And i could not even find text that describes this. Not sure where, but maybe add an explanation like the following: GRASP does maintain the notion of locators only to the extend necessary to ensure that different ASA can be implemented as different application (processes). In the context of typical operating systems, different application processes require different transport sockets, eg: (address,proto,port) sockets (as in O_IPV4_LOCATOR, O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize declarations about what protocols an ASA expects to be used across these locators. If ASA need to indicate/negotiate a specific protocol across such a locator then that protocol would need to be specified as part of the objective specific parameters. section 3.9.5: "GRASP is not intended to work across disjoint addressing or naming realms". a) It would be helpful to have corollary text such as this: When GRASP is run in the ACP context, this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR). Using O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all IPv6 addresses of the domain name indicated are ACP addresses. ASA might also be able to identify IPv6 addresses to be part of the ACP because of their prefix, but that would be additional processing complexity not necessary when simply sticking to O_IPV6_LOCATORS of only ACP addresses. b) Another corollary that IMHO would be highly useful: The fact that GRASP is not intended to work across disjoint addressing spaces does not prohibit it to be used to signal and negotiate different address spaces: Consider a flood-message (M_FLOOD) in the context of running GRASP across the ACP: The objective independent locator option indicates a locator for the objective in the ACP. If there are locators for the objective outside of the ACP, then that locator would have to be encoded into the objective parameters - and it would be a problem for the involved ASAs to ensure that the receiving ASA will know what addressing/naming realm is indicated - and most likely that those ASA have connectivity to that addressing/naming realm. c) It would be nice if the CDDL for "objective" would not only say 'any', but would be given a name that we can use to refer to it, eg: 'objective-parameters' or 'objective-data' or the like. I like objective-parameters. Cheers toerlss From nobody Fri Jun 2 07:00:03 2017 Return-Path: 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 6035C120721; Fri, 2 Jun 2017 07:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 oUdspeULNRiS; Fri, 2 Jun 2017 07: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 D726912EBA1; Fri, 2 Jun 2017 07:00:00 -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 E0F5058C4B0; Fri, 2 Jun 2017 15:59:56 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C8F04B0C165; Fri, 2 Jun 2017 15:59:56 +0200 (CEST) Date: Fri, 2 Jun 2017 15:59:56 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Eric Rescorla , The IESG , draft-ietf-anima-grasp@ietf.org, Sheng Jiang , Anima WG Message-ID: <20170602135956.GC12427@faui40p.informatik.uni-erlangen.de> References: <149567957719.8737.9760305087658705406.idtracker@ietfa.amsl.com> <5229ccf3-e9b0-79d6-d71e-1c7b0bdc1a29@gmail.com> <93bd9175-77c7-e588-93f9-49a09e12cd66@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] DULL - Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:00:02 -0000 On Wed, May 31, 2017 at 01:59:57PM +1200, Brian E Carpenter wrote: > > As you indicate, DULL has a whole pile of rules. Why are those rules > > sufficient? > > They are supposed to be self-explanatory. I'm not sure what > the issue is. > > Toerless: please speak up, you wrote that text! Eric: We just tried to minimize any insecure usage of GRASP that we MUST do and then very explicitly enumerate the constraints in the protocol that must be observed to minimize the security impact. Logically speaking, all we need to do insecurely is to subnet-multicast "My IP-address is FOO and i can do BAR", so that neighbors on the subnet that want to do BAR can discover FOO. And then that neighbor will create a standard secure connection, eg: TLS to FOO. To the best of my knowledge, there is no logical way to further reduce the insecure part of communications unless you do know upfront the IP-address of all the neighbors we should BAR with, and we do not know those addresses. So, the whole discussion then ended up how to really constrain the operations of a protocol such as GRASP that is used in multiple contexts such that there is no leakage between one (eg: insecure) context and another (insecure or secure) context. Thats what all the rules are for. I think we have gone far beyond what i have seen elsewhere in really constraining the protocol operations for an insecure context in this fashion. In man other cases such rules where counterfitted long after the fact. We had long debates about how to do this most securely, comparing mDNS and GRASP etc. pp. Even down to the points raised of "we want to reuse existing protocol to reduce code-space requirements" vs. "we want to use a unique protocol for the insecure context to minimize leakage opportunity". Ultimately for me the argument won: "we want to use our own protocol to maximize the security rules because prior protocols have done a sh**y job". Alas, as usual in IETF documents, 90% of the reasoning behind all this can never make it into documents because the mayority of overworked reviewers really hate large amounts of text (for a reason *sigh*). How else can i help on this point ? If my explanation answers your question but you feel there shold be some level of this in the GRASP text, then it would be great if you could suggest that in your own words! [Will reply to the other points separately.] Cheers Toerless > > >> and how you bridge multicast to unicast. > >> > >> ? We don't do that. > >> > > > > Huh? You send out a discovery packet in multicast and then expect > > someone to connect to you via unicast, no? > > Yes, but that is elsewhere in the document (I think that came up > in Alissa's comments). Nothing new to say in this part. > > > > > > >>> That is the trust model, but really as an explanatory matter I think > >>>> it belongs in draft-ietf-anima-reference-model rather than here. > >>>> I will add a few words in the High Level Deployment Model > >>>> section and/or the Security Considerations. > >>>> > >>>> What we do say already is that authorization of ASAs is out of scope. > >>>> I am certain that it needs to be tackled, but not here. > >>>> > >>> > >>> I don't see how you have a complete protocol without that. > >> > >> The starting position is that we trust all autonomic nodes and therefore > >> the ASAs installed in them. We are in the context of a single operator > > > > so this isn't really a stretch. > > > > > > I certainly can see how someone might decide to deploy a system like > > this, but it seems pretty problematic to have a system that is so brittle > > to single-point compromise (The term of art here is "distributed single > > point of failure") > > > > > >> The questions around life cycle > >> management of ASAs, which would certainly involve authorization, > >> were intentionally not in the initial WG charter. I think it's true > >> that you can't have a complete *system* without that, but I disagree > >> that it's a requirement for the protocol. > >> > > > > At minimum you need to specify that this is your trust model and > > then work through the implications of compromise of some subset > > of nodes, as well as of an attacker who can influence which nodes > > you talk to. > > That really, really belongs in the reference model or the ACP draft; > it's in no way specific to GRASP, because nodes could use any protocol > they please over the ACP. > > Brian -- --- tte@cs.fau.de From nobody Fri Jun 2 18:28:03 2017 Return-Path: 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 58F34129AD7; Fri, 2 Jun 2017 18:28:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hNrjy2Xn2rd3; Fri, 2 Jun 2017 18:27:59 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 3BC02129AD5; Fri, 2 Jun 2017 18:27:58 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id s62so3360643pgc.0; Fri, 02 Jun 2017 18:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KboddRJATS+4ZsnpBAYs0jJM6V+XHxEvHO/C+KvtUoo=; b=TKCnoQsaH5eBH1ydpptobDWQiR2/aFqAzU8BlfFUwlHZoOwJkn9U4r791+y/j/RJ2I +F1lOIn1ljLDSpB0Tc4semx+YvF+hisPesSW6+K4DFWObPaW9VGpIqoddpCnC0uAf/2x j4ubcNpU9UtNeO64GnrAIPKgSBeaLsEGtHyB9LAOLV06oaERwDIIxCiuImNNhtYSXLOX xOodZYbmpnCG/x6SlW7H1gHF1yxRY43zpmfoKP7GUa5xaGKkfypcGiy4Te8K/TJTP248 g045CekRZAS2HUR7e+5aJiH9j0EpKDBHtToZfDL/fIIICwEnXjaVsrEMJvVib+A4UDNn 5bkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KboddRJATS+4ZsnpBAYs0jJM6V+XHxEvHO/C+KvtUoo=; b=YYiTt5QLJIaWg6H+gZvzIiPrLHbGXC1qAOqb1rNsLhw4jRe5mGoozykAKyNLzMHmHV Ko6b1+zRuU0RjsCIndvYxkhpkS+vTWoj344K3inAp5GNMJ4yWBZx4748Gypfl4pKPQOp Kum0gPp1bYyCzRT88nfntVHHEBF7luFU4OBTqagg1kOIkuPHv3Ny7FVSY+GM4dIV5ign e1vlPqQY9oUz0l4nKA9VUurSPLoIxSH6YGtP0rSz/VKXsiSZJ8m/M93bDdln5QUqw3DM ZZ5HaHP6SJoW8PF94yM3yEWrINxHb2tGihHf+Mq5VK6KBH2JhOHtTh43Z1X3o8QVUDTI L7hg== X-Gm-Message-State: AODbwcBdJaY8fkqOkgP37YgC/tjQVeHk10eazbu8HycKu62tYlVC3Xd7 LJUTJMj+U7Db8H2e X-Received: by 10.98.134.72 with SMTP id x69mr9703770pfd.106.1496453277291; Fri, 02 Jun 2017 18:27:57 -0700 (PDT) Received: from ?IPv6:2406:e007:42d1:1:28cc:dc4c:9703:6781? ([2406:e007:42d1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g27sm42517558pfg.63.2017.06.02.18.27.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 18:27:56 -0700 (PDT) To: Toerless Eckert , draft-ietf-anima-grasp@ietf.org, anima@ietf.org References: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6deae177-9984-b43f-f494-735ba8e2d36c@gmail.com> Date: Sat, 3 Jun 2017 13:28:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [draft-ietf-anima-grasp-12 review] feedback notes 1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 01:28:01 -0000 On 03/06/2017 01:22, Toerless Eckert wrote: > Dear authors: > > some comments/questions/suggestions for GRASP: > > P1: 3.8.4: > " In a more complex implementation, the GRASP discovery mechanism will find, > for each interface, a dynamic port that it can bind to for both UDP and TCP > before initiating any discovery. " > > AFAIK currently, there is no definition of an originator port in > the discovery message (initiator = ipv* address), so i can not see > how the above mentioned "more complex implementation" could work. How > would the responder know the dynamically assigned TCP or UDP port of the > initiator ? It's available in the socket API, returned with the message by recvfrom(). > How would it know whether to respond via TCP or UDP ? It's specified as always TCP. The phrasing is confusing though; we need to find a port that is available for *sending* UDP and *listening* for TCP. Will rephrase. > > P2: > > In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are > PrefixManager and PrefixManager.Params. Looks as if its useful to think of the > objective-name space as hierarchical. But i do not find any text to that end > in the GRASP draft. I would love to see GRASP objective-names to have at > least for the purpose of IANA registration at least one level of hierarchy, > which is (.)* and that IANA registrations are only for word1. > Otherwise we would end up with a lot more "surplus"? IANA registrations that > really only are details of a particular ASA/autonomic-function. Personal opinion: You may be right, but I'm not sure yet. Can we leave this for an update? It seems quite easy to retro-fit this to the registry when we have experience. For now, it will just give the IESG something else to DISCUSS. > > P3: 3.8.11 Flood Synchronization Message > > It would be good to add some text explaining in more detail how to use the M_FLOOD > objective. Here is some text explaining how _i_ think it works. I hope i even get > it right: > > As outlined in the overview section, Flood Synchronization messages are used as an efficient > mechanism to announce objectives and their parameters (synchronization data) when > the objective is needed on many ASA in the network. Instead of creating an ongoing > amount of flooded Request messages from every client of the objective, these clients > can listen passively for flooded announcements of the objective. > > GRASP has no mechanism to flush long lived objectives whose announcer has died. True, but that's a feature. If we've announced (say) the URL for Intent and the announcer dies, it doesn't mean the Intent is dead. > ASA that use M_FLOOD objectives should primarily rely on transport layer mechanisms > to determine the aliveness of a specific locator of such an objective: determine > that an objective locator has become inoperatble due to "unreachable" signaling > (eg: ICMP) or timeouts in attempts to establish a connection. Announcers of M_FLOOD > objectives should carefully consider the time-to-live for such objectives to avoid > that stale entries clog up caches and force a large number of clients to probe > (unsuccessfully) a failed objective locator. For an objective with few locators > in the network, a periodicity of 30 seconds and time-to-live of 90 seconds may be > a good compromise (Supporting loss of as much as 3 out of three M_FLOOD messages). > be lost. Note that every periodic announcement needs to have a new session-id to > ensure that he new periodic messages is not ignored by GRASPs duplicate elimination > mechanism. That's about right I think, but do we want to say this in the protocol spec? I don't think we want to give the IESG any new text to chew on right now. I'll take it as good input to draft-carpenter-anima-asa-guidelines > P4: > > " If a subsequent Flood Synchronization message carrying the same objective > arrives with a different tag, a new cached entry MUST be created" > > I think this should not say "objective", but "objective-name". Eg: consider > that any of the parameters of the objective have changed, then the new entry should > also overwrite the old entry (for the same locator). Yes, that's the intention. If the name and tag are the same, it overwrites. We can make it clearer. To me, "same objective" means "objectve with the same name" but I can see it might be unclear. > More fundamentally: The orinator of M_FLOOD objectives would periodically > send the M_FLOOD and the content of the new M_FLOOD would simply overwrite/refresh > the cache content for what was cached with the same tag. Aka: that explanation > should be rewritten. One could argue that it gets overwritten because the new > M_FLOOD with its fresh time-to-live will have a longer lifetime than the cache > entry, but event hat is IMHO to complex. The rule should simply be to update > cache entries with fresh M_FLOOD information received (and just ignore duplicates > with sesion-id). Iy seems to me that the previous sentence ending "the corresponding cached copy of the objective MUST be overwritten" says this quite clearly. > P5: > > 6. CDDL Specification of GRASP > "objective-name = text ;see specification for uniqueness rules" > ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ > Which specification (i thought this is the specification), > which uniqueness rules ? (uniqueness does not otherwise occur in the doc). Section . It's impossible to include an in CDATA text. Will find a way to fix this. > > P6: The handling of locators in GRASP is somewhat confusing: Except when using the > URI locator, there seems to be no consistent encoding in GRASP what protocol to > use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly > encoded in the *any part of an objective. No. When you discover an objective, the discovered locator is [address, protocol, port]. Then there's an option on a flood to tag the flooded objective with [address, protocol, port]. I just don't see the problem. > And i could not even find text that > describes this. Not sure where, but maybe add an explanation like the following: > > GRASP does maintain the notion of locators only to the extend necessary to ensure > that different ASA can be implemented as different application (processes). In the > context of typical operating systems, different application processes require > different transport sockets, eg: (address,proto,port) sockets (as in O_IPV4_LOCATOR, > O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize declarations > about what protocols an ASA expects to be used across these locators. If ASA > need to indicate/negotiate a specific protocol across such a locator then that > protocol would need to be specified as part of the objective specific parameters. That's wrong, sorry. Of course you could put anything you like in the objective value, but GRASP already supplies the locator 3tuple. > section 3.9.5: "GRASP is not intended to work across disjoint addressing or naming realms". > > a) It would be helpful to have corollary text such as this> > When GRASP is run in the ACP context, > this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR). Using > O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all > IPv6 addresses of the domain name indicated are ACP addresses. ASA might also be > able to identify IPv6 addresses to be part of the ACP because of their prefix, > but that would be additional processing complexity not necessary when simply > sticking to O_IPV6_LOCATORS of only ACP addresses. > > b) Another corollary that IMHO would be highly useful: > > The fact that GRASP is not intended to work across disjoint addressing spaces > does not prohibit it to be used to signal and negotiate different address spaces: > Consider a flood-message (M_FLOOD) in the context of running GRASP across the ACP: > The objective independent locator option indicates a locator for the objective > in the ACP. If there are locators for the objective outside of the ACP, then > that locator would have to be encoded into the objective parameters - and it would > be a problem for the involved ASAs to ensure that the receiving ASA will know > what addressing/naming realm is indicated - and most likely that those ASA have > connectivity to that addressing/naming realm. Look, I'm not very interested in adding yet more text to confuse the IESG further. I think both of your comments are true but do you really want another month of discussion? > c) It would be nice if the CDDL for "objective" would not only say 'any', but > would be given a name that we can use to refer to it, eg: 'objective-parameters' > or 'objective-data' or the like. I like objective-parameters. But then we'd have a rule objective-parameters = any. Is that really an improvement? Regards Brian > > Cheers > toerlss > From nobody Sun Jun 4 07:55:05 2017 Return-Path: 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 A636F129B62; Sun, 4 Jun 2017 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 I_gB7eH8ix-8; Sun, 4 Jun 2017 07:55:00 -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 3DFBE129B6F; Sun, 4 Jun 2017 07:54:59 -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 2246D58C4B8; Sun, 4 Jun 2017 16:54:55 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0EF29B0C17A; Sun, 4 Jun 2017 16:54:54 +0200 (CEST) Date: Sun, 4 Jun 2017 16:54:54 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-grasp@ietf.org, anima@ietf.org Message-ID: <20170604145454.GD12427@faui40p.informatik.uni-erlangen.de> References: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> <6deae177-9984-b43f-f494-735ba8e2d36c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6deae177-9984-b43f-f494-735ba8e2d36c@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] [draft-ietf-anima-grasp-12 review] feedback notes 1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 14:55:03 -0000 On Sat, Jun 03, 2017 at 01:28:03PM +1200, Brian E Carpenter wrote: > On 03/06/2017 01:22, Toerless Eckert wrote: > > Dear authors: > > > > P1: 3.8.4: > > " In a more complex implementation, the GRASP discovery mechanism will find, > > for each interface, a dynamic port that it can bind to for both UDP and TCP > > before initiating any discovery. " > > > > AFAIK currently, there is no definition of an originator port in > > the discovery message (initiator = ipv* address), so i can not see > > how the above mentioned "more complex implementation" could work. How > > would the responder know the dynamically assigned TCP or UDP port of the > > initiator ? > > It's available in the socket API, returned with the message by recvfrom(). > > > How would it know whether to respond via TCP or UDP ? > > It's specified as always TCP. The phrasing is confusing though; we need to > find a port that is available for *sending* UDP and *listening* for TCP. > Will rephrase. So, in the first place, the question is why anyone would want to have "a more complex implementation". The text does not answer this question but should answer it. I guess the reason would go back to what we discussed long ago wrt. how much GRASP an ASA wants to do itself vs. how much some shared GRASP daemon/ASA needs to do. With what you write about a complex implementation, it _might_ be possible to do more GRASP in the client ASA and minimize code in a shared GRASP daemon: 1. Responder ANI device has 5 ASA. Each ASA is its own process, binds to it's own TCP port. That same port number must also be available as a free UDP port. 2. Responder ASA1 registers an objective with the GRASP ASA/Daemon. GRASP ASA/Daemon is the one listening to GRASP Discovery messages on the GRASP multicast address and GRASP port. This is the "shared daemon" requirement because we can't be certain all OS's support replicating received multicast messages to multiple sockets from different processes. 3. Now Initiator ASA on a different device wants to discover that responder ASA1 objective and wants to make sure that the TCP connection built can be directly from the responder ASA1 to the initiator ASA - without the need to pass traffic of that GRASP TCP connecetion via the GRASP daemons: 4. So, initiator ASA tries to find a port that it can bind to for both TCP and UDP. Once it has found that port, it will send a UDP multicast GRASP discovery to the GRASP destination port and with the source port being its own bound UDP port. 5. Now the responder ANI devices GRASP daemon receives that discover message. because that objective was registered by ASA1, the GRASP daemon passes the discovery request to ASA1 including the UDP source port from the received discovery message. 6. Now the ASA1 on the responder can build a TCP connetion back to the initiator using the same TCP port as UDP port. http://www.staples.com/Staples-Easy-Button/product_606396 (highly recommended product when dealing with obfuscated technology !) So... IMHO that problem of dealing with multicast and socket API issues is already difficult enough without having to deal with the problem of having to be able to bind to the same port number for UDP and TCP: IMHO, the discover multicast message needs to have another message element which is the port number to reply to. Thats assuming the reply is always TCP. If you feel UDP should also be an option then the discovery message should indicate the desired reply mode UDP/TCP and port number. Now, both approaches have a normal socket API security issue: when the responder receives the discovery message and in return builds a TCP connection, there is no guarantee that the actual TCP port on the initiator is owned by te same process as the UDP port in the discovery - whether its in the UDP source port field of the discovery message or in a GRASP message element. So, if we want to secure this UDP multicast discovery -> TCP reply in the context of existing socket APIs, then i think the mechanism could be further refined: In the context of standard socket APIs, a responder can not know for certain that the initiator TCP port is owned by the process that initiated the discovery request. The only mitigation is to a) trust the GRASP daemon on the remote side. b) The remote GRASP daemon has bound to the GRASP UDP port, so discovery multicast packets whose source UDP port is also the gRASP port (the destination port must be the GRASP port) are trusted to have come from the remote GRASP daemon. And then the TCP port number in the discover message is trusted. c) GRASP daemons can use local mechanisms to ensure that the TCP port indicated by an ASA is also owned by the ASA (aka: the interface between an ASA daemon and a GRASP daemon can use a POSIX standard UNIX socket and the gRASP daemon creates that socket and passes it back to the ASA). That way the GRASP daemon knows the TCP socket port number reliably. This is all convoluted. If you are not a big fan of concoluted explanatory text like what i wrote up above, i can understand it. But i am not a big fan of suggestive incomplete text that you have on the draft right now... The text optimized version of this is: a) add the (TCP) port parameter into the discovery message and remove text about "complex implementations" ;-) (and put the discussion into the guidelines document as you suggested below). > > P2: > > > > In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are > > PrefixManager and PrefixManager.Params. Looks as if its useful to think of the > > objective-name space as hierarchical. But i do not find any text to that end > > in the GRASP draft. I would love to see GRASP objective-names to have at > > least for the purpose of IANA registration at least one level of hierarchy, > > which is (.)* and that IANA registrations are only for word1. > > Otherwise we would end up with a lot more "surplus"? IANA registrations that > > really only are details of a particular ASA/autonomic-function. > > Personal opinion: You may be right, but I'm not sure yet. Can we leave > this for an update? It seems quite easy to retro-fit this to the registry > when we have experience. For now, it will just give the IESG something > else to DISCUSS. Sure. If that ever requires a one page follow-on RFC to change registry semantic from name to name-prefix, count me in as an author ;-P > > P3: 3.8.11 Flood Synchronization Message [...] > > GRASP has no mechanism to flush long lived objectives whose announcer has died. > > True, but that's a feature. If we've announced (say) the URL for Intent and the > announcer dies, it doesn't mean the Intent is dead. Right, but if we are a registrar and die then the proxies can not use us anymore. Which can be solved by failing connections etc. pp.. > > > ASA that use M_FLOOD objectives should primarily rely on transport layer mechanisms > > to determine the aliveness of a specific locator of such an objective: determine > > that an objective locator has become inoperatble due to "unreachable" signaling > > (eg: ICMP) or timeouts in attempts to establish a connection. Announcers of M_FLOOD > > objectives should carefully consider the time-to-live for such objectives to avoid > > that stale entries clog up caches and force a large number of clients to probe > > (unsuccessfully) a failed objective locator. For an objective with few locators > > in the network, a periodicity of 30 seconds and time-to-live of 90 seconds may be > > a good compromise (Supporting loss of as much as 3 out of three M_FLOOD messages). > > be lost. Note that every periodic announcement needs to have a new session-id to > > ensure that he new periodic messages is not ignored by GRASPs duplicate elimination > > mechanism. > > That's about right I think, but do we want to say this in the protocol spec? > I don't think we want to give the IESG any new text to chew on right now. > I'll take it as good input to draft-carpenter-anima-asa-guidelines Sure. Do you mind an informational forward pointer to that doc in the GRASP spec so as to leave that breadcrumb ? > > P4: > > > > " If a subsequent Flood Synchronization message carrying the same objective > > arrives with a different tag, a new cached entry MUST be created" > > > > I think this should not say "objective", but "objective-name". Eg: consider > > that any of the parameters of the objective have changed, then the new entry should > > also overwrite the old entry (for the same locator). > > Yes, that's the intention. If the name and tag are the same, it overwrites. > We can make it clearer. To me, "same objective" means "objectve with the > same name" but I can see it might be unclear. I have started to use the names as they are defined in CDDL ;-) > > More fundamentally: The orinator of M_FLOOD objectives would periodically > > send the M_FLOOD and the content of the new M_FLOOD would simply overwrite/refresh > > the cache content for what was cached with the same tag. Aka: that explanation > > should be rewritten. One could argue that it gets overwritten because the new > > M_FLOOD with its fresh time-to-live will have a longer lifetime than the cache > > entry, but event hat is IMHO to complex. The rule should simply be to update > > cache entries with fresh M_FLOOD information received (and just ignore duplicates > > with sesion-id). > > Iy seems to me that the previous sentence ending "the corresponding cached copy > of the objective MUST be overwritten" says this quite clearly. If it wold say objective-name, yes. My implied question was if he method of "dying-gasp" should work: eg: a graceful removed objective could announce itself with M_FLOOD of time-to-live = 1 sec and therefore overwrite any further longer-lived ttl. I think it should work, but given how terse the text is, i wonder if implementations would do the right thing (yeah, i k ow 78 pages and still this toerless guy calls it terse ;-) I like the guidelines draft option of outsourcing additional explanatory text. > > P5: > > > > 6. CDDL Specification of GRASP > > "objective-name = text ;see specification for uniqueness rules" > > ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ > > Which specification (i thought this is the specification), > > which uniqueness rules ? (uniqueness does not otherwise occur in the doc). > > Section . It's impossible to include an in CDATA text. > Will find a way to fix this. Yes, i stumbled across that problem in the bootstrap draft as well. Maybe just refer to the section with the picture. > > P6: The handling of locators in GRASP is somewhat confusing: Except when using the > > URI locator, there seems to be no consistent encoding in GRASP what protocol to > > use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly > > encoded in the *any part of an objective. > > No. When you discover an objective, the discovered locator is [address, protocol, port]. > Then there's an option on a flood to tag the flooded objective with [address, protocol, port]. > I just don't see the problem. I am talking about the protocol inside of the UDP/TCP locator. > > And i could not even find text that > > describes this. Not sure where, but maybe add an explanation like the following: > > > > GRASP does maintain the notion of locators only to the extend necessary to ensure > > that different ASA can be implemented as different application (processes). In the > > context of typical operating systems, different application processes require > > different transport sockets, eg: (address,proto,port) sockets (as in O_IPV4_LOCATOR, > > O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize declarations > > about what protocols an ASA expects to be used across these locators. If ASA > > need to indicate/negotiate a specific protocol across such a locator then that > > protocol would need to be specified as part of the objective specific parameters. > > That's wrong, sorry. Of course you could put anything you like in the objective value, > but GRASP already supplies the locator 3tuple. See your own example for BRSKI with GRASP in the ani recommendation draft. What you call method = BRSKI-TLS is what i call the protocol > > section 3.9.5: "GRASP is not intended to work across disjoint addressing or naming realms". > > > > a) It would be helpful to have corollary text such as this> > > When GRASP is run in the ACP context, > > this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR). Using > > O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all > > IPv6 addresses of the domain name indicated are ACP addresses. ASA might also be > > able to identify IPv6 addresses to be part of the ACP because of their prefix, > > but that would be additional processing complexity not necessary when simply > > sticking to O_IPV6_LOCATORS of only ACP addresses. > > > > b) Another corollary that IMHO would be highly useful: > > > > The fact that GRASP is not intended to work across disjoint addressing spaces > > does not prohibit it to be used to signal and negotiate different address spaces: > > Consider a flood-message (M_FLOOD) in the context of running GRASP across the ACP: > > The objective independent locator option indicates a locator for the objective > > in the ACP. If there are locators for the objective outside of the ACP, then > > that locator would have to be encoded into the objective parameters - and it would > > be a problem for the involved ASAs to ensure that the receiving ASA will know > > what addressing/naming realm is indicated - and most likely that those ASA have > > connectivity to that addressing/naming realm. > > Look, I'm not very interested in adding yet more text to confuse the IESG > further. I think both of your comments are true but do you really want another > month of discussion? see below. > > > c) It would be nice if the CDDL for "objective" would not only say 'any', but > > would be given a name that we can use to refer to it, eg: 'objective-parameters' > > or 'objective-data' or the like. I like objective-parameters. > > But then we'd have a rule objective-parameters = any. Is that really > an improvement? Without that line we do not have a normative word for the parameters of GRASP objectives. For example, the whole discussion about name spaces could be one simple corollary: All locators used outside of grasp-parameters MUST be from the namespace GRASP is running in. Cheers Toerless > Regards > Brian > > > > > Cheers > > toerlss From nobody Sun Jun 4 15:56:17 2017 Return-Path: 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 B035B12E054; Sun, 4 Jun 2017 15:56:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 kt0YHu3t_Zya; Sun, 4 Jun 2017 15:56:14 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 03111127B5A; Sun, 4 Jun 2017 15:56:14 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id v14so4077299pgn.1; Sun, 04 Jun 2017 15:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=24a7HXENZcsdE3HVNPLfkFYZMKCz6y02guKuS8eAX3o=; b=Yi2Zc62+YlZbz3zS3DQerfphAJl3YZz16yD5oa8qxjBgZFDQ6Kjw94NOojI2/s0QjZ oOMbTVM9dVwPKsrhP/YHffoG2O2+3H30Uz0Jqfwgs00Epwyqv4mEBfFaGJk1HqIj2+QA q5jRvUMxe5u7Hz9im2phdU5Ci0gmBH2RHKDF52W1YLV2brYM3ZDbuyCNYJGB57BqMDvc Bt/mfT/xbPV/erOOy2oJc1fu3mpkqQzZJ9lNRbSbhK0B1QCSqzrBNBqBlDeHMtVnjQ+M waR6r0bOFrfm+BqKKgc1xwCVQhX6pRoLZo5rpLCPQKd2DMAJECAag3fm5/uFMvwyhrai ZjuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=24a7HXENZcsdE3HVNPLfkFYZMKCz6y02guKuS8eAX3o=; b=pM/wtofNiBBYR2ukLGywUNstouPhkE7Jx0wsr91JUr4HypwuLjl10bAo2LhOoV3ljT QI1ZGHYrEEHJ1gpIe+Hfjt1AkwfWgmJSei0og8bgdJ+0GGpnjCRyrCgoD/VWZAAH2RKr mX/HJpMpHSS0PRINClDDY2GbgAN9bFmFsu5tmQiDFyiCFYsi5wcaJ9IULua50KY6Eaqg c3IN6NGYNczY+ROVj2V+c804YodqbILFKwl2a3MMF9xbc9FshUgiyDVcGai0m1oQFVoK Qhqbf2RVp09XrHGV2YmjBxyCBKsa02j/6HteVz4F8Inwrx1CEt0ScA80WvNmwgLcw47l s+Eg== X-Gm-Message-State: AODbwcD12d13b0KnH1aUVt7/4QzWojCJ6qzQHuPx5uShjmP+EXzRGYzB 5pYQ+idBlIzOVjdU X-Received: by 10.84.129.99 with SMTP id 90mr2589845plb.62.1496616973066; Sun, 04 Jun 2017 15:56:13 -0700 (PDT) Received: from ?IPv6:2406:e001:3d38:1:28cc:dc4c:9703:6781? ([2406:e001:3d38:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s131sm11490326pgs.6.2017.06.04.15.56.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 15:56:12 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-grasp@ietf.org, anima@ietf.org References: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> <6deae177-9984-b43f-f494-735ba8e2d36c@gmail.com> <20170604145454.GD12427@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2ec876ce-2478-27ec-881b-d2635f1cb66f@gmail.com> Date: Mon, 5 Jun 2017 10:56:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170604145454.GD12427@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [draft-ietf-anima-grasp-12 review] feedback notes 1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 22:56:16 -0000 On 05/06/2017 02:54, Toerless Eckert wrote: > On Sat, Jun 03, 2017 at 01:28:03PM +1200, Brian E Carpenter wrote: >> On 03/06/2017 01:22, Toerless Eckert wrote: >>> Dear authors: >>> >>> P1: 3.8.4: >>> " In a more complex implementation, the GRASP discovery mechanism will find, >>> for each interface, a dynamic port that it can bind to for both UDP and TCP >>> before initiating any discovery. " >>> >>> AFAIK currently, there is no definition of an originator port in >>> the discovery message (initiator = ipv* address), so i can not see >>> how the above mentioned "more complex implementation" could work. How >>> would the responder know the dynamically assigned TCP or UDP port of the >>> initiator ? >> >> It's available in the socket API, returned with the message by recvfrom(). >> >>> How would it know whether to respond via TCP or UDP ? >> >> It's specified as always TCP. The phrasing is confusing though; we need to >> find a port that is available for *sending* UDP and *listening* for TCP. >> Will rephrase. > > So, in the first place, the question is why anyone would want to have > "a more complex implementation". The text does not answer this question but > should answer it. The reason we really need this that if you want two separate instances of GRASP to run in the same node at the same time, you must have a separate port for each instance. They can't both listen to unicasts on GRASP_LISTEN_PORT. We should state that in the text, rather than the obscure "more complex" phrase. Your model below is really a case of that, since each ASA would contain its own instance of discovery. (Personally I don't recommend that: we should hide as much as possible from the ASA programmer. But that's off topic in the protocol spec.) > > I guess the reason would go back to what we discussed long ago wrt. how much GRASP > an ASA wants to do itself vs. how much some shared GRASP daemon/ASA needs to do. > With what you write about a complex implementation, it _might_ be possible to > do more GRASP in the client ASA and minimize code in a shared GRASP daemon: > > 1. Responder ANI device has 5 ASA. Each ASA is its own process, binds to it's > own TCP port. That same port number must also be available as a free UDP port. > > 2. Responder ASA1 registers an objective with the GRASP ASA/Daemon. > GRASP ASA/Daemon is the one listening to GRASP Discovery messages on the > GRASP multicast address and GRASP port. This is the "shared daemon" requirement > because we can't be certain all OS's support replicating received multicast > messages to multiple sockets from different processes. > > 3. Now Initiator ASA on a different device wants to discover that responder ASA1 > objective and wants to make sure that the TCP connection built can be directly from > the responder ASA1 to the initiator ASA - without the need to pass traffic of > that GRASP TCP connecetion via the GRASP daemons: > > 4. So, initiator ASA tries to find a port that it can bind to for both TCP and > UDP. Once it has found that port, it will send a UDP multicast GRASP discovery > to the GRASP destination port and with the source port being its own bound UDP port. > > 5. Now the responder ANI devices GRASP daemon receives that discover message. > because that objective was registered by ASA1, the GRASP daemon passes the discovery > request to ASA1 including the UDP source port from the received discovery message. > > 6. Now the ASA1 on the responder can build a TCP connetion back to the initiator > using the same TCP port as UDP port. > > http://www.staples.com/Staples-Easy-Button/product_606396 > (highly recommended product when dealing with obfuscated technology !) > > So... IMHO that problem of dealing with multicast and socket API issues is already > difficult enough without having to deal with the problem of having to be able to bind > to the same port number for UDP and TCP Yes, it is a bit messy because the socket API is so primitive, but because of the above mentioned problem that you can't share a TCP port between instances, I see no alternative. > > IMHO, the discover multicast message needs to have another message element which is the > port number to reply to. Thats assuming the reply is always TCP. If you feel UDP > should also be an option then the discovery message should indicate the desired > reply mode UDP/TCP and port number. We could have designed it that way but we didn't, and I don't want to make such a change in the middle of IESG discussion (unless of course we find a bug). > Now, both approaches have a normal socket API security issue: when the responder > receives the discovery message and in return builds a TCP connection, there is > no guarantee that the actual TCP port on the initiator is owned by te same > process as the UDP port in the discovery - whether its in the UDP source port > field of the discovery message or in a GRASP message element. > > So, if we want to secure this UDP multicast discovery -> TCP reply in the context > of existing socket APIs, then i think the mechanism could be further refined: > > In the context of standard socket APIs, a responder can not know for certain that > the initiator TCP port is owned by the process that initiated the discovery > request. The only mitigation is to > a) trust the GRASP daemon on the remote side. In the ACP, we can do that. > b) The remote GRASP daemon has bound to the GRASP UDP port, so discovery > multicast packets whose source UDP port is also the gRASP port (the > destination port must be the GRASP port) are trusted to have come from the > remote GRASP daemon. And then the TCP port number in the discover message > is trusted. Yes, in the single-instance case. But that isn't the general case. > c) GRASP daemons can use local mechanisms to ensure that the TCP port indicated > by an ASA is also owned by the ASA (aka: the interface between an ASA daemon > and a GRASP daemon can use a POSIX standard UNIX socket and the gRASP daemon > creates that socket and passes it back to the ASA). That way the GRASP daemon > knows the TCP socket port number reliably. If the discovery is executed entirely by the GRASP core, the ASA never knows anything about the socket. That's my preferred implementation but it isn't required by the protocol spec, obviously. > > This is all convoluted. If you are not a big fan of concoluted explanatory text > like what i wrote up above, i can understand it. But i am not a big fan of > suggestive incomplete text that you have on the draft right now... Sure. And changing to to be specific that this is needed for mutiple instances in one node is a good idea (and is IMHO a complete explanation of why it's needed). > > The text optimized version of this is: a) add the (TCP) port parameter into the > discovery message and remove text about "complex implementations" ;-) > (and put the discussion into the guidelines document as you suggested below). As above: IMHO this is not the time to change the protocol spec. (If the current spec wasn't implementable I would have suggested a change a long time ago.) > >>> P2: >>> >>> In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are >>> PrefixManager and PrefixManager.Params. Looks as if its useful to think of the >>> objective-name space as hierarchical. But i do not find any text to that end >>> in the GRASP draft. I would love to see GRASP objective-names to have at >>> least for the purpose of IANA registration at least one level of hierarchy, >>> which is (.)* and that IANA registrations are only for word1. >>> Otherwise we would end up with a lot more "surplus"? IANA registrations that >>> really only are details of a particular ASA/autonomic-function. >> >> Personal opinion: You may be right, but I'm not sure yet. Can we leave >> this for an update? It seems quite easy to retro-fit this to the registry >> when we have experience. For now, it will just give the IESG something >> else to DISCUSS. > > Sure. If that ever requires a one page follow-on RFC to change registry semantic > from name to name-prefix, count me in as an author ;-P > >>> P3: 3.8.11 Flood Synchronization Message > [...] >>> GRASP has no mechanism to flush long lived objectives whose announcer has died. >> >> True, but that's a feature. If we've announced (say) the URL for Intent and the >> announcer dies, it doesn't mean the Intent is dead. > > Right, but if we are a registrar and die then the proxies can not use us anymore. > Which can be solved by failing connections etc. pp.. Yes. Every single bit of code in autonomics must handle exceptions. >>> ASA that use M_FLOOD objectives should primarily rely on transport layer mechanisms >>> to determine the aliveness of a specific locator of such an objective: determine >>> that an objective locator has become inoperatble due to "unreachable" signaling >>> (eg: ICMP) or timeouts in attempts to establish a connection. Announcers of M_FLOOD >>> objectives should carefully consider the time-to-live for such objectives to avoid >>> that stale entries clog up caches and force a large number of clients to probe >>> (unsuccessfully) a failed objective locator. For an objective with few locators >>> in the network, a periodicity of 30 seconds and time-to-live of 90 seconds may be >>> a good compromise (Supporting loss of as much as 3 out of three M_FLOOD messages). >>> be lost. Note that every periodic announcement needs to have a new session-id to >>> ensure that he new periodic messages is not ignored by GRASPs duplicate elimination >>> mechanism. >> >> That's about right I think, but do we want to say this in the protocol spec? >> I don't think we want to give the IESG any new text to chew on right now. >> I'll take it as good input to draft-carpenter-anima-asa-guidelines > > Sure. Do you mind an informational forward pointer to that doc in the GRASP spec > so as to leave that breadcrumb ? Yes, I will look for a good place to plant that. > >>> P4: >>> >>> " If a subsequent Flood Synchronization message carrying the same objective >>> arrives with a different tag, a new cached entry MUST be created" >>> >>> I think this should not say "objective", but "objective-name". Eg: consider >>> that any of the parameters of the objective have changed, then the new entry should >>> also overwrite the old entry (for the same locator). >> >> Yes, that's the intention. If the name and tag are the same, it overwrites. >> We can make it clearer. To me, "same objective" means "objectve with the >> same name" but I can see it might be unclear. > > I have started to use the names as they are defined in CDDL ;-) > >>> More fundamentally: The orinator of M_FLOOD objectives would periodically >>> send the M_FLOOD and the content of the new M_FLOOD would simply overwrite/refresh >>> the cache content for what was cached with the same tag. Aka: that explanation >>> should be rewritten. One could argue that it gets overwritten because the new >>> M_FLOOD with its fresh time-to-live will have a longer lifetime than the cache >>> entry, but event hat is IMHO to complex. The rule should simply be to update >>> cache entries with fresh M_FLOOD information received (and just ignore duplicates >>> with sesion-id). >> >> Iy seems to me that the previous sentence ending "the corresponding cached copy >> of the objective MUST be overwritten" says this quite clearly. > > If it wold say objective-name, yes. My implied question was if he method > of "dying-gasp" should work: eg: a graceful removed objective could announce > itself with M_FLOOD of time-to-live = 1 sec and therefore overwrite any further > longer-lived ttl. I think it should work, but given how terse the text is, > i wonder if implementations would do the right thing (yeah, i k ow 78 pages and > still this toerless guy calls it terse ;-) > > I like the guidelines draft option of outsourcing additional explanatory text. > >>> P5: >>> >>> 6. CDDL Specification of GRASP >>> "objective-name = text ;see specification for uniqueness rules" >>> ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ >>> Which specification (i thought this is the specification), >>> which uniqueness rules ? (uniqueness does not otherwise occur in the doc). >> >> Section . It's impossible to include an in CDATA text. >> Will find a way to fix this. > > Yes, i stumbled across that problem in the bootstrap draft as well. Maybe > just refer to the section with the picture. > >>> P6: The handling of locators in GRASP is somewhat confusing: Except when using the >>> URI locator, there seems to be no consistent encoding in GRASP what protocol to >>> use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly >>> encoded in the *any part of an objective. >> >> No. When you discover an objective, the discovered locator is [address, protocol, port]. >> Then there's an option on a flood to tag the flooded objective with [address, protocol, port]. >> I just don't see the problem. > > I am talking about the protocol inside of the UDP/TCP locator. Yes, that's really the same point that Adam Roach caught. I think the next text will be clearer (in the description of "Locator IPv6 address option", although it also applies to IPv4). > >>> And i could not even find text that >>> describes this. Not sure where, but maybe add an explanation like the following: >>> >>> GRASP does maintain the notion of locators only to the extend necessary to ensure >>> that different ASA can be implemented as different application (processes). In the >>> context of typical operating systems, different application processes require >>> different transport sockets, eg: (address,proto,port) sockets (as in O_IPV4_LOCATOR, >>> O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize declarations >>> about what protocols an ASA expects to be used across these locators. If ASA >>> need to indicate/negotiate a specific protocol across such a locator then that >>> protocol would need to be specified as part of the objective specific parameters. >> >> That's wrong, sorry. Of course you could put anything you like in the objective value, >> but GRASP already supplies the locator 3tuple. > > See your own example for BRSKI with GRASP in the ani recommendation draft. > What you call method = BRSKI-TLS is what i call the protocol Sure, but that's relative to a very specialised infrastructure objective. I regard that as an almost pathological case that needs a separate spec (inside BRSKI, but I havn't had time to look at the latest BRSKI). > >>> section 3.9.5: "GRASP is not intended to work across disjoint addressing or naming realms". >>> >>> a) It would be helpful to have corollary text such as this> >>> When GRASP is run in the ACP context, >>> this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR). Using >>> O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all >>> IPv6 addresses of the domain name indicated are ACP addresses. ASA might also be >>> able to identify IPv6 addresses to be part of the ACP because of their prefix, >>> but that would be additional processing complexity not necessary when simply >>> sticking to O_IPV6_LOCATORS of only ACP addresses. >>> >>> b) Another corollary that IMHO would be highly useful: >>> >>> The fact that GRASP is not intended to work across disjoint addressing spaces >>> does not prohibit it to be used to signal and negotiate different address spaces: >>> Consider a flood-message (M_FLOOD) in the context of running GRASP across the ACP: >>> The objective independent locator option indicates a locator for the objective >>> in the ACP. If there are locators for the objective outside of the ACP, then >>> that locator would have to be encoded into the objective parameters - and it would >>> be a problem for the involved ASAs to ensure that the receiving ASA will know >>> what addressing/naming realm is indicated - and most likely that those ASA have >>> connectivity to that addressing/naming realm. >> >> Look, I'm not very interested in adding yet more text to confuse the IESG >> further. I think both of your comments are true but do you really want another >> month of discussion? > > see below. >> >>> c) It would be nice if the CDDL for "objective" would not only say 'any', but >>> would be given a name that we can use to refer to it, eg: 'objective-parameters' >>> or 'objective-data' or the like. I like objective-parameters. >> >> But then we'd have a rule objective-parameters = any. Is that really >> an improvement? > > Without that line we do not have a normative word for the parameters of GRASP > objectives. Well, OK, but for overall consistency I think it has to be objective-value. > > For example, the whole discussion about name spaces could be one simple corollary: > > All locators used outside of grasp-parameters MUST be from the namespace GRASP is > running in. That's more or less what the note in "Locator Options" says. I can make it more explicit. I'm not convinced it needs a MUST though. Who can guess what people will invent in future? Hmm. I have a lot of changes stacked up in the XML. I'm quite keen to post the draft. Brian From nobody Sun Jun 4 18:43:02 2017 Return-Path: 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 816B212751F for ; Sun, 4 Jun 2017 18:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 a-4GqlHTWong for ; Sun, 4 Jun 2017 18:42:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BA8124B0A for ; Sun, 4 Jun 2017 18:42:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 98598203AD for ; Sun, 4 Jun 2017 21:43:37 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4697A6380F for ; Sun, 4 Jun 2017 21:42:58 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] 200 vs 201 responses from MASA to Registrar (BRSKI-MASA protocol) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 01:43:00 -0000 --=-=-= Content-Type: text/plain Max, in section 3.3 we document the contents that the Registrar will POST to the MASA's /requestvoucher. In section 3.4 we say: 3.4. Voucher Response ... If the the join operation is successful, the server response MUST contain an HTTP 200 response code. The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. It seems that since we are using POST, that we ought to answer with an HTTP 201 response code, and include a Location: header at which the voucher could be accessed later on. I am not sure if I'm arguing for returning just the 201, and expect the Registrar to do a GET, although that would be more correct. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk0tyEACgkQgItw+93Q 3WXcswgAlr8JKMSL0+Ztf//nIiTZLzJET7oTn2VeAfzdMP48j83orzLm8ZnYLbni uTG4gd93QdYvZyppvIUwRhfT97yg41fWs+eUOS39GFlyPJgwEV7m3hamW2sOXhQ7 5TtORl132omK72ASCi/m820g4REEuXmqnGNhOlo4xJKIT79riDbXMFipCpujJ0Mf ucwUHqaPd7/6DuZ2XLArsZvwoujjz85itTo7xIOuEl1QmHpvCrrTi5Xli7yu6oMi t5laGXubvwfTiiwaYHQ3dpBGsskvwNSuex2gUXYZYErTRmtPZU1dSfuZL41AFpcZ 1CINBPQWhcqEP1QgMiXwz6YkD8Wylg== =WdGX -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 5 13:57:41 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DBE1293EB; Mon, 5 Jun 2017 13:57:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149669625424.3230.10151704455578829166@ietfa.amsl.com> Date: Mon, 05 Jun 2017 13:57:34 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:57:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-13.txt Pages : 79 Date : 2017-06-05 Abstract: This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-13 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 5 15:22:26 2017 Return-Path: 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 B820E126557 for ; Mon, 5 Jun 2017 15:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ez6Xo-yRgB7w for ; Mon, 5 Jun 2017 15:22:24 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 E9F18120721 for ; Mon, 5 Jun 2017 15:22:23 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 9so89004181pfj.1 for ; Mon, 05 Jun 2017 15:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W15hKp99TCQD9XSZGyJNKQFVqlCR6xmF4dDs/bmy3o0=; b=jy6xwPRn24GNR1tNszWb58GdzqGNRKcDU3oWm7fNaFii0PXEoTUrEPBgtRHEnIR7u7 K7q4SFIBQ3Tp7+hCDM0l/nHA5ASNvn8lSdaLF2djJmnVCkJAOaemCdm7zVDURylwNfEq MSQNHcnbNAGETE+jfYTFouTg2hcCGZbia1BWtxGDKmNUjWQIvq53GvMwivFG87SP0iRj mTDF8/COiQQ3ecza8cxch4f8yCcMoBdBCQzNweMcWNadjzEdEe2wyw9nTWNcoNmurpsl NxwjtT05BVsonX3V3Lq9n9x/DU6c9CBfcCnUdBkDE80DiO++Kiekq6IANB7NpoXwa2jQ Csxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=W15hKp99TCQD9XSZGyJNKQFVqlCR6xmF4dDs/bmy3o0=; b=jdzp19cc4Ukta4adob2xIpPddckuxvBG15m1N+X6lnUwERxglUoGlJQONV0+kuf5ds uimGfJExmzTp06Q3Zf3hnNFDe3XbuokF0zX3QqDkHgqrTeuxUjZTQCuXlmFKtEaMedM2 O6bcRZcaVanN+YJAAqEdt4+E+KCIAaF2ekdxHp8uA7WrGLGDbv5HQHmG27BD6mgdEqaN cGPhCgzYAHkQnXE9/7rYw0KzZKGHyKIQQU6EBoJmHOTGPrXxHkXCm/tE+bh1h78fF6Tn 7/+8ln4b50ufAVMHazBoKkg5e+0cDqnRWTTg2RCBbzf77Y0Tv/cGeeoubTEdQphT0u7y jTSg== X-Gm-Message-State: AODbwcBm1lVEIyrjBJDfA7yaslI/qomuj1KZGRReSC95dclLLdnSkfOV 150+pUG2oPqEkx+w X-Received: by 10.84.217.216 with SMTP id d24mr5517601plj.148.1496701343323; Mon, 05 Jun 2017 15:22:23 -0700 (PDT) Received: from ?IPv6:2406:e001:5517:1:28cc:dc4c:9703:6781? ([2406:e001:5517:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d6sm56749761pfk.90.2017.06.05.15.22.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 15:22:22 -0700 (PDT) To: Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 6 Jun 2017 10:22:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149669625424.3230.10151704455578829166@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 22:22:26 -0000 This version includes a second round of responses to IESG comments. We may not be done yet, but please check the diffs. Here are the main changes: Removed all mention of TLS, including SONN, since it was under- specified. Clarified other text about trust and security model. Banned Rapid Mode when multicast is insecure. Explained use of M_INVALID to support extensibility Corrected details on discovery cache TTL and discovery timeout. Improved description of multicast UDP w.r.t. RFC8085. Clarified when transport connections are opened or closed. Noted that IPPROTO values come from the Protocol Numbers registry Protocol change: Added protocol and port numbers to URI locator. Removed inaccurate text about routing protocols Moved Requirements section to an Appendix. Other editorial and technical clarifications. Regards Brian On 06/06/2017 08:57, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-13.txt > Pages : 79 > Date : 2017-06-05 > > Abstract: > This document specifies the GeneRic Autonomic Signaling Protocol > (GRASP), which enables autonomic nodes and autonomic service agents > to dynamically discover peers, to synchronize state with each other, > and to negotiate parameter settings with each other. GRASP depends > on an external security environment that is described elsewhere. The > technical objectives and parameters for specific application > scenarios are to be described in separate documents. Appendices > briefly discuss requirements for the protocol and existing protocols > with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-13 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Mon Jun 5 16:13:57 2017 Return-Path: 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 47B1812956D for ; Mon, 5 Jun 2017 16:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 m7TmQiW5yJ9W for ; Mon, 5 Jun 2017 16:13:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E48E12956C for ; Mon, 5 Jun 2017 16:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1680; q=dns/txt; s=iport; t=1496704433; x=1497914033; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/ReFdBFAYl43/I0yIIM/u2N+4S2qGZo08CufHxUZBU4=; b=a4qi04AZ/QYbJkZ9hBFrNxA7p5e6eFLryj85Na9IHGLzIEqo2RGzsNtM 6TN/lIQkqd73gldh8EMNizgfOAHFikpmwwUn6S1koK28OI2TpexV8HThm ns5EIlYStrFXsE5IwZR3Q711P7bFTrIgnqRDrvkSazfYCofvVixA/+/w6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABI5TVZ/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0HjgWSBHKVC4IQIQuCQoM2AoMIPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQE4NAsFCwIBCBgeECcLJQIEDgWKIggQr0OMAwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFiEErgkA0hFQWg0KCMQWeMwGHIYwLkXyUXgEfOIEKdBVGEgG?= =?us-ascii?q?Gc3YBiByBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,303,1493683200"; d="scan'208,223";a="431182721" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2017 23:13:50 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v55NDoKt031650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Jun 2017 23:13:50 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Jun 2017 18:13:49 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Mon, 5 Jun 2017 18:13:49 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson CC: anima Thread-Topic: [Anima] 200 vs 201 responses from MASA to Registrar (BRSKI-MASA protocol) Thread-Index: AQHS3Z0U9IHdGraU20SXxz4aPqEFZaIXO16A Date: Mon, 5 Jun 2017 23:13:49 +0000 Message-ID: <5956A92F-A0B9-437E-BB78-B8EBFFE95CBF@cisco.com> References: <15032.1496626978@obiwan.sandelman.ca> In-Reply-To: <15032.1496626978@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <2EA6A8A65DA5F946ADA3EF32DA7FAFB9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] 200 vs 201 responses from MASA to Registrar (BRSKI-MASA protocol) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 23:13:55 -0000 >From https://tools.ietf.org/html/rfc2616#section-9.5 The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. In this case I think the 200 OK code is most appropriate since the server g= enerates a signed voucher as a result of the POST and returns it. The vouch= er is not identified by a URI.=20 - max=20 > On Jun 4, 2017, at 7:42 PM, Michael Richardson wr= ote: >=20 >=20 > Max, in section 3.3 we document the contents that the Registrar will POST= to > the MASA's /requestvoucher. >=20 > In section 3.4 we say: > 3.4. Voucher Response >=20 > ... > If the the join operation is successful, the server response MUST > contain an HTTP 200 response code. The server MUST answer with a > suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. >=20 > It seems that since we are using POST, that we ought to answer with an HT= TP > 201 response code, and include a Location: header at which the voucher co= uld > be accessed later on. I am not sure if I'm arguing for returning just = the > 201, and expect the Registrar to do a GET, although that would be more > correct. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jun 5 16:42:01 2017 Return-Path: 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 930F612ACAF for ; Mon, 5 Jun 2017 16:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Wfq3vqHKKFlU for ; Mon, 5 Jun 2017 16:41:57 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9461C129B48 for ; Mon, 5 Jun 2017 16:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7198; q=dns/txt; s=iport; t=1496706117; x=1497915717; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FiKYj+yNxmoBbs9eHP/tNF4Tg4eUFPZDYskZf3Tp20c=; b=CZx4kFvasUYDEDTH3w/GYcmRtcjvn82A/phbSdtZ5FWRe/yzHC38Bc4S KTEzrf9FlTDwqkUy+ECTDU32/RQBt3rVV4oirdQj6wjoKvA8v6wFFjjtY q9LYdyTFGwa45ad/sY0aeMPAkBrzFeGhJbnum72Ea+pq9Jj7ZeHLpdrHP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAACX6zVZ/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hg2yKGZFiInKHOI1TghAhC4V4AhqCbj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIQQNOgsFCwIBCBgCAiYCAgIfBgsVEAIEDgUJigkDDQgQr?= =?us-ascii?q?SOBbDqHPw2EOAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4c2KwuCNTSCWE6BW4J?= =?us-ascii?q?7MIIxBZ14OwGHIYczhFiCBlWEaYo4izwniHsBHzhLP3QVHCoSAYZzdgGIHIENA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.39,303,1493683200"; d="scan'208";a="436041002" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jun 2017 23:41:56 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v55NfuFc031993 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Jun 2017 23:41:56 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 5 Jun 2017 18:41:55 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Mon, 5 Jun 2017 18:41:55 -0500 From: "Max Pritikin (pritikin)" To: Brian E Carpenter CC: Anima WG Thread-Topic: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt Thread-Index: AQHS3j5snrdVicCNRkqIy/rRKD6arKIXK7kAgAAWPIA= Date: Mon, 5 Jun 2017 23:41:55 +0000 Message-ID: <6E52AD74-4CDA-4520-B59B-D44F970F002A@cisco.com> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.7] Content-Type: text/plain; charset="utf-8" Content-ID: <13E69B41C207784F9168CE5209692A4F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 23:42:00 -0000 DQo+IE9uIEp1biA1LCAyMDE3LCBhdCA0OjIyIFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IFRoaXMgdmVyc2lvbiBpbmNsdWRl cyBhIHNlY29uZCByb3VuZCBvZiByZXNwb25zZXMgdG8gSUVTRyBjb21tZW50cy4NCj4gDQo+IFdl IG1heSBub3QgYmUgZG9uZSB5ZXQsIGJ1dCBwbGVhc2UgY2hlY2sgdGhlIGRpZmZzLiBIZXJlIGFy ZSB0aGUgbWFpbiBjaGFuZ2VzOg0KPiANCj4gICBSZW1vdmVkIGFsbCBtZW50aW9uIG9mIFRMUywg aW5jbHVkaW5nIFNPTk4sIHNpbmNlIGl0IHdhcyB1bmRlci0NCj4gICBzcGVjaWZpZWQuDQoNClRo ZSAtMTMgdGV4dCBtYWludGFpbnMgdGhlIOKAnE1VU1QgYmUgYXV0aGVudGljYXRlZCBhbmQgZW5j cnlwdGlvbiBNVVNUIGJlIHVzZWTigJ0gYnV0IG5vdyB0aGVyZSBpcyBubyBub3JtYXRpdmUgcmVx dWlyZW1lbnQgb24gaG93IHRoaXMgaXMgbWV0LiBDb3JyZWN0PyANCg0KICAgICAgICAgPHQ+QXMg bWVudGlvbmVkIGluIDx4cmVmIHRhcmdldD0iaGlnaGxldmVsIi8+LCBzb21lIEdSQVNQIG9wZXJh dGlvbnMgbWlnaHQgYmUNCiAgICAgICAgIHBlcmZvcm1lZCBhY3Jvc3MgYW4gYWRtaW5pc3RyYXRp dmUgZG9tYWluIGJvdW5kYXJ5IGJ5IG11dHVhbCBhZ3JlZW1lbnQsIHdpdGhvdXQgdGhlDQogICAg ICAgICBiZW5lZml0IG9mIGFuIEFDUC4gU3VjaCBvcGVyYXRpb25zDQogICAgICAgICBNVVNUIGJl IGNvbmZpbmVkIHRvIGEgc2VwYXJhdGUgaW5zdGFuY2Ugb2YgR1JBU1Agd2l0aCBpdHMgb3duIGNv cHkgb2YgYWxsIEdSQVNQDQogICAgICAgICBkYXRhIHN0cnVjdHVyZXMuIE1lc3NhZ2VzIE1VU1Qg YmUgYXV0aGVudGljYXRlZCBhbmQgZW5jcnlwdGlvbiBNVVNUIGJlIHVzZWQuDQogICAgICAgICA8 IS0tIFRMUyA8eHJlZiB0YXJnZXQ9IlJGQzUyNDYiLz4gYW5kIERUTFMgPHhyZWYgdGFyZ2V0PSJS RkM2MzQ3Ii8+IGJhc2VkIG9uIGEgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKQ0KICAg ICAgICAgPHhyZWYgdGFyZ2V0PSJSRkM1MjgwIi8+IGFyZSBSRUNPTU1FTkRFRCBmb3IgdGhpcyBw dXJwb3NlLi0tPg0KICAgICAgICAgRnVydGhlciBkZXRhaWxzIG1heSBiZSBzcGVjaWZpZWQgaW4g ZnV0dXJlIGRvY3VtZW50cy4NCiAgICAgICAgIDwvdD48L3NlY3Rpb24+DQoNCkFzIHN1Y2ggSeKA mW0gbm90IHN1cmUgdGhpcyBzZWN0aW9uIGlzIHByb3ZpZGluZyBhbnkgdmFsdWUgYW55bW9yZS4g UGVyaGFwcyBzaW1wbHkgcmVtb3ZlIGl0PyANCkl0cyBvbmx5IHNheWluZyB0aGF0IHNvbWUgZnV0 dXJlIHdvcmsgbWlnaHQgZGlzY292ZXIgYW4gYWx0ZXJuYXRpdmUgbm9uLWNvbnN0YWluZWQgd2F5 IG9mIHJ1bm5pbmcgR1JBU1AuIFRoaXMgaXMgZWZmZWN0aXZlbHkgYWxyZWFkeSBkaXNjdXNzZWQg YWJvdmU6DQoNCg0KICAgICA8dD5UaGUgQUNQLCBvciBpbiBpdHMgYWJzZW5jZSBhbm90aGVyIHNl Y3VyaXR5IG1lY2hhbmlzbSwgc2V0cyB0aGUgYm91bmRhcnkgd2l0aGluIHdoaWNoIG5vZGVzDQog ICAgICAgICBhcmUgdHJ1c3RlZCBhcyBHUkFTUCBwZWVycy4gQSBHUkFTUCBpbXBsZW1lbnRhdGlv biBNVVNUIHJlZnVzZSB0byBleGVjdXRlIEdSQVNQDQogICAgICAgICBzeW5jaHJvbml6YXRpb24g YW5kIG5lZ290aWF0aW9uIGZ1bmN0aW9ucyBpZiB0aGVyZSBpcyBuZWl0aGVyIGFuIG9wZXJhdGlv bmFsDQogICAgICAgICBBQ1Agbm9yIGFub3RoZXIgc2VjdXJlIGVudmlyb25tZW50LiA8L3Q+DQoN ClFVRVNUSU9OOiBUaGUgQlJTS0kgLTA2IGRyYWZ0IGdlbmVyaWNhbGx5IHJlZmVyZW5jZXMgR1JB U1AgZm9yIGRpc2NvdmVyeSBidXQgb2YgY291cnNlIHdlIGtub3cgdGhhdCB0aGlzIGlzIHByaW9y IHRvIGJlaW5nIGFibGUgdG8gZXN0YWJsaXNoIGFuIEFDUC4gVGhlcmVmb3JlIHdlIG11c3QgYmUg cmVmZXJlbmNpbmcgc29tZXRoaW5nIGluIDxzZWN0aW9uIGFuY2hvcj0ic2VjaW5zdCIgdGl0bGU9 IkNvbnN0cmFpbmVkIEluc3RhbmNlc+KAnT4uIEkgdGhpbmsgdGhlbiB0aGF0IHRoZSBCUlNLSSBk b2N1bWVudCBzaG91bGQgYmUgcmVmZXJlbmNpbmcgc3BlY2lmaWNhbGx5IDxzZWN0aW9uIGFuY2hv cj0ic2VjaW5zdC1kdWxsIiB0aXRsZT0iRGlzY292ZXJ5IFVuc29saWNpdGVkIExpbmstTG9jYWzi gJ0+LiBEbyB5b3UgYWdyZWU/IA0KDQotIG1heA0KDQoNCj4gDQo+ICAgQ2xhcmlmaWVkIG90aGVy IHRleHQgYWJvdXQgdHJ1c3QgYW5kIHNlY3VyaXR5IG1vZGVsLg0KPiANCj4gICBCYW5uZWQgUmFw aWQgTW9kZSB3aGVuIG11bHRpY2FzdCBpcyBpbnNlY3VyZS4NCj4gDQo+ICAgRXhwbGFpbmVkIHVz ZSBvZiBNX0lOVkFMSUQgdG8gc3VwcG9ydCBleHRlbnNpYmlsaXR5DQo+IA0KPiAgIENvcnJlY3Rl ZCBkZXRhaWxzIG9uIGRpc2NvdmVyeSBjYWNoZSBUVEwgYW5kIGRpc2NvdmVyeSB0aW1lb3V0Lg0K PiANCj4gICBJbXByb3ZlZCBkZXNjcmlwdGlvbiBvZiBtdWx0aWNhc3QgVURQIHcuci50LiAgUkZD ODA4NS4NCj4gDQo+ICAgQ2xhcmlmaWVkIHdoZW4gdHJhbnNwb3J0IGNvbm5lY3Rpb25zIGFyZSBv cGVuZWQgb3IgY2xvc2VkLg0KPiANCj4gICBOb3RlZCB0aGF0IElQUFJPVE8gdmFsdWVzIGNvbWUg ZnJvbSB0aGUgUHJvdG9jb2wgTnVtYmVycyByZWdpc3RyeQ0KPiANCj4gICBQcm90b2NvbCBjaGFu Z2U6IEFkZGVkIHByb3RvY29sIGFuZCBwb3J0IG51bWJlcnMgdG8gVVJJIGxvY2F0b3IuDQo+IA0K PiAgIFJlbW92ZWQgaW5hY2N1cmF0ZSB0ZXh0IGFib3V0IHJvdXRpbmcgcHJvdG9jb2xzDQo+IA0K PiAgIE1vdmVkIFJlcXVpcmVtZW50cyBzZWN0aW9uIHRvIGFuIEFwcGVuZGl4Lg0KPiANCj4gICBP dGhlciBlZGl0b3JpYWwgYW5kIHRlY2huaWNhbCBjbGFyaWZpY2F0aW9ucy4NCj4gDQo+IFJlZ2Fy ZHMNCj4gICBCcmlhbg0KPiANCj4gT24gMDYvMDYvMjAxNyAwODo1NywgaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIHdyb3RlOg0KPj4gDQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdXRvbm9taWMgTmV0d29ya2luZyBJbnRlZ3Jh dGVkIE1vZGVsIGFuZCBBcHByb2FjaCBvZiB0aGUgSUVURi4NCj4+IA0KPj4gICAgICAgIFRpdGxl ICAgICAgICAgICA6IEEgR2VuZXJpYyBBdXRvbm9taWMgU2lnbmFsaW5nIFByb3RvY29sIChHUkFT UCkNCj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBDYXJzdGVuIEJvcm1hbm4NCj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICBCcmlhbiBDYXJwZW50ZXINCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICBCaW5nIExpdQ0KPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYW5pbWEt Z3Jhc3AtMTMudHh0DQo+PiAJUGFnZXMgICAgICAgICAgIDogNzkNCj4+IAlEYXRlICAgICAgICAg ICAgOiAyMDE3LTA2LTA1DQo+PiANCj4+IEFic3RyYWN0Og0KPj4gICBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyB0aGUgR2VuZVJpYyBBdXRvbm9taWMgU2lnbmFsaW5nIFByb3RvY29sDQo+PiAgIChH UkFTUCksIHdoaWNoIGVuYWJsZXMgYXV0b25vbWljIG5vZGVzIGFuZCBhdXRvbm9taWMgc2Vydmlj ZSBhZ2VudHMNCj4+ICAgdG8gZHluYW1pY2FsbHkgZGlzY292ZXIgcGVlcnMsIHRvIHN5bmNocm9u aXplIHN0YXRlIHdpdGggZWFjaCBvdGhlciwNCj4+ICAgYW5kIHRvIG5lZ290aWF0ZSBwYXJhbWV0 ZXIgc2V0dGluZ3Mgd2l0aCBlYWNoIG90aGVyLiAgR1JBU1AgZGVwZW5kcw0KPj4gICBvbiBhbiBl eHRlcm5hbCBzZWN1cml0eSBlbnZpcm9ubWVudCB0aGF0IGlzIGRlc2NyaWJlZCBlbHNld2hlcmUu ICBUaGUNCj4+ICAgdGVjaG5pY2FsIG9iamVjdGl2ZXMgYW5kIHBhcmFtZXRlcnMgZm9yIHNwZWNp ZmljIGFwcGxpY2F0aW9uDQo+PiAgIHNjZW5hcmlvcyBhcmUgdG8gYmUgZGVzY3JpYmVkIGluIHNl cGFyYXRlIGRvY3VtZW50cy4gIEFwcGVuZGljZXMNCj4+ICAgYnJpZWZseSBkaXNjdXNzIHJlcXVp cmVtZW50cyBmb3IgdGhlIHByb3RvY29sIGFuZCBleGlzdGluZyBwcm90b2NvbHMNCj4+ICAgd2l0 aCBjb21wYXJhYmxlIGZlYXR1cmVzLg0KPj4gDQo+PiANCj4+IFRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hbmltYS1ncmFzcC8NCj4+IA0KPj4gVGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtZ3Jhc3AtMTMNCj4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1ncmFzcC0xMw0KPj4gDQo+PiBB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hbmltYS1ncmFzcC0xMw0K Pj4gDQo+PiANCj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+PiANCj4+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiANCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQo+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBk aXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4gb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQW5pbWEgbWFpbGluZyBs aXN0DQo+IEFuaW1hQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYW5pbWENCg0K From nobody Mon Jun 5 16:51:18 2017 Return-Path: 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 D2718129B45 for ; Mon, 5 Jun 2017 16:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kQq5wZXtwzFp for ; Mon, 5 Jun 2017 16:51:15 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 A0C77129C39 for ; Mon, 5 Jun 2017 16:51:09 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 83so32249067pfr.0 for ; Mon, 05 Jun 2017 16:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Fljfnv7c0TnkxIJpekb7IR/hGepL1Zg0jqkLK+83MDk=; b=j5k4XI1v2wPaz+3o8m590wOKDwAX4qJCs8BgdTi+lOqnx8f7W9VEiu/AZqsM2OclUt xrxwiGUaNWmyBn54FdZvKAP47Y3wtLO8+dM+5DjUpGkpirI2qbFTquIGzoaXmu2BEh+E A4Z0od4FcXmPrw6QvJAkeADtwNd7w+mUg+yfRuXsb/3lSPEkJausBuZdZZkqnW22rKC4 mRAAo7Iiqe1Pj4KsQrxt7q6jwZ7WYkEEhx1v+1he0eb820RsbMUfltTGhC11HvsarlNr l0tJ6wIx4eDQ4hQTMn/RnYR0/IT0ik3aeZUy4c5GZZA8c4nUSK9O5oHUcvn46onwLeT3 o5CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Fljfnv7c0TnkxIJpekb7IR/hGepL1Zg0jqkLK+83MDk=; b=rYsG7DMtnZSWuStOWdG3szIxo4v9RvIV7isCKYfy3fpivmr0mft0ldEODbsXLqPYJB aJnMjmvtqVm6iHsTIfE11+HjJL49Hb1aihSrVBIs1B6fIhPmplnhhgoAIGGrWE4sWVYs swgcZvx3CnqPJZZTV4TJ0nLyecDgqJwaADhxeoAQEJLxYwOoPICY/F0rkpEMeoYn28EL jr4oxFVqXrSBC0nnrKXK4DRGADnXyEkNG7P0pkxHrp9dd3HwDnEW2C187vqlvp9XhWdq v3XYiQt/QpHBiJGKbYnsNyeqpSamMmFdvRcK8+tGq9UgGOf8YSgnkf55AX5ln8v7v6ES sYbg== X-Gm-Message-State: AODbwcD1pr9IlWsMYItgJBQ362yc3FMjcV0x5pM3Tslit1Bzx/OcsobC rLftg6uaYEjYfv2l X-Received: by 10.84.231.199 with SMTP id g7mr17848272pln.70.1496706669038; Mon, 05 Jun 2017 16:51:09 -0700 (PDT) Received: from ?IPv6:2406:e001:5517:1:28cc:dc4c:9703:6781? ([2406:e001:5517:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 67sm60328688pfn.84.2017.06.05.16.51.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 16:51:08 -0700 (PDT) To: "Max Pritikin (pritikin)" Cc: Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <6E52AD74-4CDA-4520-B59B-D44F970F002A@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5dd51d61-1dff-97d5-abe4-4448c46cd938@gmail.com> Date: Tue, 6 Jun 2017 11:51:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6E52AD74-4CDA-4520-B59B-D44F970F002A@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 23:51:18 -0000 On 06/06/2017 11:41, Max Pritikin (pritikin) wrote: >=20 >> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter wrote: >> >> This version includes a second round of responses to IESG comments. >> >> We may not be done yet, but please check the diffs. Here are the main = changes: >> >> Removed all mention of TLS, including SONN, since it was under- >> specified. >=20 > The -13 text maintains the =E2=80=9CMUST be authenticated and encryptio= n MUST be used=E2=80=9D but now there is no normative requirement on how = this is met. Correct?=20 Correct, because EKR's DISCUSS was partly about the semi-specified usage = with TLS. >=20 > As mentioned in , some GRASP op= erations might be > performed across an administrative domain boundary by mutual a= greement, without the > benefit of an ACP. Such operations > MUST be confined to a separate instance of GRASP with its own = copy of all GRASP > data structures. Messages MUST be authenticated and encryption= MUST be used. > > Further details may be specified in future documents. > > From nobody Tue Jun 6 16:24:31 2017 Return-Path: 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 348C7128D44 for ; Tue, 6 Jun 2017 16:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 JB63K1NMlN7A for ; Tue, 6 Jun 2017 16:24:22 -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 C9CD0128B93 for ; Tue, 6 Jun 2017 16:24:21 -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 8164658C4EC; Wed, 7 Jun 2017 01:24:17 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 65B19B0C1F1; Wed, 7 Jun 2017 01:24:17 +0200 (CEST) Date: Wed, 7 Jun 2017 01:24:17 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:24:25 -0000 Thanks, Brian. Lot of good work. I was surprised to see SONN go away. I do not understand what was considered to be underspecified about it. Everything about that text was IMHO "OK". Now i was not a big fan of the text, but if you do not want to bring it back then IMHO we would need some other equivalent explanation. Just as a reminder: The use-case for SONN is the ACP: - you discover a candidate ACP neighbor with DULL - You build a TLS connection to that candidate ACP neighbor - You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg: IPsec with/without GRE, or dTLS or IP over CoAP or what the heck. - YOu build the ACP. - Then you run the ACP instance of GRASP also across this new ACP leg. The "SONN" instance dies as soon as the ACP is up to the neighbor. I do not think that the "SONN" instance is anything special. Thats why i do not necessarily need to see the text reinstated. But it was nicely listing out the implications of running a separate instance of GRASP across just a single p2p connection. Especially the fact that you wouldn't want to flood any M_DISCOVERY from that instance over to all the interfaces you use for the ACP instance was IMHO well explanatory. If i look at -13 wrt to these considerations: > The protocol SHOULD always run within a secure Autonomic Control > Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is > assumed to carry all messages securely, including link-local > multicast when it is virtualized over the ACP. A GRASP instance MUST > verify whether the ACP is operational. "SHOULD always run within a secure ACP" is not a good sales pitch and might confuse readers how easy it is to proliferate GRASP. In that respect its IMHO factually not correct. Here is how i would propose to write it resolving both the missing SONN text and replacing that above paragraph: GRASP is defined without authentication/encryption. Every ("normal") instance of GRASP MUST either rely on an underlying transport that authenticates (and optionally encrypts) messages from/to GRASP neighbors or the instance of GRASP MUST be constrained. One such constrained instance type of GRASP is defined below - DULL. Devices may need to be able to run more than one normal instances of GRASP, each with a separate set of GRASP neighbors. No data structures of GRASP can be shared across instances (including registered/cached objectives). No messages received from a neighbor in one instance eof GRASP can be forwarded to a neighbor in another instance of GRASP (eg: M_FLOOD messages that forwarded to all GRASP neighbors are forwarded only to all GRASP neighbors in the same instance). In ANI devices, the main instance of GRASP is the ACP instance. The ACP is the transport that performs authentication and encryption of all GRASP messages for this instance. Before the ACP can be built to a neighbor, GRASP may also be used to negotiate how to build the ACP to that neighbor. This negotiation happens over a separate instance of GRASP running over TLS. This is a normal, but separate (from ACP) instance of GRASP. We call such an instance also a (normal) p2p instance, because it operates to only one GRASP neighbor. SUch a p2p instances implementation can be simplified because a range of functions do automatically not apply to it (forwarding of M_FLOOD messages, redirect messages, ...). (aka: normal p2p instance would be exactly what SONN was). > Network interfaces could be at different security levels, in > particular being part of the ACP or not. All the interfaces > supported by a given GRASP instance MUST be at the same security > level. I am hesitant about the term "security level" that you introduce here. I would not know how to define that term. "Clarence, this interface has Clearance" ? ;-)) What would happen if you simply deleted the whole paragraph ? (but took my text above) ? > The ACP, or in its absence another security mechanism, sets the > boundary within which nodes are trusted as GRASP peers. A GRASP > implementation MUST refuse to execute GRASP synchronization and > negotiation functions if there is neither an operational ACP nor > another secure environment. So... IMHO, it would be great if we had some clear terminology, eg: GRASP domain: a connected graph of nodes. Each node in the graph is a (normal) instance of GRASP running on a different (virtual) device. GRASP neighbors: grasp nodes to which an instance has an edge in the graph GRASP peers: all nodes (GRASP instances) in the graph Instances of GRASP expect that they can unicast send/receive packets to all peers. GRASP does not need to know the addresses of neighbors because it addresses neighbors via link-local multicast (M_DISCOVERY and M_FLOOD). The section 2.5.2 about constrained instances : With my proposed text qove IMHO you would not need any additional text for the non-ACP case. I also do no not understand where outside of DULL you would need the consideration of not doing Rapid Mode. Cheers Toerless On Tue, Jun 06, 2017 at 10:22:20AM +1200, Brian E Carpenter wrote: > This version includes a second round of responses to IESG comments. > > We may not be done yet, but please check the diffs. Here are the main changes: > > Removed all mention of TLS, including SONN, since it was under- > specified. > > Clarified other text about trust and security model. > > Banned Rapid Mode when multicast is insecure. > > Explained use of M_INVALID to support extensibility > > Corrected details on discovery cache TTL and discovery timeout. > > Improved description of multicast UDP w.r.t. RFC8085. > > Clarified when transport connections are opened or closed. > > Noted that IPPROTO values come from the Protocol Numbers registry > > Protocol change: Added protocol and port numbers to URI locator. > > Removed inaccurate text about routing protocols > > Moved Requirements section to an Appendix. > > Other editorial and technical clarifications. > > Regards > Brian > > On 06/06/2017 08:57, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > > > Title : A Generic Autonomic Signaling Protocol (GRASP) > > Authors : Carsten Bormann > > Brian Carpenter > > Bing Liu > > Filename : draft-ietf-anima-grasp-13.txt > > Pages : 79 > > Date : 2017-06-05 > > > > Abstract: > > This document specifies the GeneRic Autonomic Signaling Protocol > > (GRASP), which enables autonomic nodes and autonomic service agents > > to dynamically discover peers, to synchronize state with each other, > > and to negotiate parameter settings with each other. GRASP depends > > on an external security environment that is described elsewhere. The > > technical objectives and parameters for specific application > > scenarios are to be described in separate documents. Appendices > > briefly discuss requirements for the protocol and existing protocols > > with comparable features. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-anima-grasp-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 6 17:02:00 2017 Return-Path: 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 7557B126E01 for ; Tue, 6 Jun 2017 17:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 7o9YXDHIcdbG for ; Tue, 6 Jun 2017 17:01:56 -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 50284126DED for ; Tue, 6 Jun 2017 17:01:56 -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 52B0D58C4EC; Wed, 7 Jun 2017 02:01:52 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3AFE2B0C1FC; Wed, 7 Jun 2017 02:01:52 +0200 (CEST) Date: Wed, 7 Jun 2017 02:01:52 +0200 From: Toerless Eckert To: Brian E Carpenter , pthubert@faui40p.informatik.uni-erlangen.de Cc: Michael Richardson , Toerless Eckert , anima Message-ID: <20170607000152.GK12427@faui40p.informatik.uni-erlangen.de> References: <22673.1491420302@obiwan.sandelman.ca> <20170406190527.GA22731@faui40p.informatik.uni-erlangen.de> <25101.1491514303@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] draft-ietf-anima-autonomic-control-plane-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 00:01:58 -0000 Adding Pascal explicity because i may be confused about various RPL things here: I may be wrong, but it looks to me as if MichaelRs comments and reference to this new draft about RPL IPinIP header stuff makes it sound as if we MUST somehow support these IPinIP headers in ACP: https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-10&url2=draft-ietf-roll-useofrplinfo-14 Also, during the last IETF, i think MichaelR said something to the extend that the "profile" defined for RPL via the latest -06 version should rather go into some form of RPL profile draft.... But if i remember correctly, Pascal told me there is no such "RPPL profile" draft format. When i discussed with Pascal, he reconfirmed to me that the approach/profile choosen for RPL in the Cisco IOS implementation of ACP should be perfetly RPL standards compliant - and it does not do any IPinIP header extensions. This is something i would prefer as the mandatory minimum ACP requirements because i am fearful of asking all type of equipment to support RPL routing protocol specific IPinIP header processing. I am not even sure if i could today expect to get this IPinIP header processing in all linux that i might expect on native ANI devices, but given how we're unlikely allowed for some intervening device to insert/delete those headers, the use of IPinIP headers would eliminate the option to easily set up extensions ("autonomic connect") to the ACP in a NOC - into pre-existing management devices with the "What The F**K is RPL" TCP/IP stack. Not using IPinIP headers does of course come at the limitation of - if i understand it correctly - a single instance with a single (active) root. As long as we can have automatic root election so that we have root redundancy, i think this is a sufficient minimum functionality for ACP. It would be great to bring in as much as possible of that IPinIP support via SHOULD, but i am not 100% clear how this can be done: - It seems to be easy to make IPinIP support SHOULD for endpoints. Such an endpoint could only use the default instance/root of RPL. Right ? - It is less clear to me if/how its possible to introduce partial support for IPinIP on transit nodes. I am hping that RPL can automatically figure out that additional instances/dodags can only work across paths where all transit nodes support IPinIP. Then the problem is solved. If this si something RPL can not singnal, then it seems as if a transit node without IPinIP support would kill non-default instance/transit paths. - I am very interested to make non IPinIP capable transit nodes sufficient for MUST ACP requirements because i am quite sure that a relevant part of HW accelerated forwarding engines will not support IPinIP routing, so any mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO would make me ask to rethink the choice of ACP default routing protocol. So... Q1: Do we agree on this direction ? Q2: How can we finalize the sufficient/necessary text mods to ACP to express this ? (profile definition etc..) Thanks a lot! Toerless On Fri, Apr 07, 2017 at 10:04:21AM +1200, Brian E Carpenter wrote: > Comment at the end.. > > On 07/04/2017 09:31, Michael Richardson wrote: > > > > Brian E Carpenter wrote: > > >> Unless RPL for the ACP or any future ACP mechanism do require reception and processing > > >> of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 packet targeted > > >> to their ACP address. > > > > > I'm still not clear what the attack is. This rule seems to be saying "don't act as a > > > protocol 41 tunnel end point by default." But who would do that anyway? If you aren't > > > configured as a tunnel end point, protocol 41 is /dev/null. If you are configured > > > as a tunnel end point, you know what to do with the packet by definition. Don't act > > > as a GRE end point by default either. In fact, if you get any packet you don't understand, > > > drop it. > > > > Because we have to insert RPI header with an IPIP header, that means that > > every RPL router node needs to be will to accept IPIP packets addressed to > > it. It should find IPouter.dst = ME, and IPinner.dst = ME. > > (with IPouter.src being the device that inserted the IPIP header, > > and IPinner.src being the original source of the packet). > > > > *IF* the ACP router has some "clients" (i.e. VMs inside it), it may want > > to do IPIP encap/decap for the client machines. > > > > >> When reception/processing of IPv6-in-IPv6 packets is required for RPL, only > > >> IPv6-in-IPv6 packets with an ACP address from the same autonomic domain should be > > >> accepted. > > > > > Yes. But it does seem a bit obvious, frankly. Also, I can't imagine a use case. > > > I can imagine a use case where packets addressed from and to an ACP address arrive > > > encapsulated in a non-ACP packet, because we are connecting two ACP clouds > > > over a non-ACP tunnel, but in that case the tunnel end point will not be visible > > > in the ACP VRF anyway. > > > > Agreed. > > The point in the security considerations is to make it really clear that > > traffic should not pass via the ACP to the Internet. > > > > Imagine a compromised machine (a desktop in the NOC!!!) that can send IPIP > > traffic via the ACP to a backbone router, which will then decapsulate it > > (ignoring our words), and sending it out to the Internet at 100Gb/s speeds? > > This is the issue that I want to make sure the "considerations" point out. > > Absolutely. And it could be a BYOD in the NOC that manages to join the ACP, > even. We really do need to tackle node and ASA authorization in Phase 2. > > Brian From nobody Tue Jun 6 17:02:48 2017 Return-Path: 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 28624126E01 for ; Tue, 6 Jun 2017 17:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 7rCqE0WoPCaM for ; Tue, 6 Jun 2017 17:02:45 -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 ED1AC126DED for ; Tue, 6 Jun 2017 17:02:44 -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 368A758C4EC; Wed, 7 Jun 2017 02:02:41 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1C482B0C1FC; Wed, 7 Jun 2017 02:02:40 +0200 (CEST) Date: Wed, 7 Jun 2017 02:02:40 +0200 From: Toerless Eckert To: Brian E Carpenter , pthubert@cisco.com Cc: Michael Richardson , Toerless Eckert , anima Message-ID: <20170607000240.GA23319@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] draft-ietf-anima-autonomic-control-plane-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 00:02:47 -0000 [oops. resending with fixed address for pascal] Adding Pascal explicity because i may be confused about various RPL things here: I may be wrong, but it looks to me as if MichaelRs comments and reference to this new draft about RPL IPinIP header stuff makes it sound as if we MUST somehow support these IPinIP headers in ACP: https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-10&url2=draft-ietf-roll-useofrplinfo-14 Also, during the last IETF, i think MichaelR said something to the extend that the "profile" defined for RPL via the latest -06 version should rather go into some form of RPL profile draft.... But if i remember correctly, Pascal told me there is no such "RPPL profile" draft format. When i discussed with Pascal, he reconfirmed to me that the approach/profile choosen for RPL in the Cisco IOS implementation of ACP should be perfetly RPL standards compliant - and it does not do any IPinIP header extensions. This is something i would prefer as the mandatory minimum ACP requirements because i am fearful of asking all type of equipment to support RPL routing protocol specific IPinIP header processing. I am not even sure if i could today expect to get this IPinIP header processing in all linux that i might expect on native ANI devices, but given how we're unlikely allowed for some intervening device to insert/delete those headers, the use of IPinIP headers would eliminate the option to easily set up extensions ("autonomic connect") to the ACP in a NOC - into pre-existing management devices with the "What The F**K is RPL" TCP/IP stack. Not using IPinIP headers does of course come at the limitation of - if i understand it correctly - a single instance with a single (active) root. As long as we can have automatic root election so that we have root redundancy, i think this is a sufficient minimum functionality for ACP. It would be great to bring in as much as possible of that IPinIP support via SHOULD, but i am not 100% clear how this can be done: - It seems to be easy to make IPinIP support SHOULD for endpoints. Such an endpoint could only use the default instance/root of RPL. Right ? - It is less clear to me if/how its possible to introduce partial support for IPinIP on transit nodes. I am hping that RPL can automatically figure out that additional instances/dodags can only work across paths where all transit nodes support IPinIP. Then the problem is solved. If this si something RPL can not singnal, then it seems as if a transit node without IPinIP support would kill non-default instance/transit paths. - I am very interested to make non IPinIP capable transit nodes sufficient for MUST ACP requirements because i am quite sure that a relevant part of HW accelerated forwarding engines will not support IPinIP routing, so any mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO would make me ask to rethink the choice of ACP default routing protocol. So... Q1: Do we agree on this direction ? Q2: How can we finalize the sufficient/necessary text mods to ACP to express this ? (profile definition etc..) Thanks a lot! Toerless On Fri, Apr 07, 2017 at 10:04:21AM +1200, Brian E Carpenter wrote: > Comment at the end.. > > On 07/04/2017 09:31, Michael Richardson wrote: > > > > Brian E Carpenter wrote: > > >> Unless RPL for the ACP or any future ACP mechanism do require reception and processing > > >> of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 packet targeted > > >> to their ACP address. > > > > > I'm still not clear what the attack is. This rule seems to be saying "don't act as a > > > protocol 41 tunnel end point by default." But who would do that anyway? If you aren't > > > configured as a tunnel end point, protocol 41 is /dev/null. If you are configured > > > as a tunnel end point, you know what to do with the packet by definition. Don't act > > > as a GRE end point by default either. In fact, if you get any packet you don't understand, > > > drop it. > > > > Because we have to insert RPI header with an IPIP header, that means that > > every RPL router node needs to be will to accept IPIP packets addressed to > > it. It should find IPouter.dst = ME, and IPinner.dst = ME. > > (with IPouter.src being the device that inserted the IPIP header, > > and IPinner.src being the original source of the packet). > > > > *IF* the ACP router has some "clients" (i.e. VMs inside it), it may want > > to do IPIP encap/decap for the client machines. > > > > >> When reception/processing of IPv6-in-IPv6 packets is required for RPL, only > > >> IPv6-in-IPv6 packets with an ACP address from the same autonomic domain should be > > >> accepted. > > > > > Yes. But it does seem a bit obvious, frankly. Also, I can't imagine a use case. > > > I can imagine a use case where packets addressed from and to an ACP address arrive > > > encapsulated in a non-ACP packet, because we are connecting two ACP clouds > > > over a non-ACP tunnel, but in that case the tunnel end point will not be visible > > > in the ACP VRF anyway. > > > > Agreed. > > The point in the security considerations is to make it really clear that > > traffic should not pass via the ACP to the Internet. > > > > Imagine a compromised machine (a desktop in the NOC!!!) that can send IPIP > > traffic via the ACP to a backbone router, which will then decapsulate it > > (ignoring our words), and sending it out to the Internet at 100Gb/s speeds? > > This is the issue that I want to make sure the "considerations" point out. > > Absolutely. And it could be a BYOD in the NOC that manages to join the ACP, > even. We really do need to tackle node and ASA authorization in Phase 2. > > Brian From nobody Tue Jun 6 17:10:27 2017 Return-Path: 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 27057126E01; Tue, 6 Jun 2017 17:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 ofCMk-0DsoQK; Tue, 6 Jun 2017 17:10:14 -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 01CF7126DD9; Tue, 6 Jun 2017 17:10:13 -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 9194258C4EC; Wed, 7 Jun 2017 02:10:10 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 80ED4B0C1FE; Wed, 7 Jun 2017 02:10:10 +0200 (CEST) Date: Wed, 7 Jun 2017 02:10:10 +0200 From: Toerless Eckert To: Brian E Carpenter , iesg@ietf.org, anima@ietf.org Message-ID: <20170607001010.GC23319@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt (IESG comment) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 00:10:16 -0000 (slight rant about encryption, sorry, also Ccing IESG because this seems to have resulted from IESG feedback): Which IESG feedback did raise the need to mandate encryption for GRASP in the text block you propose ? If this does stem from IESG feedback, i would love to know any appropriate IETF security guideline (RFC?) that defines this MUST as recommended for network signaling (such as GRASP). IMHO: I think its bogus and an annoying proliferation of PerPass concerns into totally different domains than end-user data. I think most network signaling works best if it is NOT encrypted by default because it easily breaks monitoring, diagnostics, troubleshooting, analytics, optimizations. IMHO, networking signaling transport MUST support authentication and SHOULD enable this by default. It MUST support enrcyption but SHOULD select the default for encryption (off/on) based on weighting monitoring, diagnostics, troublehsooting, analytics and optimizations benefits vs. data privacy concerns (eg: understood and documented increase in attack surface). Example: - TLS with zero-encrypt is IMHO a good default for network signaling (such as GRASP). - ACP is a great solution to enable encryption by default because the zero-touch handling of domain certificates does allow to easily establish trust relationships for "third-party" monitoring, diagnostics, troubleshooting, analytics and optimization functions. Thanks Toerless > On Jun 5, 2017, at 4:22 PM, Brian E Carpenter wrote: > > This version includes a second round of responses to IESG comments. > > We may not be done yet, but please check the diffs. Here are the main changes: > [...] > > As mentioned in , some GRASP operations might be > performed across an administrative domain boundary by mutual agreement, without the > benefit of an ACP. Such operations > MUST be confined to a separate instance of GRASP with its own copy of all GRASP > data structures. Messages MUST be authenticated and encryption MUST be used. > > Further details may be specified in future documents. > > -- --- tte@cs.fau.de From nobody Tue Jun 6 17:11:12 2017 Return-Path: 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 A7A19128961; Tue, 6 Jun 2017 17:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 etvigPKi5uEN; Tue, 6 Jun 2017 17:11:09 -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 A9A33126DED; Tue, 6 Jun 2017 17:11:08 -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 DF1F258C4F5; Wed, 7 Jun 2017 02:11:04 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id CC082B0C1FE; Wed, 7 Jun 2017 02:11:04 +0200 (CEST) Date: Wed, 7 Jun 2017 02:11:04 +0200 From: Toerless Eckert To: anima@ietf.org, draft-ietf-anima-prefix-management@ietf.org Message-ID: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] [draft-ietf-anima-prefix-management-03] review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 00:11:11 -0000 [darn, second mail header typo on my side. sorry.] Dear authors Some feedback for the PD draft: 1. Relationship to DHCPv6 PD: The note in 4.3 makes it sound as if there is a concern by the authors that this proposal could potentially be seen as being in conflict with DHCPv6. I am not sure about a practical case where this case would ever be a concern. If the authors can think of such a case, then it would be good to add sentences explaining that case. Otherwise maybe revisit this concern. IMHO ANIMA-PD could nicely integrate/expand DHCP-PD: RFC3633 (DHCPv6 PD) abstract says: "..delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary.." ^^^^^^^^^^^^^^^^^^^^^^^ To validate the ANI, IMHO we just need to show how to use GRASP within a domain, eg: not across an administrative boundary. == no overlap with the declared intended use of DHCPv6 PD. Instead i could rather see ANI/GRASP used inside the domain and then DHCP/DHCPv6-PD be used on the edge of the domain to client (non-ANI devices). 2. Prefix Management Parameters I do not understand from the text what prefix length is described in 6.1. Maybe i am misunderstanding how the proposed PD mechanism should work, but in my understanding, a device has at least TWO type of prefixes: GRASP/(+DHCP-PD) +---------+ requested | router | ------ Interfaces with assigned prefixes <-----------------> | with | ... "Assigned prefix-length 'APL'" prefix-length | PM-ASA | ------ or 'RPL' +---------+ GRASP/DHCP-PD requests via downstream PM-ASA If RPL == APL, then there is no prefix aggregation. This may be acceptable (==scale well enough) at GRASP/DHCP-PD signaling level. If thats what the authors have in mind then that should be written explicitly. Note that if RPL == APL, then this will result in more prefixes at the routing level because all APLs can be from different prefixes and may not be aggregateable. IMHO, achieving aggregation and managing that via PM-ASA would be a big benefit of PM-ASA. Aka: If the document intends to support RPL < APL, then that should be better described. For example, section 6.1 could for each role have simply those two parameters (requested_prefix_length, assigned_prefix_length): [ [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_length", 56] ], [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_length", 64] ], [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ] ] Thre assigned_prefix_length is of course most important if the downstream is an interface where the router with PM-ASA needs to configure the prefix and the addresses are assigned by SLAAC or DHCP from the router itself. If the downstream is not a local interface but requests from PM-ASA, then the prefix can be determined by the downstream PM-ASA. 3. Mobile network roles section 6.1: Please expand (in parenthesis) the abbreviations you use on first use, eg: IPRAN, RNC in section 6.1. Please check any other unexplained TLAs in the document. A good picture with RSG, ASG, CSG would be great and help. Especially if you want to take the prior suggestion into account of what prefix length would be required in which role device. 4. If you read the point 5 below, i think there are a lot of options how PDs with ASAs can be done. All of these options would require further details such as more GRASP objective parameters, more description of the ASA state machinery, the individual GRASP negotiation steps etc. I do not think we want to go through all that detail work because that is IMHO easier done by first building prototypes, and instead having the document rather be a "framework" or "architecture document instead of an ASA functional specification. To that end, it would IMHO be prudent to say so, for example before the last two paragraphs of the introduction: proposed text, as 3rd last paragraph of introduction: This document is not a functional specification of the proposed autonomic function "prefix management" or all detail all the aspects of GRASP objective parameters and ASA procedures necessary to achieve all the different options of building a complete system. Instead it describes the architectural framework utilizing the components of the ANI and outlines the different deployment options and aspects and defines simple type of objectives in GRASP to start building the system as well as some basic parameter examples. 5. Abstract deployment pictures / solution overview: I think it would help in understanding the document if it would include a logical deployment model pictures with explanations of the target deployment models. Ideally comparing to how this is done with DHCP. For example: In the introduction, there are some high level, very suggestive statements about limitations of DHCP (non-autonomicity). Its really hard to detail why/how the PD solution improves over this without a more explicit comparison of some DHCP deployment model example and a PD deployment model example. So, i have appended two proposed texts: 5.1 for what i understand to be the two most common DHCP deployment models, and 5.2 for what i understand to be the proposed PD deployment model. I would strongly suggest to consider using 5.2 in the document - or something equivalent. Otherwise its IMHO hard to follow / understand how PD is meant to work. Brian Carpenter already proved the feedback that a section like 5.1 might be contentuous and also incomplete because centralized address management has a wide range of options not only limited to DHCP but also involving Radius and other protocols - and there is even a whole working group in the making (CASM - coordinated address space management). So maybe my proposed 5.1 would better go into an appended with sufficient preface stating exactly that these are just examples, and that there are many more deployment models, and that there are no current IETF recommendations or documents laying out such complete deployment pictures. (which IMHO is exactly one of the may problems). If folks feel that any more explicit description of even exemplary DHCP deployment models is inappropriate because it would get too contentuous, then its almost impossible to make statements about the limitations about DHCP in the introduction. But without trying to give an example and getting backpressure from reviewers, its IMHO a dead end:wq 5.1. Address & Prefix management with DHCP edge dynamic, "netconf/YANG" interfaces <-----------------> +-------------+ +-------------+ <- telemetry | edge router/|+ ------ +--------+ |config server| ..... Domain .... | DHCP server || ... | CPE |-+ LANs +-------------+ +-------------+| ------ +--------+ | (----| ) +-------------+ DHCP/ +---------+ DHCPv6 / PD Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD (RF3633) for IPv6 capable CPE that are router and have LANs behind them. This requires various coordination functions via some backend system depicted as "config server": The address prefixes on the edge interfaces should be slightly larger than required for the number of CPE connected so that the overall address space is best used. The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router. If too fine grained prefixes are used, this will result in large routing tables across the "Domain". If too coase grained prefixes are used, address space is wasted. There is no standard describing algorithms for how config servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization. There are currently no complete YANG models that a config server could use to perform these actions (including telemetry of assigned adddresses from such distributed DHCP servers). For example, a YANG model for controlling DHCP server operations is still in draft (draft-liu-dhc-dhcp-yang-model-06). Due to these and other problems of the above model, the more common DHCP deployment model is as follows: edge +-------------+ initial, "CLI" interfaces |config server| -----------------> +-------------+ +-------------+ | edge router/|-+ ------ +--------+ | ..... Domain .... | DHCP relay | | ... | CPE |-+ LANs +-------------+ +-------------+ | ------ +--------+ | (----| ) |DHCP server | +--------------+ DHCP/ +---------+ +-------------+ DHCPv6 / PD Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber identifying options into DHCP requests from CPE (eg: rfc3046, rfc6221), the DHCP server has complete policies for address assignments and prefixes useable on every edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address/address-prefix into the routing table of the edge router which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the Domain (the same. There is no comprehensive standardization of these solutions. RFC3633 section 14. for example simply refers to "a [non-defined] protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router". 5.2 Prefix management with ANI/GRASP With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model is intended to look as follows: |<................... ANI Domain / ACP...................>| (...) ............-> Roles | v "Edge routers" GRASP parameter +----------------+ Network wide parameters/policy | PM-ASA | downstream interfaces | |(DHCP-functions)| ------ v "central device" +----------------+ +-------+ ^ +--------+ |PM-ASA | <................... GRASP .... .... | CPE |-+ ( LANs ) +-------+ . v |(PM-ASA)| | ----| . +........+ +----------------+ +--------+ | +...........+ . PM-ASA . | PM-ASA | ------ +---------+ .DHCP server. +........+ |(DHCP-functions)| SLAAC / +...........+ "intermediate router"+----------------+ DHCP / DHCP-pd The network runs an ANI domain with ACP between some central device (eg: router or ANI enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between the devices and enables the use of GRASP not only for p2p communication, but also for distribution/flooding. The central devices and edge-routers run software to support this documents autonomic IPv6 edge prefix management (PM). In the autonomic networking terminology, such software are called "Autonomic Service Agents" (ASA). The ASA for Prefix Management are called PM-ASA in this document and form together the Autonomic Prefix Management Function. Edge-routers can have different roles based on the type and number of CPE attaching to them. Consider edge routers could be RSG, ASG CSG in mobile aggregation networks (see Section 6.1). Mechanisms outside the scope of this document make routers aware of their role. 1. In a minimum Prefix Managmeent solution, the central device uses the "PrefixManager.Params" GRASP Objective introduced in this document to disseminate network wide, per-role parameters to edge routers. The PM-ASA use the parameters applying to its role to locallly "configuring" pre-existing addressing functions. Because PM-ASA do not manage the dynamic assignment of actual IPv6 address prefixes in this case, the following options can be considered: 1.a The edge router connects via downstream interfaces to (host) CPE that each require an address. The PM-ASA sets up for each such interface a DHCP requesting router (according to RFC3633) to request an IPv6 prefix for the interface. The routers address on the downstream interface can be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to RFC3633) is required. Its address can be another parameter from the GRASP Objective. 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in 1.a. 2. In a solution without a central DHCP server, the PM-ASA on the edge routers do not only learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device. These addresses are then used by the PM-ASA on the edge routers to edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It need to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded. This solution is quite similar to the initial described IPv6 DHCP deployment model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provides the automation to make this approach work more easily than it is possible today. 3. The address pool(s) from which prefixes are allocated do not need to be taken all from one central location. Edge router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further (smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can not get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed. 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built (indicated in he picture via a dotted intermediate router). This would require additional parameters to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the prefixes can be delegated. This is not detailed further below. 5. In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE"), then GRASP will extend into the actual customer sites and can equally run a PM-ASA. All the options described in points 1..4 above would then apply to the CPE as the edge router with the mayor changes being that a) a CPE router will most likley not need to run DHCPv6 PD itself, but only DHCP address assignment, b) The edge routers to which the CPE connect would most likely become ideal places to run a hierarchical instance of PD-ASAs on as outlined in point 1. From nobody Tue Jun 6 17:39:09 2017 Return-Path: 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 BF7B9127286 for ; Tue, 6 Jun 2017 17:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Xk6h-xeopycU for ; Tue, 6 Jun 2017 17:39:05 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 A6FE6126DD9 for ; Tue, 6 Jun 2017 17:39:05 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 83so45707167pfr.0 for ; Tue, 06 Jun 2017 17:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XCXPd9hZMmAaNliw0A9Ej+L2Awf0jqebEwAMxVY6KqI=; b=iTK5Fvln0DcjxTuO8Lt3yrQsuXDCN+vdS2U+R5Hop4ky6/2+Svt6LKn+1vzJoiGHTK 4DMrO+ULzDXoAML4Gp5S7+EZ/n8VFROl12IbyjE9I4LdB6+dOr9kOufZWlc+05gL9dfe 4CKeeN2o42BnHqloQ4z/nTz0VAEOiuKHkggxSELDwGPwCtxa0GR7eErfF37mGQ5jveMf G55ph+x2eqvji5tA5l/pum3cb/vbA7sKvwUyvr4z4aVonvlZCDtKTFTLjsHwnpBAiec1 1Nw7e+5dAbLcSNR1QM3YQvzwCCV9GcgT5X6kc/sQcM0/Wi+Hij9VHi6W1m3yAhaucHhg ZK3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XCXPd9hZMmAaNliw0A9Ej+L2Awf0jqebEwAMxVY6KqI=; b=dBZFuBJHW5Hco4Cjva6g+ZScMO32PhiKu/YCpMWAl1aj9uTl6ZC95vnKE8tPAr/dQz j8D9YzovYO38t6lTG6sKGaFi96yebhBnst9Ofxd81oQ152KVreHa9on3pfJo1MFTgG7N +E1bYfY3HXBIe9MdS9BhsFOiU9YN6nQSjcKkHqFRMbK8eKHNqeLzMjSEUpusIDeltZ9w 9KFHzH+OhEJqGsA44JR9O0gQTSMdA7uk1s3N6gzUniP1HBs8I7kHu0NBfMpQuNiriSkR lVUM1I+zmoZ+WyjhRNJW5WCjkmHuulxSsA//LuMu13j406GfDe6Pu/fQS8Hy8mPzk1Hu wo6w== X-Gm-Message-State: AODbwcBe6XdK5DbhXNkEzeR3IP+ls4XTNMEe7GQ5njdObSuQLm3dOvZX g0hE2NRCtdkV5GaC X-Received: by 10.84.217.90 with SMTP id e26mr13289083plj.161.1496795944949; Tue, 06 Jun 2017 17:39:04 -0700 (PDT) Received: from [130.216.38.7] (sc-cs-316051.cs.auckland.ac.nz. [130.216.38.7]) by smtp.gmail.com with ESMTPSA id l4sm52462pgn.34.2017.06.06.17.39.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 17:39:04 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> Date: Wed, 7 Jun 2017 12:38:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 00:39:08 -0000 On 07/06/2017 11:24, Toerless Eckert wrote: > Thanks, Brian. Lot of good work. > > I was surprised to see SONN go away. I do not understand what was considered to be > underspecified about it. Everything about that text was IMHO "OK". Now i was > not a big fan of the text, but if you do not want to bring it back then IMHO > we would need some other equivalent explanation. EKR didn't like the loose mention of TLS. It would be perfectly fine to revive SONN in the ACP draft or even in a separate ACP 'profile' draft. But I had the impression that IPSec was the preferred model for ACP. In either case you will have exactly the same discussion with EKR, and he's probably right ;-). In other words you have to fully describe how cert/key management works. I think DULL is more fundamental to GRASP and it doesn't contain any undefined mechanism. A reminder: assuming GRASP is approved by the IESG, it will block at the RFC Editor until the ACP is also approved. So I think it makes sense to focus all the security details in the ACP draft, to minimise loops between the documents. > > Just as a reminder: The use-case for SONN is the ACP: > > - you discover a candidate ACP neighbor with DULL > - You build a TLS connection to that candidate ACP neighbor > - You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg: IPsec > with/without GRE, or dTLS or IP over CoAP or what the heck. > - YOu build the ACP. > - Then you run the ACP instance of GRASP also across this new ACP leg. > The "SONN" instance dies as soon as the ACP is up to the neighbor. > > I do not think that the "SONN" instance is anything special. Thats why i do not > necessarily need to see the text reinstated. But it was nicely listing out the > implications of running a separate instance of GRASP across just a single p2p > connection. Especially the fact that you wouldn't want to flood any M_DISCOVERY > from that instance over to all the interfaces you use for the ACP instance was > IMHO well explanatory. > > If i look at -13 wrt to these considerations: > > > The protocol SHOULD always run within a secure Autonomic Control > > Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is > > assumed to carry all messages securely, including link-local > > multicast when it is virtualized over the ACP. A GRASP instance MUST > > verify whether the ACP is operational. > > "SHOULD always run within a secure ACP" is not a good sales pitch > and might confuse readers how easy it is to proliferate GRASP. In > that respect its IMHO factually not correct. > > Here is how i would propose to write it resolving both the missing SONN text > and replacing that above paragraph: > > GRASP is defined without authentication/encryption. Every ("normal") instance of GRASP MUST > either rely on an underlying transport that authenticates (and optionally encrypts) > messages from/to GRASP neighbors or the instance of GRASP MUST be constrained. One such > constrained instance type of GRASP is defined below - DULL. > > Devices may need to be able to run more than one normal instances of GRASP, each with > a separate set of GRASP neighbors. No data structures of GRASP can be shared across > instances (including registered/cached objectives). No messages received from a > neighbor in one instance eof GRASP can be forwarded to a neighbor in another instance > of GRASP (eg: M_FLOOD messages that forwarded to all GRASP neighbors are forwarded > only to all GRASP neighbors in the same instance). > > In ANI devices, the main instance of GRASP is the ACP instance. The ACP is the transport > that performs authentication and encryption of all GRASP messages for this instance. > > Before the ACP can be built to a neighbor, GRASP may also be used to negotiate > how to build the ACP to that neighbor. This negotiation happens over a separate > instance of GRASP running over TLS. This is a normal, but separate (from ACP) instance > of GRASP. We call such an instance also a (normal) p2p instance, because it operates > to only one GRASP neighbor. SUch a p2p instances implementation can be simplified > because a range of functions do automatically not apply to it (forwarding of M_FLOOD > messages, redirect messages, ...). > > (aka: normal p2p instance would be exactly what SONN was). I think your text and the existing text intend to say the same thing. But do you really want to go back to the IESG with a completely new text? Can we wait and see what the DISCUSSing ADs think about the changes so far? > > Network interfaces could be at different security levels, in > > particular being part of the ACP or not. All the interfaces > > supported by a given GRASP instance MUST be at the same security > > level. > > I am hesitant about the term "security level" that you introduce here. I would not > know how to define that term. "Clarence, this interface has Clearance" ? ;-)) Hmm. That text first appeared in draft-ietf-anima-grasp-08. To me it seems self-defining, but if it doesn't seem that way to you, it should be retouched. There's a slight discrepancy between the way the current text uses "instance" (a GRASP instance in a single node) and your usage above (the set of such instances that share a security regime). So a bit more terminology tweaking is still needed. > What would happen if you simply deleted the whole paragraph ? (but took my text above) ? > > > The ACP, or in its absence another security mechanism, sets the > > boundary within which nodes are trusted as GRASP peers. A GRASP > > implementation MUST refuse to execute GRASP synchronization and > > negotiation functions if there is neither an operational ACP nor > > another secure environment. > > So... IMHO, it would be great if we had some clear terminology, eg: > > GRASP domain: a connected graph of nodes. Each node in the graph is a (normal) > instance of GRASP running on a different (virtual) device. I have always ducked this because I understood that discussing domains and domain boundaries was future work for Anima. But logically, that makes sense. > GRASP neighbors: grasp nodes to which an instance has an edge in the graph > GRASP peers: all nodes (GRASP instances) in the graph > > Instances of GRASP expect that they can unicast send/receive packets to all peers. > GRASP does not need to know the addresses of neighbors because it addresses > neighbors via link-local multicast (M_DISCOVERY and M_FLOOD). > > The section 2.5.2 about constrained instances : > > With my proposed text qove IMHO you would not need any additional text for the > non-ACP case. I'd need to read the whole thing to be sure of that. > I also do no not understand where outside of DULL you would need the consideration > of not doing Rapid Mode. Can we assume secure multicast except inside the ACP? I don't think so. > > Cheers > Toerless > > On Tue, Jun 06, 2017 at 10:22:20AM +1200, Brian E Carpenter wrote: >> This version includes a second round of responses to IESG comments. >> >> We may not be done yet, but please check the diffs. Here are the main changes: >> >> Removed all mention of TLS, including SONN, since it was under- >> specified. >> >> Clarified other text about trust and security model. >> >> Banned Rapid Mode when multicast is insecure. >> >> Explained use of M_INVALID to support extensibility >> >> Corrected details on discovery cache TTL and discovery timeout. >> >> Improved description of multicast UDP w.r.t. RFC8085. >> >> Clarified when transport connections are opened or closed. >> >> Noted that IPPROTO values come from the Protocol Numbers registry >> >> Protocol change: Added protocol and port numbers to URI locator. >> >> Removed inaccurate text about routing protocols >> >> Moved Requirements section to an Appendix. >> >> Other editorial and technical clarifications. >> >> Regards >> Brian >> >> On 06/06/2017 08:57, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. >>> >>> Title : A Generic Autonomic Signaling Protocol (GRASP) >>> Authors : Carsten Bormann >>> Brian Carpenter >>> Bing Liu >>> Filename : draft-ietf-anima-grasp-13.txt >>> Pages : 79 >>> Date : 2017-06-05 >>> >>> Abstract: >>> This document specifies the GeneRic Autonomic Signaling Protocol >>> (GRASP), which enables autonomic nodes and autonomic service agents >>> to dynamically discover peers, to synchronize state with each other, >>> and to negotiate parameter settings with each other. GRASP depends >>> on an external security environment that is described elsewhere. The >>> technical objectives and parameters for specific application >>> scenarios are to be described in separate documents. Appendices >>> briefly discuss requirements for the protocol and existing protocols >>> with comparable features. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-anima-grasp-13 >>> https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13 >>> >>> >>> 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. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jun 6 18:01:43 2017 Return-Path: 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 A1FCC126E01; Tue, 6 Jun 2017 18:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nNYp1AepiVmX; Tue, 6 Jun 2017 18:01:38 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 B841B1294DB; Tue, 6 Jun 2017 18:01:38 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id u1so946316pfg.1; Tue, 06 Jun 2017 18:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tEHFY0dLnI6xgNut0Ue6w4LdB8lDyv74LbYZwJCOk9M=; b=SRAKN1EhtagiI7ZxdnKyvQgDzWAGAaQOpVSd3np25XzYlDCKvjA1cfojAXtd1TZIY8 Xlj/rjxVnDnmtZNfsIDGL3kP8NBhvgtf1MPsDGfByF/vWPJvwh68z0BhMFy6gWBhjV4l Is5vUYj0MlpNkp0Kaye3fSgCqqzK6f4Ol7rG4hlIV0aDuomUMIsFxwO87OfMH2fu/h1/ fj/bAC09mjuuCZwuI8yUkFi5uxpGqN1gSf4J2KEOTCOIXFtlkxQbayN5sEnoL8fXo7rd WnCStA4gimsfN0WObyNjYsZuOF2w5IE2ZHDll4Yf2VlcndAn3DIlMe11NMmPuPWpHa2/ f4Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=tEHFY0dLnI6xgNut0Ue6w4LdB8lDyv74LbYZwJCOk9M=; b=SN5BuIbBB/AX0MbH3T5RxLsj9aWDvNGBEdD7cfYogIei9vILEgs8UF22BfjK5YxecJ eYhOe1J1aV5tWiElvecrKErlijWpEQ+Uw0HagfFORHCCGDlWDVMRM/wCgSnU7lUj97V1 g1muTqxZzf+SangekXRQV8nv7pYsdrAPjKEAauOxTVppa1nAouDux/bvavb5FSGpUvJ+ 1REvw5PcwKtmf3GTKiYSpvP6TJgyn8UYBLKTSMAOhUGRun+8lcdpi+57ew5yliSuhzm2 +hG2TU4J2OAaGnnpiVR6z4qDwyk5zJlUUoq91fdFZjpSMPeVgVjw67bzNcZ5ol280qSU wduw== X-Gm-Message-State: AODbwcD4gnGS8wJuxTypoYffuJJ18u44yqM96LiJdamMOIlMzhYRwi3X rEEcAG0XOIBTn9og X-Received: by 10.98.88.196 with SMTP id m187mr13225933pfb.87.1496797297789; Tue, 06 Jun 2017 18:01:37 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id 192sm114052pfb.10.2017.06.06.18.01.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 18:01:36 -0700 (PDT) To: Toerless Eckert , anima@ietf.org, draft-ietf-anima-prefix-management@ietf.org References: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <85488f61-1772-df24-4171-6275aa85abc0@gmail.com> Date: Wed, 7 Jun 2017 13:01:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [draft-ietf-anima-prefix-management-03] review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:01:42 -0000 On 07/06/2017 12:11, Toerless Eckert wrote: > [darn, second mail header typo on my side. sorry.] > > Dear authors > > Some feedback for the PD draft: > > 1. Relationship to DHCPv6 PD: > > The note in 4.3 makes it sound as if there is a concern by the authors that this proposal > could potentially be seen as being in conflict with DHCPv6. Yes, and I think that is a mistake. It would be an equal mistake to see this as in conflict with Radius. Rather than discussing DHCPv6/PD or Radius, I think they are really out of scope. As in a previous message to the WG, my idea is to drop the "PD" flag in the proposed objective. An ASA that uses this GRASP objective to obtain a pool of prefixes can then use DHCPv6/PD, Radius, or any other method it wants to hand prefixes out to client routers. It should be completely independent. (But including some 'serving suggestions' may well be useful, as in your items 5.1 and 5.2.) Skipping ahead: ... > 2. Prefix Management Parameters > > I do not understand from the text what prefix length is described in 6.1. Maybe i am misunderstanding > how the proposed PD mechanism should work, but in my understanding, a device has at least > TWO type of prefixes: > > GRASP/(+DHCP-PD) +---------+ > requested | router | ------ Interfaces with assigned prefixes > <-----------------> | with | ... "Assigned prefix-length 'APL'" > prefix-length | PM-ASA | ------ or > 'RPL' +---------+ GRASP/DHCP-PD requests via downstream PM-ASA > > If RPL == APL, then there is no prefix aggregation. This may be acceptable (==scale well enough) > at GRASP/DHCP-PD signaling level. If thats what the authors have in mind then that should > be written explicitly. > > Note that if RPL == APL, then this will result in more prefixes at the routing level because > all APLs can be from different prefixes and may not be aggregateable. IMHO, achieving aggregation > and managing that via PM-ASA would be a big benefit of PM-ASA. > > Aka: If the document intends to support RPL < APL, then that should be better described. For > example, section 6.1 could for each role have simply those two parameters (requested_prefix_length, > assigned_prefix_length): > > [ > [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_length", 56] ], > [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_length", 64] ], > [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ] > ] The intention is "assigned_prefix_length", i.e. what the gateway concerned will assign to connected routers. I'm not sure that we need to specify the requested length; that could be decided by a heuristic in the gateway when its pool is getting low. I don't have a strong opinion about that, but I did code a heuristic in https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.py so it can be done. > Thre assigned_prefix_length is of course most important if the downstream is an interface > where the router with PM-ASA needs to configure the prefix and the addresses are assigned > by SLAAC or DHCP from the router itself. If the downstream is not a local interface but > requests from PM-ASA, then the prefix can be determined by the downstream PM-ASA. The prefix that the client would like, yes, but the prefix length that the network allows surely has to be defined by the NOC. So maybe it should be "minimum_allowed_prefix_length" The text about these parameters is intentionally not definitive. I think only experience will tell us the correct answer(s). > 3. Mobile network roles > > section 6.1: Please expand (in parenthesis) the abbreviations you use on first use, eg: > IPRAN, RNC in section 6.1. Please check any other unexplained TLAs in the document. > > A good picture with RSG, ASG, CSG would be great and help. Especially if you want to take > the prior suggestion into account of what prefix length would be required in which role device. > > 4. If you read the point 5 below, i think there are a lot of options how PDs with ASAs can be done. > All of these options would require further details such as more GRASP objective parameters, > more description of the ASA state machinery, the individual GRASP negotiation steps etc. > I do not think we want to go through all that detail work because that is IMHO easier done by > first building prototypes, and instead having the document rather be a "framework" or > "architecture document instead of an ASA functional specification. To that end, it would IMHO be > prudent to say so, for example before the last two paragraphs of the introduction: Yes. And as far as I can see, we might need to express anything that the CASM people can express, for the same reasons: draft-sun-casm-address-pool-management-yang > proposed text, as 3rd last paragraph of introduction: > > This document is not a functional specification of the proposed autonomic function > "prefix management" or all detail all the aspects of GRASP objective parameters and ASA procedures > necessary to achieve all the different options of building a complete system. Instead it > describes the architectural framework utilizing the components of the ANI and outlines the > different deployment options and aspects and defines simple type of objectives in GRASP to > start building the system as well as some basic parameter examples. Yes, it's Informational for a reason. Thanks Brian > > 5. Abstract deployment pictures / solution overview: > > I think it would help in understanding the document if it would include a logical deployment > model pictures with explanations of the target deployment models. Ideally comparing to how this > is done with DHCP. > > For example: In the introduction, there are some high level, very suggestive statements about limitations > of DHCP (non-autonomicity). Its really hard to detail why/how the PD solution improves over > this without a more explicit comparison of some DHCP deployment model example and a PD > deployment model example. > > So, i have appended two proposed texts: 5.1 for what i understand to be the two most common > DHCP deployment models, and 5.2 for what i understand to be the proposed PD deployment model. > > I would strongly suggest to consider using 5.2 in the document - or something equivalent. > Otherwise its IMHO hard to follow / understand how PD is meant to work. > > Brian Carpenter already proved the feedback that a section like 5.1 might be contentuous and > also incomplete because centralized address management has a wide range of options not only > limited to DHCP but also involving Radius and other protocols - and there is even a whole working group > in the making (CASM - coordinated address space management). > > So maybe my proposed 5.1 would better go into an appended with sufficient preface stating > exactly that these are just examples, and that there are many more deployment models, and > that there are no current IETF recommendations or documents laying out such complete deployment > pictures. (which IMHO is exactly one of the may problems). If folks feel that any more > explicit description of even exemplary DHCP deployment models is inappropriate because > it would get too contentuous, then its almost impossible to make statements about > the limitations about DHCP in the introduction. But without trying to give an example > and getting backpressure from reviewers, its IMHO a dead end:wq > > > 5.1. Address & Prefix management with DHCP > > edge > dynamic, "netconf/YANG" interfaces > <-----------------> +-------------+ > +-------------+ <- telemetry | edge router/|+ ------ +--------+ > |config server| ..... Domain .... | DHCP server || ... | CPE |-+ LANs > +-------------+ +-------------+| ------ +--------+ | (----| ) > +-------------+ DHCP/ +---------+ > DHCPv6 / PD > > Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server > assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD (RF3633) > for IPv6 capable CPE that are router and have LANs behind them. > > This requires various coordination functions via some backend system depicted > as "config server": The address prefixes on the edge interfaces should be slightly larger > than required for the number of CPE connected so that the overall address space is best used. > The config server needs to provision edge interface address prefixes and DHCP parameters > for every edge router. If too fine grained prefixes are used, this will result in large routing > tables across the "Domain". If too coase grained prefixes are used, address space is wasted. > > There is no standard describing algorithms for how config servers would best perform this > ongoing dynamic provisioning to optimize routing table size and address space utilization. > There are currently no complete YANG models that a config server could use to perform > these actions (including telemetry of assigned adddresses from such distributed DHCP servers). > For example, a YANG model for controlling DHCP server operations is still in draft > (draft-liu-dhc-dhcp-yang-model-06). > > Due to these and other problems of the above model, the more common DHCP deployment model is as > follows: > > edge > +-------------+ initial, "CLI" interfaces > |config server| -----------------> +-------------+ > +-------------+ | edge router/|-+ ------ +--------+ > | ..... Domain .... | DHCP relay | | ... | CPE |-+ LANs > +-------------+ +-------------+ | ------ +--------+ | (----| ) > |DHCP server | +--------------+ DHCP/ +---------+ > +-------------+ DHCPv6 / PD > > > Dynamic provisioning changes to edge routers are avoided by using a central DHCP server > and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the > edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber > identifying options into DHCP requests from CPE (eg: rfc3046, rfc6221), the DHCP server > has complete policies for address assignments and prefixes useable on every > edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts > static routes for the assigned address/address-prefix into the routing table of the edge router > which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE > and LANs reachable across the Domain (the same. > > There is no comprehensive standardization of these solutions. RFC3633 section 14. for example > simply refers to "a [non-defined] protocol or other out-of-band communication to add routing > information for delegated prefixes into the provider edge router". > > 5.2 Prefix management with ANI/GRASP > > With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model > is intended to look as follows: > > |<................... ANI Domain / ACP...................>| (...) ............-> > > Roles > | > v "Edge routers" > GRASP parameter +----------------+ > Network wide parameters/policy | PM-ASA | downstream interfaces > | |(DHCP-functions)| ------ > v "central device" +----------------+ > +-------+ ^ +--------+ > |PM-ASA | <................... GRASP .... .... | CPE |-+ ( LANs ) > +-------+ . v |(PM-ASA)| | ----| > . +........+ +----------------+ +--------+ | > +...........+ . PM-ASA . | PM-ASA | ------ +---------+ > .DHCP server. +........+ |(DHCP-functions)| SLAAC / > +...........+ "intermediate router"+----------------+ DHCP / DHCP-pd > > > The network runs an ANI domain with ACP between some central device (eg: router or ANI > enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch > communication channel between the devices and enables the use of GRASP not only for p2p > communication, but also for distribution/flooding. > > The central devices and edge-routers run software to support this documents autonomic > IPv6 edge prefix management (PM). In the autonomic networking terminology, such software are called > "Autonomic Service Agents" (ASA). The ASA for Prefix Management are called PM-ASA in this document > and form together the Autonomic Prefix Management Function. > > Edge-routers can have different roles based on the type and number of CPE attaching to them. > Consider edge routers could be RSG, ASG CSG in mobile aggregation networks (see Section 6.1). > Mechanisms outside the scope of this document make routers aware of their role. > > 1. In a minimum Prefix Managmeent solution, the central device uses the "PrefixManager.Params" > GRASP Objective introduced in this document to disseminate network wide, per-role parameters > to edge routers. The PM-ASA use the parameters applying to its role to locallly "configuring" > pre-existing addressing functions. Because PM-ASA do not manage the dynamic assignment of actual > IPv6 address prefixes in this case, the following options can be considered: > > 1.a The edge router connects via downstream interfaces to (host) CPE that each require an address. > The PM-ASA sets up for each such interface a DHCP requesting router (according to RFC3633) to > request an IPv6 prefix for the interface. The routers address on the downstream interface can > be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via > RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the > CPEs. A central DHCP server acting as the DHCP delegating router (according to RFC3633) is > required. Its address can be another parameter from the GRASP Objective. > > 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are > routers and act as DHCPv6 requesting routers. The need to support this could be derived from > role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests > to the central DHCP server as in 1.a. > > 2. In a solution without a central DHCP server, the PM-ASA on the edge routers do not only > learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate > actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. > In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA > in the central device. These addresses are then used by the PM-ASA on the edge routers > to edge routers to configure prefixes on their downstream interfaces to assign addresses > via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign > addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting > IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the > address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the > local DHCP servers it starts. It need to monitor the address utilization and accordingly request > more address prefixes if its existing prefixes are exhausted, or return address prefixes when they > are unneeded. > > This solution is quite similar to the initial described IPv6 DHCP deployment model without > central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provides the automation to make this > approach work more easily than it is possible today. > > 3. The address pool(s) from which prefixes are allocated do not need to be taken all from > one central location. Edge router PM-ASA that received a big (short) prefix from a central > PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used > in such a way that the PM-ASA would find and select the objective from the closest neighboring > PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further > (smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can > not get further large prefixes from that central location anymore. Because > the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes > that have to be injected into the routing tables is limited and the topological proximity > increases the chances that aggregation of prefixes in the IGP can most likely limit > the geography in which the longer prefixes need to be routed. > > 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built > (indicated in he picture via a dotted intermediate router). This would require additional parameters > to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the > prefixes can be delegated. This is not detailed further below. > > 5. In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE"), then GRASP will extend > into the actual customer sites and can equally run a PM-ASA. All the options described in points > 1..4 above would then apply to the CPE as the edge router with the mayor changes being that > a) a CPE router will most likley not need to run DHCPv6 PD itself, but only DHCP address assignment, > b) The edge routers to which the CPE connect would most likely become ideal places to run a > hierarchical instance of PD-ASAs on as outlined in point 1. > > From nobody Tue Jun 6 18:06:39 2017 Return-Path: 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 D665512951C; Tue, 6 Jun 2017 18:06:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rJINAxCinrn6; Tue, 6 Jun 2017 18:06:36 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 9153B129503; Tue, 6 Jun 2017 18:06:36 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id l89so29287173pfi.2; Tue, 06 Jun 2017 18:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q3GRL1jlaOMAgvj9OUgqzgshFxjyW9t5vUAWI+HlCMk=; b=vUu4dd+X1XwsQwy7hChtPFn0oOmIxXyUZy+6JrAmDGijgc85VjYpbo9L2l35MnBnEh dDmnYqjp4zQTeMkYU5AsVZsPo0kV6j+TOBMcgcQRLAJhfqsj2kkIbPtYNK/L+WdXVDuy Rjp6qA4dqhJNWocxOCvJVEEUeOEJdoMUV09NzNVgTwzYOsMPG8C4LSd1tg1xwbemoHr9 AFnjSe0QRpq7EWYRSu8WL/PwAA/5jbal9hJtgQmSwnY3CDSy6ntFgZJUHb9zRDzPYGxl beiHxUqkqXUhH+PtinASF7vnFij3ywL6IBKZR8ghvhNqoe5FxfJ1fxkWo185zd1AgORC atuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=q3GRL1jlaOMAgvj9OUgqzgshFxjyW9t5vUAWI+HlCMk=; b=O+/M7Zh0bg2feU08MSPTJ17H1I0eeXilTPkK2NGh7js2jKV2bHcno/3a06qTyCqpCb r+mfTRINpddAGMo4txVUWzd5uSqn5n7/gZJD6xHjTxeXkReQSBuVkVixU7ntlO4Oz4Nc THmwg6cljFofsfYUUuVL6nXFnN/vmUqMTgxYwneFlzYVmZyynXLRP5N/VPK4qn/4sedQ A8qJY2brarMfTt3pbRdkzwNeVFbmuq+cD5adLMgHmStnXpHpNuNq5IEf+RakZy8B38X7 35R4cEnGag6wlWZAzU6+vwb2Jdgym/RSsn9NPnbHzvm796YMwjca3CODBYfNuDMG1rvI lYBw== X-Gm-Message-State: AODbwcC+WqpkQ488Qmurftu7I/9HLuZaYJjmacXXwfybMaYJC9SgdbNP Z/rFbYYj+5nEb+yp X-Received: by 10.99.218.69 with SMTP id l5mr30120314pgj.88.1496797596053; Tue, 06 Jun 2017 18:06:36 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id u62sm94860pgd.53.2017.06.06.18.06.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 18:06:35 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-grasp@ietf.org, anima@ietf.org References: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> <6deae177-9984-b43f-f494-735ba8e2d36c@gmail.com> <20170604145454.GD12427@faui40p.informatik.uni-erlangen.de> <2ec876ce-2478-27ec-881b-d2635f1cb66f@gmail.com> <20170606160904.GE12427@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 7 Jun 2017 13:06:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170606160904.GE12427@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] explanatory text [was draft-ietf-anima-grasp-12 review] feedback notes 1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:06:38 -0000 Just on one rather general point: > If we try to find a good place outside the main GRASP spec for this type of > explanatory text, which draft could that be ? I think we may need a GRASP implementer's guide. Whether it should be an RFC or a wiki page is a separate question. I also guess we will need a GRASPbis document after a year or two. That's life. Regards Brian From nobody Tue Jun 6 19:25:47 2017 Return-Path: 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 38BDA129B11; Tue, 6 Jun 2017 19:25:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8ZcbMNHXvHy3; Tue, 6 Jun 2017 19:25:44 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 11CB71296B0; Tue, 6 Jun 2017 19:25:44 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 9so173677pfj.1; Tue, 06 Jun 2017 19:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rO678PO4Q8LCa/H5yp/uQiU/o9yQrrdMWXzRLkQJwOw=; b=OKFF02KAV5pkZEuB6G1CsdVkNigHcNVnDr2BiHRW7gEow+SGo3S7Xlp/WbiwfgXAuu 37B0EtVOYLKaPzur507CLJ9VsiRyOGqzcUYePW60eAkznX26EAFJtpKQGaz7u0VRVsGD t/+oR/G+OlpQZiB3mSQTqxVi58MzKoHUBuHvTJhVMh9JbGwbW7puvjgtSsKvlyi4wCKk qtL3n+Ku8RvtIRmIwXsaJJgfYA0LGont7bdAuBCT8wZiuqaVqA6+TQMR/VNRh82jIhAD 9hYlzomeqDFYqfQZEDUm3qjuv322OWJBkxbGgcBZMLD7XqlPHYw3YGJS4acP0u0HLMXz sUFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rO678PO4Q8LCa/H5yp/uQiU/o9yQrrdMWXzRLkQJwOw=; b=aQUIfTHzox9ouXJ/H+HuQJSebLhPV35fHefFlsNW47xEnvup4CMMq/WyKMUqbwjZm1 J7uh4XsXo11OgVUpn8HHF2WlPe2VfzcJpJwGCd7npL+LOfqtJa80dR+aumNphououuKV 3e0CvOP413mG+b3fTj+vFT+0KdF91SixJs5mJ0L9gVnG8gwM+BoNWc06vbbqN561o3zL I7PM/djyP4oAeQ+rx0DvfRZLY1Mrxy1Hl4M2Q4CewH/YWZ3Ynk1/bDEMwIkb+k01G1lQ uj25U43ticxmwra4bU5YRqKLjI6vbynzeIA6N1vHwZkZvZEIkE2cYM8x+CNV9J4EbQ1V bFGg== X-Gm-Message-State: AODbwcCQznXwvyuHpgRzwKmF3NhbIEObQuRUkXKde3NqZ4STOJO7Q8S2 rnIZKB4qdkdzovEx X-Received: by 10.98.74.5 with SMTP id x5mr16222387pfa.149.1496802343321; Tue, 06 Jun 2017 19:25:43 -0700 (PDT) Received: from [130.216.38.7] (sc-cs-316051.sfac.auckland.ac.nz. [130.216.38.7]) by smtp.gmail.com with ESMTPSA id j11sm262095pgn.38.2017.06.06.19.25.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 19:25:42 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-grasp@ietf.org, anima@ietf.org References: <20170602132221.GB12427@faui40p.informatik.uni-erlangen.de> <6deae177-9984-b43f-f494-735ba8e2d36c@gmail.com> <20170604145454.GD12427@faui40p.informatik.uni-erlangen.de> <2ec876ce-2478-27ec-881b-d2635f1cb66f@gmail.com> <20170606160904.GE12427@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 7 Jun 2017 14:25:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170606160904.GE12427@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [draft-ietf-anima-grasp-12 review] feedback notes 1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 02:25:46 -0000 On 07/06/2017 04:09, Toerless Eckert wrote: > On Mon, Jun 05, 2017 at 10:56:07AM +1200, Brian E Carpenter wrote: >>> IMHO, the discover multicast message needs to have another message element which is the >>> port number to reply to. Thats assuming the reply is always TCP. If you feel UDP >>> should also be an option then the discovery message should indicate the desired >>> reply mode UDP/TCP and port number. >> >> We could have designed it that way but we didn't, and I don't want to make such >> a change in the middle of IESG discussion (unless of course we find a bug). > > I have not seen yet a protocol requirement that an instance needs to find > a dynamic port that it can bind to both via UDP and via TCP. Especially > given how this requirement can be avoided by adding a simple signaling element > to the GRASP header of multicast discovery messages. > > The main issue is also that unlike a lot of other features in GRASP, > this would be hard to introduce in a backward compatible fashion later: > > Just for curiosity: Lets assume the messaging was changed later to: > > discovery-message = [M_DISCOVERY, session-id, initiator, ?tcp-reply-port, objective] > tcp-reply-port = port-number > > a) I hope/guess that "old" GRASP implementations would skip/ignore this element > because CBOR is self-identifying and the implementation wouldn't know > this signaling element. Right ? Unexpected optional parameters in the middle are awkward to parse, so although it would be ugly, I'd tend to put it at the end. OK, I implemented discovery-message = [M_DISCOVERY, session-id, initiator, objective, ?tcp-reply-port] About ten lines of code affected. I have dummy ASAs running that can mix and match with or without this field in the message. Well, feedback please? Do we want to make a protocol change at this late stage, or leave things as they are with the option to add this later? Now I know how little coding is involved, I am 100% open minded on this question. Brian > b) Even if a) is true, an old receiver of M_FLOOD would not be able to > respond. > > Wrt to IESG: You have more experience with IESG review. If they have no concern with > this, i leave it up to you authors how to handle this. > >>> In the context of standard socket APIs, a responder can not know for certain that >>> the initiator TCP port is owned by the process that initiated the discovery >>> request. The only mitigation is to >>> a) trust the GRASP daemon on the remote side. >> >> In the ACP, we can do that. >> >>> b) The remote GRASP daemon has bound to the GRASP UDP port, so discovery >>> multicast packets whose source UDP port is also the gRASP port (the >>> destination port must be the GRASP port) are trusted to have come from the >>> remote GRASP daemon. And then the TCP port number in the discover message >>> is trusted. >> >> Yes, in the single-instance case. But that isn't the general case. > > I am always talking about multi-instance. The difference is just > which process (ASA or GRASP) is sending the M_DISCOVERY. The TCP GRASP > connection would always be handled only by ASA processes. > >>> c) GRASP daemons can use local mechanisms to ensure that the TCP port indicated >>> by an ASA is also owned by the ASA (aka: the interface between an ASA daemon >>> and a GRASP daemon can use a POSIX standard UNIX socket and the gRASP daemon >>> creates that socket and passes it back to the ASA). That way the GRASP daemon >>> knows the TCP socket port number reliably. >> >> If the discovery is executed entirely by the GRASP core, the ASA never knows >> anything about the socket. That's my preferred implementation but it >> isn't required by the protocol spec, obviously. >> >>> >>> This is all convoluted. If you are not a big fan of concoluted explanatory text >>> like what i wrote up above, i can understand it. But i am not a big fan of >>> suggestive incomplete text that you have on the draft right now... >> >> Sure. And changing to to be specific that this is needed for mutiple instances >> in one node is a good idea (and is IMHO a complete explanation of why it's needed). > > If we try to find a good place outside the main GRASP spec for this type of > explanatory text, which draft could that be ? the ASA guideline draft looked > a bit more higher layer. grasp-api draft ? > >>>> No. When you discover an objective, the discovered locator is [address, protocol, port]. >>>> Then there's an option on a flood to tag the flooded objective with [address, protocol, port]. >>>> I just don't see the problem. >>> >>> I am talking about the protocol inside of the UDP/TCP locator. >> >> Yes, that's really the same point that Adam Roach caught. I think >> the next text will be clearer (in the description of "Locator IPv6 >> address option", although it also applies to IPv4). > > Thanks. I am really looking for textual clarity on two points: > > a) when i look at a locator, what context will it be in ? > IMHO: its in the context of GRASP (aka "ACP" for ANI deployments), unless > it is in the objective-value, in which case its an objective local definition. > > b) How do i figure out what protocol is being run on top of of a locator ? > ...It's convoluted. semantic of the objective determines it, so if the objective > has multiple protocol options, then the objective-value has to have some element to define > it. But there is no standard attribute for this in CDDL defined so far;-( > > Aka: if we would define a standard CDDL elemnt "locator-method" that we would > also use in BRSKI (string) that defines the different possible options for the > protocol of the locator... that would help. > >>> See your own example for BRSKI with GRASP in the ani recommendation draft. >>> What you call method = BRSKI-TLS is what i call the protocol >> >> Sure, but that's relative to a very specialised infrastructure objective. >> I regard that as an almost pathological case that needs a separate spec >> (inside BRSKI, but I havn't had time to look at the latest BRSKI). > > I don't think it's pathological. Whenever an autonomic function is (also) using some non-GRASP > protocol between its ASA, and uses GRASP to negotiate such a protocol, then we have this > case. > >>> Without that line we do not have a normative word for the parameters of GRASP >>> objectives. >> >> Well, OK, but for overall consistency I think it has to be objective-value. > > Ok. > >>> All locators used outside of grasp-parameters MUST be from the namespace GRASP is >>> running in. >> >> That's more or less what the note in "Locator Options" says. I can make it more >> explicit. I'm not convinced it needs a MUST though. Who can guess what people >> will invent in future? > > Anything outside the objective-value is part of the GRASP spec, right ? > SO if someone invents a case for such a locator to be in a different namespace, then > that would have to be defined in an extension/revision to GRASP, right ? > == should be correct and safe to make the statement in the GRASP spec now. > >> Hmm. I have a lot of changes stacked up in the XML. I'm quite keen to >> post the draft. > > Great. > > Cheers > Toerless >> >> Brian > From nobody Tue Jun 6 19:40:51 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDA8129B1E; Tue, 6 Jun 2017 19:40:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149680324521.26338.17506742948600134765.idtracker@ietfa.amsl.com> Date: Tue, 06 Jun 2017 19:40:45 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 99 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 02:40:45 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: homenet netconf dhc 6tisch nmrg 6lo Second Priority: 6man softwire roll supa v6ops Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Sheng Jiang Terry Manderson Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Tue Jun 6 21:05:11 2017 Return-Path: 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 DA362129B5F for ; Tue, 6 Jun 2017 21:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 snj_y050H0vP for ; Tue, 6 Jun 2017 21:05:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B07129B71 for ; Tue, 6 Jun 2017 21:05:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIA61243; Wed, 07 Jun 2017 04:05:05 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 7 Jun 2017 05:05:04 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 7 Jun 2017 12:04:57 +0800 From: "Liubing (Leo)" To: Anima WG CC: "draft-ietf-anima-autonomic-control-plane@tools.ietf.org" Thread-Topic: RPL alternatives in ACP? (was: Regarding ACP routing protocol) Thread-Index: AQHS30M5PbRAxq1dDU22FKng+O+nvg== Date: Wed, 7 Jun 2017 04:04:57 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59377B72.00A5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d28c64caccf733f02b67daa501e597ae Archived-At: Subject: [Anima] RPL alternatives in ACP? (was: Regarding ACP routing protocol) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 04:05:11 -0000 Hi ACP co-authors, (Maybe you missed my last mail "Regarding ACP routing protocol", let me re-= post it with a clearer title and CC to you.) When I discuss ACP with some product people, they are always curious about = why we choosed RPL for routing. I understand the benefits of RPL in ACP, it is lightweight and much more sc= alable in a single routing area, but most of the non-IoT network devices se= em lacking the support of RPL.=20 So, please pardon my iteration on this problem, can we possibly make anothe= r traditional IGP literally legal in the ACP document? (e.g. ISIS-autoconf = or OSPFv3-autoconf) I know supporting multiple protocols would potentially = cause interoperation issues. But in some closed solutions, multi-vendor int= eroperation is not the No.1 consideration for customers. If ACP allows ISIS= -autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in n= on-IoT network scenarios. Any comments/eggs? :) B.R. Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > Sent: Tuesday, May 23, 2017 5:53 PM > To: Anima WG > Subject: [Anima] Regarding ACP routing protocol >=20 > Hi all, >=20 > When I discuss ACP with some product people, they are always curious > about why we choose RPL for routing. > I understand the benefits of RPL in ACP, it is lightweight and much more > scalable in a single routing area, but most of the non-IoT network device= s > seem like lack the support of RPL. >=20 > So, please pardon my iteration on this problem, can we possibly make > another more traditional IGP literally legal in the ACP document? (e.g. > ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols > would potentially cause interoperation issue. But in some closed solution= s, > multi-vendor interoperation is not the No.1 consideration for customers. = If > ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more > widely adopted in non-IoT network devices. >=20 > Any comments? Or eggs :) >=20 > B.R. > Bing >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 6 23:34:16 2017 Return-Path: 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 DF0BC12EA97; Tue, 6 Jun 2017 23:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 xHKCs-z9puNj; Tue, 6 Jun 2017 23:34:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDA112EAAA; Tue, 6 Jun 2017 23:34:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOO61990; Wed, 07 Jun 2017 06:34:06 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 7 Jun 2017 07:34:04 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 7 Jun 2017 14:33:58 +0800 From: Duzongpeng To: Toerless Eckert , "anima@ietf.org" , "draft-ietf-anima-prefix-management@ietf.org" Thread-Topic: [draft-ietf-anima-prefix-management-03] review Thread-Index: AQHS3yKVr9mPZiykpkqgOS1vdhZuOqIY6uWA Date: Wed, 7 Jun 2017 06:33:58 +0000 Message-ID: References: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59379E5E.0128, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9df67425a7919b6c4b52da2d5c21b8e8 Archived-At: Subject: Re: [Anima] [draft-ietf-anima-prefix-management-03] review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 06:34:14 -0000 Hi, Toerless Thanks for the review and suggestions. Some personal opinions to share. Please correct me if any misunderstanding= . 1. The description about the relationship between DHCP PD and ANIMA prefix= -management mechanism is ambiguous.=20 =09 I agree with Brian's suggestion about deleting the PD issue from this docu= ment.=20 It is a realization problem and deleting it will not cause too much misund= erstanding.=20 IMO, to talk too much about the details is not the document's purpose, i.e= ., validation of the designation of autonomic networking infrastructure. 2. A node model containing "requested_prefix_length" and "assigned_prefix_= length" is propsoed, while in current document we only have a prefix_length= for the node. I think the problem is shortage of description of the whole structure, or = a clear example. It causes the reader hard to image the mechanism. We need make it clear about the main mechanism, for example, adding some t= opology pictures and TLA descriptions as suggested.=20 =09 3. It is suggested to add more abbreviation explanations and a picture abo= ut 6.1 (the IPRAN example section) Agree. 4. It is suggested that we should not go through all that detail work beca= use that is easier done by first building prototypes. Also, you have propos= ed a paragraph of introduction: This document is not a functional specification of the proposed autonomi= c function "prefix management" or all detail all the aspects of GRASP objective para= meters and ASA procedures necessary to achieve all the different options of building a complete sys= tem. Instead it describes the ***architectural framework*** utilizing the components of t= he ANI and outlines the different deployment options and aspects and defines simple type of objec= tives in GRASP to start building the system as well as some basic parameter examples. Agree. But as suggested by Brian, ***architectural framework*** perhaps is= not very proper here.=20 I suggest some other word here, such as "initial realization" or "prototyp= e system". Is it OK? 5. You suggest that add some texts about the abstract deployment pictures = / solution overview Including: 5.1. Address & Prefix management with DHCP 5.2 Prefix management with ANI/GRASP I agree that we need to add some mechanism descriptions to make the reader= more easily catch the main point about the mechanism. However, although it may be helpful, I do not suggest describing too much = about the DHCP mechanism in this document. I suggest focusing on the main mechanism about ANIMA prefix-management and= adding more details about it. If it can solve the problem of ambiguity, we do not need to add too much c= ontents about other detailed descriptions in this document. On the other side, I agree with the proposed solution architecture, and I = think it should be able to work.=20 If it is agreed that to add all the texts is necessary, i.e., it is worthw= hile to explain the multiple solutions in the document, I am ok with it. =09 Best Regards Zongpeng Du -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: Wednesday, June 07, 2017 8:11 AM To: anima@ietf.org; draft-ietf-anima-prefix-management@ietf.org Subject: [draft-ietf-anima-prefix-management-03] review [darn, second mail header typo on my side. sorry.] Dear authors Some feedback for the PD draft: 1. Relationship to DHCPv6 PD: The note in 4.3 makes it sound as if there is a concern by the authors that= this proposal could potentially be seen as being in conflict with DHCPv6. I am not sure about a practical case where this case would ever be a concer= n. If the authors can think of such a case, then it would be good to add se= ntences explaining that case. Otherwise maybe revisit this concern. IMHO AN= IMA-PD could nicely integrate/expand DHCP-PD: RFC3633 (DHCPv6 PD) abstract says: "..delegating a long- lived prefix from = a delegating router to a requesting router, across an administrative bounda= ry.." ^^^^^^^^^^^^^^^^^^^^^^^ To validat= e the ANI, IMHO we just need to show how to use GRASP within a domain, eg: = not across an administrative boundary. =3D=3D no overlap with the declared = intended use of DHCPv6 PD. Instead i could rather see ANI/GRASP used inside= the domain and then DHCP/DHCPv6-PD be used on the edge of the domain to cl= ient (non-ANI devices). 2. Prefix Management Parameters I do not understand from the text what prefix length is described in 6.1. M= aybe i am misunderstanding how the proposed PD mechanism should work, but i= n my understanding, a device has at least TWO type of prefixes: GRASP/(+DHCP-PD) +---------+ requested | router | ------ Interfaces with assigned p= refixes <-----------------> | with | ... "Assigned prefix-length 'A= PL'" prefix-length | PM-ASA | ------ or 'RPL' +---------+ GRASP/DHCP-PD requests via= downstream PM-ASA If RPL =3D=3D APL, then there is no prefix aggregation. This may be accepta= ble (=3D=3Dscale well enough) at GRASP/DHCP-PD signaling level. If thats wh= at the authors have in mind then that should be written explicitly. Note that if RPL =3D=3D APL, then this will result in more prefixes at the = routing level because all APLs can be from different prefixes and may not b= e aggregateable. IMHO, achieving aggregation and managing that via PM-ASA w= ould be a big benefit of PM-ASA. Aka: If the document intends to support RPL < APL, then that should be bett= er described. For example, section 6.1 could for each role have simply thos= e two parameters (requested_prefix_length, assigned_prefix_length): [ [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_l= ength", 56] ], [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_l= ength", 64] ], [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_l= ength", 64] ] ] Thre assigned_prefix_length is of course most important if the downstream i= s an interface where the router with PM-ASA needs to configure the prefix a= nd the addresses are assigned by SLAAC or DHCP from the router itself. If t= he downstream is not a local interface but requests from PM-ASA, then the p= refix can be determined by the downstream PM-ASA.=20 3. Mobile network roles section 6.1: Please expand (in parenthesis) the abbreviations you use on fi= rst use, eg: IPRAN, RNC in section 6.1. Please check any other unexplained TLAs in the d= ocument. A good picture with RSG, ASG, CSG would be great and help. Especially if yo= u want to take the prior suggestion into account of what prefix length woul= d be required in which role device. 4. If you read the point 5 below, i think there are a lot of options how PD= s with ASAs can be done. All of these options would require further details such as more GRASP objec= tive parameters, more description of the ASA state machinery, the individua= l GRASP negotiation steps etc. I do not think we want to go through all that detail work because that is I= MHO easier done by first building prototypes, and instead having the docume= nt rather be a "framework" or "architecture document instead of an ASA func= tional specification. To that end, it would IMHO be prudent to say so, for= example before the last two paragraphs of the introduction: proposed text, as 3rd last paragraph of introduction: This document is not a functional specification of the proposed autonomic= function "prefix management" or all detail all the aspects of GRASP objective para= meters and ASA procedures necessary to achieve all the different options of building a complete sys= tem. Instead it describes the architectural framework utilizing the components of the ANI= and outlines the different deployment options and aspects and defines simple type of objec= tives in GRASP to start building the system as well as some basic parameter examples. 5. Abstract deployment pictures / solution overview: I think it would help in understanding the document if it would include a l= ogical deployment model pictures with explanations of the target deployment= models. Ideally comparing to how this is done with DHCP. For example: In the introduction, there are some high level, very suggestiv= e statements about limitations of DHCP (non-autonomicity). Its really hard = to detail why/how the PD solution improves over this without a more explici= t comparison of some DHCP deployment model example and a PD deployment mode= l example. So, i have appended two proposed texts: 5.1 for what i understand to be the= two most common DHCP deployment models, and 5.2 for what i understand to b= e the proposed PD deployment model. I would strongly suggest to consider using 5.2 in the document - or somethi= ng equivalent. Otherwise its IMHO hard to follow / understand how PD is meant to work. Brian Carpenter already proved the feedback that a section like 5.1 might b= e contentuous and also incomplete because centralized address management ha= s a wide range of options not only limited to DHCP but also involving Radiu= s and other protocols - and there is even a whole working group in the maki= ng (CASM - coordinated address space management). So maybe my proposed 5.1 would better go into an appended with sufficient p= reface stating exactly that these are just examples, and that there are man= y more deployment models, and that there are no current IETF recommendation= s or documents laying out such complete deployment pictures. (which IMHO is= exactly one of the may problems). If folks feel that any more explicit des= cription of even exemplary DHCP deployment models is inappropriate because = it would get too contentuous, then its almost impossible to make statements= about the limitations about DHCP in the introduction. But without trying t= o give an example and getting backpressure from reviewers, its IMHO a dead = end:wq 5.1. Address & Prefix management with DHCP edge dynamic, "netconf/YANG" interfaces <-----------------> +-------------+ +-------------+ <- telemetry | edge router/|+ ------ +----= ----+ |config server| ..... Domain .... | DHCP server || ... | CPE= |-+ LANs +-------------+ +-------------+| ------ +----= ----+ | (----| ) +-------------+ DHCP/ +---= ------+ DHCPv6 / PD Edge DHCP server deployment requires every edge router connecting to CPE to= be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv= 6 prefixes via DHCPv6-PD (RF3633) for IPv6 capable CPE that are router and = have LANs behind them. This requires various coordination functions via some backend system depict= ed as "config server": The address prefixes on the edge interfaces should b= e slightly larger than required for the number of CPE connected so that the= overall address space is best used. The config server needs to provision edge interface address prefixes and DH= CP parameters for every edge router. If too fine grained prefixes are used= , this will result in large routing tables across the "Domain". If too coas= e grained prefixes are used, address space is wasted. There is no standard describing algorithms for how config servers would bes= t perform this ongoing dynamic provisioning to optimize routing table size = and address space utilization. There are currently no complete YANG models that a config server could use = to perform these actions (including telemetry of assigned adddresses from s= uch distributed DHCP servers). For example, a YANG model for controlling DHCP server operations is still i= n draft (draft-liu-dhc-dhcp-yang-model-06). Due to these and other problems of the above model, the more common DHCP de= ployment model is as follows: edge +-------------+ initial, "CLI" interfaces |config server| -----------------> +-------------+ +-------------+ | edge router/|-+ ------ +---= -----+ | ..... Domain .... | DHCP relay | | ... | CP= E |-+ LANs +-------------+ +-------------+ | ------ +---= -----+ | (----| ) |DHCP server | +--------------+ DHCP/ +--= -------+ +-------------+ DHCPv6 / PD Dynamic provisioning changes to edge routers are avoided by using a central= DHCP server and reducing the edge router from DHCP server to DHCP relay. T= he "configuration" on the edge routers is static, the DHCP relay function i= nserts "edge interface" and/or subscriber identifying options into DHCP req= uests from CPE (eg: rfc3046, rfc6221), the DHCP server has complete policie= s for address assignments and prefixes useable on every edge-router/interfa= ce/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts st= atic routes for the assigned address/address-prefix into the routing table = of the edge router which are then to be distributed by the IGP (or BGP) ins= ide the domain to make the CPE and LANs reachable across the Domain (the sa= me. There is no comprehensive standardization of these solutions. RFC3633 secti= on 14. for example simply refers to "a [non-defined] protocol or other out-= of-band communication to add routing information for delegated prefixes int= o the provider edge router". 5.2 Prefix management with ANI/GRASP With the proposed use of ANI and Prefix-management ASAs using GRASP, the de= ployment model is intended to look as follows:=20 |<................... ANI Domain / ACP...................>| (...) .......= .....-> Roles | v "Edge routers" GRASP parameter +----------------+ Network wide parameters/policy | PM-ASA | downstream in= terfaces | |(DHCP-functions)| ------ v "central device" +----------------+ +-------+ ^ +---= -----+ |PM-ASA | <................... GRASP .... .... | CP= E |-+ ( LANs ) +-------+ . v |(PM= -ASA)| | ----| =20 . +........+ +----------------+ +---= -----+ |=20 +...........+ . PM-ASA . | PM-ASA | ------ +--= -------+ .DHCP server. +........+ |(DHCP-functions)| SLAAC / +...........+ "intermediate router"+----------------+ DHCP / DHCP-p= d The network runs an ANI domain with ACP between some central device (eg: ro= uter or ANI enabled management device) and the edge routers. ANI/ACP provid= es a secure, zero-touch communication channel between the devices and enabl= es the use of GRASP not only for p2p communication, but also for distributi= on/flooding. The central devices and edge-routers run software to support this documents= autonomic IPv6 edge prefix management (PM). In the autonomic networking terminology, = such software are called "Autonomic Service Agents" (ASA). The ASA for Pref= ix Management are called PM-ASA in this document and form together the Auto= nomic Prefix Management Function. Edge-routers can have different roles based on the type and number of CPE a= ttaching to them. Consider edge routers could be RSG, ASG CSG in mobile aggregation networks = (see Section 6.1). Mechanisms outside the scope of this document make routers aware of their r= ole. 1. In a minimum Prefix Managmeent solution, the central device uses the "Pr= efixManager.Params" GRASP Objective introduced in this document to disseminate network wide, pe= r-role parameters to edge routers. The PM-ASA use the parameters applying t= o its role to locallly "configuring" pre-existing addressing functions. Because PM-ASA do not manage the dynamic= assignment of actual IPv6 address prefixes in this case, the following options can be considered= : 1.a The edge router connects via downstream interfaces to (host) CPE that e= ach require an address. The PM-ASA sets up for each such interface a DHCP requesting router (accord= ing to RFC3633) to request an IPv6 prefix for the interface. The routers ad= dress on the downstream interface can be another parameter from the GRASP O= bjective. The CPEs assign addresses in the prefix via RAs from the router o= r the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs.= A central DHCP server acting as the DHCP delegating router (according to R= FC3633) is required. Its address can be another parameter from the GRASP Ob= jective. 1.b The edge router also connects via downstream interfaces to (customer ma= naged) CPEs that are routers and act as DHCPv6 requesting routers. The need= to support this could be derived from role and/or GRASP parameters and the= PM-ASA sets up a DHCP relay function to pass on requests to the central DH= CP server as in 1.a. 2. In a solution without a central DHCP server, the PM-ASA on the edge rout= ers do not only learn parameters from "PrefixManager.Params" but also utili= ze GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "= PrefixManager" objective described in more detail below. In the most simple case, these prefixes are delegated via this GRASP object= ive from the PM-ASA in the central device. These addresses are then used b= y the PM-ASA on the edge routers to edge routers to configure prefixes on t= heir downstream interfaces to assign addresses via RA/SLAAC to host CPEs. T= he PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses= via DHCP to CPE from the prefixes it received. This includes both host CPE= s requesting IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-AS= A needs to manage the address pool(s) it has requested via GRASP and alloca= te sub-address pools to interfaces and the local DHCP servers it starts. It= need to monitor the address utilization and accordingly request more addre= ss prefixes if its existing prefixes are exhausted, or return address prefi= xes when they are unneeded. This solution is quite similar to the initial described IPv6 DHCP deploymen= t model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do pr= ovides the automation to make this approach work more easily than it is pos= sible today. 3. The address pool(s) from which prefixes are allocated do not need to be = taken all from one central location. Edge router PM-ASA that received a big= (short) prefix from a central PM-ASA could offer smaller sub-prefixes to n= eighboring edge-router PM-ASA. GRASP could be used in such a way that the P= M-ASA would find and select the objective from the closest neighboring PM-A= SA, therefore allowing to maximize aggregation: A PM-ASA would only request= further (smaller/shorter) prefixes when it exhausts its own poll (from the central = location) and can not get further large prefixes from that central location= anymore. Because the overflow prefixes taken from a topological nearby PM-= ASA, the number of longer prefixes that have to be injected into the routin= g tables is limited and the topological proximity increases the chances tha= t aggregation of prefixes in the IGP can most likely limit the geography in= which the longer prefixes need to be routed.=20 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy o= f PM-ASA can be built (indicated in he picture via a dotted intermediate ro= uter). This would require additional parameters to the "PrefixManager" obje= ctive to allow creating a hierarchy of PM-ASA across which the prefixes can= be delegated. This is not detailed further below. 5. In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE")= , then GRASP will extend into the actual customer sites and can equally run= a PM-ASA. All the options described in points 1..4 above would then apply to the CPE as the edge router with the mayor ch= anges being that a) a CPE router will most likley not need to run DHCPv6 PD itself, but only= DHCP address assignment, b) The edge routers to which the CPE connect would most likely become ideal= places to run a hierarchical instance of PD-ASAs on as outlined in point 1= . From nobody Wed Jun 7 02:23:37 2017 Return-Path: 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 1B045129B20 for ; Wed, 7 Jun 2017 02:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 xibpLbIxTm5e for ; Wed, 7 Jun 2017 02:23:33 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 D9AB0129AFA for ; Wed, 7 Jun 2017 02:23:32 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 7so113959310wmo.1 for ; Wed, 07 Jun 2017 02:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Rzhrdiw3xVLMGNYfMgsWsBkmyU5UsshaW6cNhHEcGf8=; b=YiR1Wy8VvqFe3QiU5+WhzBmMeTQToYp05NaHoKfKm2oP1vv6EjFBO5E72tXFQlEc7Q pLs1hpdF9MS2EuuIH/AfEvCsvyWzZFzL5/v4Z7OZ7NKAFd7or2w9qHMHVZ7xx8KMzjpg 7ltOtPtVXwrlV5YCYJKI9mqIk+c1r8gfywD7FUTJyS6va7gqoM1c1W2Lgj+W1mWreTSm 3fM6agO9Nrvum0VvR1pvEf48ffxYI5Xs5LeSU5XxSZ827dsq2BL75TwkI6ofUo5u2RtN nzieNFqUQniBT9x8ResciwnugsCSnCFETUyidOhsA/9YfZdwwaJQktu7DhQr909vJOv8 U+xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Rzhrdiw3xVLMGNYfMgsWsBkmyU5UsshaW6cNhHEcGf8=; b=frMmG0Hk8pa+dsdTlDMp2QdWTTAaD8cNStVssAYvWW6iAgsze9IYwy5/wog9YPA8Az awa15clOugHoI+qMMwlKcUrlS3UpfDW9+KfqL+deTeruMi7/h6v/wiBrg+iUKnhckH/N yD6WtsVQtlbW7bgOxZ/HNHSl5IwqCQFHoUgfKt7qcb+VcmxsPIEGZ2g9g7zWiBKlICkt ETo4O0tj73qjZGvhGsWzlzrS1PPMXU2ER0rmSr5c9SpmJroZoHl5SR0ITmQV9rDAUzz+ Sj4Eu6GZ7qRvbi0i0f1IR7w9Y2l+r0Ds4T8cN5L9n9vqERRltBqnIOSxIiRYl1QdIjTV IvNQ== X-Gm-Message-State: AKS2vOxPHoqP6/fCBBPktu8Eb9rtzn/CJCkLeUMjKsm6kz9/ndE6hMYf KyYljuGoxsGlEDUlOOA= X-Received: by 10.28.217.1 with SMTP id q1mr1442656wmg.23.1496827411164; Wed, 07 Jun 2017 02:23:31 -0700 (PDT) Received: from [192.168.1.23] (ANice-652-1-117-233.w83-201.abo.wanadoo.fr. [83.201.20.233]) by smtp.gmail.com with ESMTPSA id 185sm20020173wmp.1.2017.06.07.02.23.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 02:23:30 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> Message-ID: Date: Wed, 7 Jun 2017 11:23:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] RPL alternatives in ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 09:23:35 -0000 Bing, I´m afraid that´s a can of worms... Homenet has been stalled for a long time, and quite a few IETFs were only about the fight "my routing protocol is better than yours". I´m afraid if we enter this discussion, we have 2 years of arguments ahead for no obvious benefit. Let me ask the other way round: With the specs as they are, what will NOT work? My view: Unless we have a real good reason, we should not enter this debate... Michael On 07/06/2017 06:04, Liubing (Leo) wrote: > Hi ACP co-authors, > > (Maybe you missed my last mail "Regarding ACP routing protocol", let me re-post it with a clearer title and CC to you.) > > When I discuss ACP with some product people, they are always curious about why we choosed RPL for routing. > I understand the benefits of RPL in ACP, it is lightweight and much more scalable in a single routing area, but most of the non-IoT network devices seem lacking the support of RPL. > > So, please pardon my iteration on this problem, can we possibly make another traditional IGP literally legal in the ACP document? (e.g. ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols would potentially cause interoperation issues. But in some closed solutions, multi-vendor interoperation is not the No.1 consideration for customers. If ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT network scenarios. > > Any comments/eggs? :) > > B.R. > Bing > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) >> Sent: Tuesday, May 23, 2017 5:53 PM >> To: Anima WG >> Subject: [Anima] Regarding ACP routing protocol >> >> Hi all, >> >> When I discuss ACP with some product people, they are always curious >> about why we choose RPL for routing. >> I understand the benefits of RPL in ACP, it is lightweight and much more >> scalable in a single routing area, but most of the non-IoT network devices >> seem like lack the support of RPL. >> >> So, please pardon my iteration on this problem, can we possibly make >> another more traditional IGP literally legal in the ACP document? (e.g. >> ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols >> would potentially cause interoperation issue. But in some closed solutions, >> multi-vendor interoperation is not the No.1 consideration for customers. If >> ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more >> widely adopted in non-IoT network devices. >> >> Any comments? Or eggs :) >> >> B.R. >> Bing >> >> _______________________________________________ >> 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 From nobody Wed Jun 7 05:23:18 2017 Return-Path: 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 2046212EBE7 for ; Wed, 7 Jun 2017 05:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 PnSHw0Bq0E_3 for ; Wed, 7 Jun 2017 05:23:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C50312EBE3 for ; Wed, 7 Jun 2017 05:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3071; q=dns/txt; s=iport; t=1496838194; x=1498047794; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nYu6qLO+aUd0yLeTKxFyrTfklmCDmJeRo4hD7hqO+88=; b=bOffu4dCtv94Pw88EdRYBAyJEM5HZhvOoZ8mpasbj4Yy3a2GOUK8Y5WW 1TzNAJIGlVtypT5ZgLKT9NmRob22w353ZkT0oXHBVzTrmKSPECbXUPanW P5Ivfj2LDknxMqqlafjj71agXXjR3tAzGA41acBr06y7pMOyADxVcDZL4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAQAP7zdZ/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1higQ0Hn2yYECELhXgCgm9CFQECAQEBAQEBAWsdC4UYAQEBAQI?= =?us-ascii?q?BAQE4NBAHBAIBCBEEAQEBHgkHJwsUCQgCBBMIE4oICBCwb4t9AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWLYYRNAQGGDgWeOQKTLYIPhT6KPJRmATUiSz90FRwqhwh?= =?us-ascii?q?2hyKBI4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,311,1493683200"; d="scan'208";a="254668796" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 12:23:13 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v57CNDLE015150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Jun 2017 12:23:13 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 7 Jun 2017 07:23:12 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1210.000; Wed, 7 Jun 2017 07:23:12 -0500 From: "Roberta Maglione (robmgl)" To: "anima@ietf.org" Thread-Topic: [Anima] RPL alternatives in ACP? Thread-Index: AQHS32/DfmisZynkOUKIe2IF+6o3jKIZTBlA Date: Wed, 7 Jun 2017 12:23:12 +0000 Message-ID: References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.123.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] RPL alternatives in ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:23:16 -0000 Hello Bing, I'm not sure I fully understand and agree with what you are trying to say w= ith this sentence:=20 > But in some closed solutions, multi-vendor interoperation is not the No.1= consideration for customers. If you think that multi-vendor interoperability is not needed what's the po= int of making a standard? Why discussing it here? You could make your own c= hoice for protocol without asking for WG opinion/consensus. Roberta On 07/06/2017 06:04, Liubing (Leo) wrote: > Hi ACP co-authors, > > (Maybe you missed my last mail "Regarding ACP routing protocol", let=20 > me re-post it with a clearer title and CC to you.) > > When I discuss ACP with some product people, they are always curious abou= t why we choosed RPL for routing. > I understand the benefits of RPL in ACP, it is lightweight and much more = scalable in a single routing area, but most of the non-IoT network devices = seem lacking the support of RPL. > > So, please pardon my iteration on this problem, can we possibly make anot= her traditional IGP literally legal in the ACP document? (e.g. ISIS-autocon= f or OSPFv3-autoconf) I know supporting multiple protocols would potentiall= y cause interoperation issues. But in some closed solutions, multi-vendor i= nteroperation is not the No.1 consideration for customers. If ACP allows IS= IS-autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in= non-IoT network scenarios. > > Any comments/eggs? :) > > B.R. > Bing > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing=20 >> (Leo) >> Sent: Tuesday, May 23, 2017 5:53 PM >> To: Anima WG >> Subject: [Anima] Regarding ACP routing protocol >> >> Hi all, >> >> When I discuss ACP with some product people, they are always curious=20 >> about why we choose RPL for routing. >> I understand the benefits of RPL in ACP, it is lightweight and much=20 >> more scalable in a single routing area, but most of the non-IoT=20 >> network devices seem like lack the support of RPL. >> >> So, please pardon my iteration on this problem, can we possibly make=20 >> another more traditional IGP literally legal in the ACP document? (e.g. >> ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple=20 >> protocols would potentially cause interoperation issue. But in some=20 >> closed solutions, multi-vendor interoperation is not the No.1=20 >> consideration for customers. If ACP allows ISIS-autoconf or=20 >> OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT net= work devices. >> >> Any comments? Or eggs :) >> >> B.R. >> Bing >> >> _______________________________________________ >> 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 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jun 7 12:07:44 2017 Return-Path: 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 8F9CD1314A7 for ; Wed, 7 Jun 2017 12:07:42 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 xJ1Xgma8CnIt for ; Wed, 7 Jun 2017 12:07:41 -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 37121131482 for ; Wed, 7 Jun 2017 12:04:41 -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 1D02258C4EC; Wed, 7 Jun 2017 21:04:37 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id F18CBB0C216; Wed, 7 Jun 2017 21:04:36 +0200 (CEST) Date: Wed, 7 Jun 2017 21:04:36 +0200 From: Toerless Eckert To: "Liubing (Leo)" Cc: Anima WG , "draft-ietf-anima-autonomic-control-plane@tools.ietf.org" Message-ID: <20170607190436.GA20021@faui40p.informatik.uni-erlangen.de> References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] RPL alternatives in ACP? (was: Regarding ACP routing protocol) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:07:42 -0000 Hi Bing Sorry if i overlooked some email. Somehow there must be better tooling that just a humonguous mailing list to track todo items. If i just knew what ;-)) Did the people whom you discussed this with read Appendix A of the ACP draft ? If they did, what where the comments ? From wha you write, it sounded as if there was no discussion about the requirements that resulted in the choice of RPL but only about past experience and extrapolating from it. Thats a logic by which you build cars with wings instead of airplanes ;-) I would very much like to help making people understand why we choose RPL and maybe the arguments in appendix A do not yet represent the best possible text. I for once could think of a lot more explanation of details that might help, but i would like to extend he text only upon actually understanding what argument would help to further the discussion. Beside what Roberta said: If we wanted to define solutions to support multiple IGPs for the ACP in an interoperable fashion, we would need IMHO to go all the way into the bootstrap protocol to be able to query the device about the supported routing protocol choices and only permitting it into the domain if the routing protocol used by the domain is suported. And i am not sure i would get approval on such a complex extension to the bootstrap protocol from the other bootstrap authors. Aka: The whole concept of multi-IGP support would first need to be nailed down a lot more. And even if we would achieve that goal: i can see no option to NOT make ONE protocol the MTI (mandatory to implement) option, and RPL is the best compromise with the largest applicability across small/IoT to large/ent/SP networks in a zero-touch autoconfiguring environment. Cheers Toerless On Wed, Jun 07, 2017 at 04:04:57AM +0000, Liubing (Leo) wrote: > Hi ACP co-authors, > > (Maybe you missed my last mail "Regarding ACP routing protocol", let me re-post it with a clearer title and CC to you.) > > When I discuss ACP with some product people, they are always curious about why we choosed RPL for routing. > I understand the benefits of RPL in ACP, it is lightweight and much more scalable in a single routing area, but most of the non-IoT network devices seem lacking the support of RPL. > > So, please pardon my iteration on this problem, can we possibly make another traditional IGP literally legal in the ACP document? (e.g. ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols would potentially cause interoperation issues. But in some closed solutions, multi-vendor interoperation is not the No.1 consideration for customers. If ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT network scenarios. > > Any comments/eggs? :) > > B.R. > Bing > > > -----Original Message----- > > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) > > Sent: Tuesday, May 23, 2017 5:53 PM > > To: Anima WG > > Subject: [Anima] Regarding ACP routing protocol > > > > Hi all, > > > > When I discuss ACP with some product people, they are always curious > > about why we choose RPL for routing. > > I understand the benefits of RPL in ACP, it is lightweight and much more > > scalable in a single routing area, but most of the non-IoT network devices > > seem like lack the support of RPL. > > > > So, please pardon my iteration on this problem, can we possibly make > > another more traditional IGP literally legal in the ACP document? (e.g. > > ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols > > would potentially cause interoperation issue. But in some closed solutions, > > multi-vendor interoperation is not the No.1 consideration for customers. If > > ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more > > widely adopted in non-IoT network devices. > > > > Any comments? Or eggs :) > > > > B.R. > > Bing > > > > _______________________________________________ > > 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 -- --- tte@cs.fau.de From nobody Wed Jun 7 12:24:47 2017 Return-Path: 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 ADB8A131486; Wed, 7 Jun 2017 12:24:46 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 bK5jw4yuTPre; Wed, 7 Jun 2017 12:24:43 -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 68892131463; Wed, 7 Jun 2017 12:24:43 -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 0717B58C4EC; Wed, 7 Jun 2017 21:24:39 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D78EDB0C216; Wed, 7 Jun 2017 21:24:38 +0200 (CEST) Date: Wed, 7 Jun 2017 21:24:38 +0200 From: Toerless Eckert To: Duzongpeng Cc: "anima@ietf.org" , "draft-ietf-anima-prefix-management@ietf.org" Message-ID: <20170607192438.GB20021@faui40p.informatik.uni-erlangen.de> References: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] [draft-ietf-anima-prefix-management-03] review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:24:46 -0000 Thankz, Duzongpeng, inline: On Wed, Jun 07, 2017 at 06:33:58AM +0000, Duzongpeng wrote: > Hi, Toerless > > Thanks for the review and suggestions. > > Some personal opinions to share. Please correct me if any misunderstanding. > > 1. The description about the relationship between DHCP PD and ANIMA prefix-management mechanism is ambiguous. > > I agree with Brian's suggestion about deleting the PD issue from this document. > > It is a realization problem and deleting it will not cause too much misunderstanding. Instead of deletion it might be more helpful to write text that explains as i did in my review how RFC3633 is meant for interdomain (administative boundary) operation and that the GRASP/ANI based approach is intra-domain and therefore could even be a great complement to DHCPv6 - and not replace it. > IMO, to talk too much about the details is not the document's purpose, i.e., validation of the designation of autonomic networking infrastructure. Not sure what specific change proposal that refers to. > 2. A node model containing "requested_prefix_length" and "assigned_prefix_length" is propsoed, while in current document we only have a prefix_length for the node. > > I think the problem is shortage of description of the whole structure, or a clear example. It causes the reader hard to image the mechanism. > We need make it clear about the main mechanism, for example, adding some topology pictures and TLA descriptions as suggested. Thanks. > 3. It is suggested to add more abbreviation explanations and a picture about 6.1 (the IPRAN example section) > > Agree. > > 4. It is suggested that we should not go through all that detail work because that is easier done by first building prototypes. Also, you have proposed a paragraph of introduction: > > This document is not a functional specification of the proposed autonomic function > "prefix management" or all detail all the aspects of GRASP objective parameters and ASA procedures > necessary to achieve all the different options of building a complete system. Instead it > describes the ***architectural framework*** utilizing the components of the ANI and outlines the > different deployment options and aspects and defines simple type of objectives in GRASP to > start building the system as well as some basic parameter examples. > > Agree. But as suggested by Brian, ***architectural framework*** perhaps is not very proper here. > I suggest some other word here, such as "initial realization" or "prototype system". Is it OK? Well, Brian is a native english speaker so i'd happily defer to his selection of words. To me "architectural framework is always the best lame excuse for providing an overview and then NOT go into details. Just enough to feel safe that it can be built and will deliver the claimed benefits. "initiaial realization" or "prototype" sounds to me as if a lot more details would have to be worked out. > 5. You suggest that add some texts about the abstract deployment pictures / solution overview > Including: > > 5.1. Address & Prefix management with DHCP > 5.2 Prefix management with ANI/GRASP > > I agree that we need to add some mechanism descriptions to make the reader more easily catch the main point about the mechanism. > However, although it may be helpful, I do not suggest describing too much about the DHCP mechanism in this document. > > I suggest focusing on the main mechanism about ANIMA prefix-management and adding more details about it. > If it can solve the problem of ambiguity, we do not need to add too much contents about other detailed descriptions in this document. > > On the other side, I agree with the proposed solution architecture, and I think it should be able to work. > If it is agreed that to add all the texts is necessary, i.e., it is worthwhile to explain the multiple solutions in the document, I am ok with it. So, the DHCP text i proposed has two purposes: a) It is meant to justify paragraph 2 of section 3 (problem statement). b) It is meant to show how the proposed picture/solution with PD could fill in exactly the not well defined/working pieces of one of the DHCP pictures. Aka: Mayve lets wait with the DHCP texts for when Brian has time (after getting through GRASP), so that we can understand his best insight and then finalize that part of the discussion. Cheers Toerless > > Best Regards > Zongpeng Du > > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: Wednesday, June 07, 2017 8:11 AM > To: anima@ietf.org; draft-ietf-anima-prefix-management@ietf.org > Subject: [draft-ietf-anima-prefix-management-03] review > > [darn, second mail header typo on my side. sorry.] > > Dear authors > > Some feedback for the PD draft: > > 1. Relationship to DHCPv6 PD: > > The note in 4.3 makes it sound as if there is a concern by the authors that this proposal could potentially be seen as being in conflict with DHCPv6. > > I am not sure about a practical case where this case would ever be a concern. If the authors can think of such a case, then it would be good to add sentences explaining that case. Otherwise maybe revisit this concern. IMHO ANIMA-PD could nicely integrate/expand DHCP-PD: > > RFC3633 (DHCPv6 PD) abstract says: "..delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary.." > ^^^^^^^^^^^^^^^^^^^^^^^ To validate the ANI, IMHO we just need to show how to use GRASP within a domain, eg: not across an administrative boundary. == no overlap with the declared intended use of DHCPv6 PD. Instead i could rather see ANI/GRASP used inside the domain and then DHCP/DHCPv6-PD be used on the edge of the domain to client (non-ANI devices). > > 2. Prefix Management Parameters > > I do not understand from the text what prefix length is described in 6.1. Maybe i am misunderstanding how the proposed PD mechanism should work, but in my understanding, a device has at least TWO type of prefixes: > > GRASP/(+DHCP-PD) +---------+ > requested | router | ------ Interfaces with assigned prefixes > <-----------------> | with | ... "Assigned prefix-length 'APL'" > prefix-length | PM-ASA | ------ or > 'RPL' +---------+ GRASP/DHCP-PD requests via downstream PM-ASA > > If RPL == APL, then there is no prefix aggregation. This may be acceptable (==scale well enough) at GRASP/DHCP-PD signaling level. If thats what the authors have in mind then that should be written explicitly. > > Note that if RPL == APL, then this will result in more prefixes at the routing level because all APLs can be from different prefixes and may not be aggregateable. IMHO, achieving aggregation and managing that via PM-ASA would be a big benefit of PM-ASA. > > Aka: If the document intends to support RPL < APL, then that should be better described. For example, section 6.1 could for each role have simply those two parameters (requested_prefix_length, > assigned_prefix_length): > > [ > [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_length", 56] ], > [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_length", 64] ], > [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ] ] > > Thre assigned_prefix_length is of course most important if the downstream is an interface where the router with PM-ASA needs to configure the prefix and the addresses are assigned by SLAAC or DHCP from the router itself. If the downstream is not a local interface but requests from PM-ASA, then the prefix can be determined by the downstream PM-ASA. > > 3. Mobile network roles > > section 6.1: Please expand (in parenthesis) the abbreviations you use on first use, eg: > IPRAN, RNC in section 6.1. Please check any other unexplained TLAs in the document. > > A good picture with RSG, ASG, CSG would be great and help. Especially if you want to take the prior suggestion into account of what prefix length would be required in which role device. > > 4. If you read the point 5 below, i think there are a lot of options how PDs with ASAs can be done. > All of these options would require further details such as more GRASP objective parameters, more description of the ASA state machinery, the individual GRASP negotiation steps etc. > I do not think we want to go through all that detail work because that is IMHO easier done by first building prototypes, and instead having the document rather be a "framework" or "architecture document instead of an ASA functional specification. To that end, it would IMHO be prudent to say so, for example before the last two paragraphs of the introduction: > > proposed text, as 3rd last paragraph of introduction: > > This document is not a functional specification of the proposed autonomic function > "prefix management" or all detail all the aspects of GRASP objective parameters and ASA procedures > necessary to achieve all the different options of building a complete system. Instead it > describes the architectural framework utilizing the components of the ANI and outlines the > different deployment options and aspects and defines simple type of objectives in GRASP to > start building the system as well as some basic parameter examples. > > 5. Abstract deployment pictures / solution overview: > > I think it would help in understanding the document if it would include a logical deployment model pictures with explanations of the target deployment models. Ideally comparing to how this is done with DHCP. > > For example: In the introduction, there are some high level, very suggestive statements about limitations of DHCP (non-autonomicity). Its really hard to detail why/how the PD solution improves over this without a more explicit comparison of some DHCP deployment model example and a PD deployment model example. > > So, i have appended two proposed texts: 5.1 for what i understand to be the two most common DHCP deployment models, and 5.2 for what i understand to be the proposed PD deployment model. > > I would strongly suggest to consider using 5.2 in the document - or something equivalent. > Otherwise its IMHO hard to follow / understand how PD is meant to work. > > Brian Carpenter already proved the feedback that a section like 5.1 might be contentuous and also incomplete because centralized address management has a wide range of options not only limited to DHCP but also involving Radius and other protocols - and there is even a whole working group in the making (CASM - coordinated address space management). > > So maybe my proposed 5.1 would better go into an appended with sufficient preface stating exactly that these are just examples, and that there are many more deployment models, and that there are no current IETF recommendations or documents laying out such complete deployment pictures. (which IMHO is exactly one of the may problems). If folks feel that any more explicit description of even exemplary DHCP deployment models is inappropriate because it would get too contentuous, then its almost impossible to make statements about the limitations about DHCP in the introduction. But without trying to give an example and getting backpressure from reviewers, its IMHO a dead end:wq > > > 5.1. Address & Prefix management with DHCP > > edge > dynamic, "netconf/YANG" interfaces > <-----------------> +-------------+ > +-------------+ <- telemetry | edge router/|+ ------ +--------+ > |config server| ..... Domain .... | DHCP server || ... | CPE |-+ LANs > +-------------+ +-------------+| ------ +--------+ | (----| ) > +-------------+ DHCP/ +---------+ > DHCPv6 / PD > > Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD (RF3633) for IPv6 capable CPE that are router and have LANs behind them. > > This requires various coordination functions via some backend system depicted as "config server": The address prefixes on the edge interfaces should be slightly larger than required for the number of CPE connected so that the overall address space is best used. > The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router. If too fine grained prefixes are used, this will result in large routing tables across the "Domain". If too coase grained prefixes are used, address space is wasted. > > There is no standard describing algorithms for how config servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization. > There are currently no complete YANG models that a config server could use to perform these actions (including telemetry of assigned adddresses from such distributed DHCP servers). > For example, a YANG model for controlling DHCP server operations is still in draft (draft-liu-dhc-dhcp-yang-model-06). > > Due to these and other problems of the above model, the more common DHCP deployment model is as > follows: > > edge > +-------------+ initial, "CLI" interfaces > |config server| -----------------> +-------------+ > +-------------+ | edge router/|-+ ------ +--------+ > | ..... Domain .... | DHCP relay | | ... | CPE |-+ LANs > +-------------+ +-------------+ | ------ +--------+ | (----| ) > |DHCP server | +--------------+ DHCP/ +---------+ > +-------------+ DHCPv6 / PD > > > Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber identifying options into DHCP requests from CPE (eg: rfc3046, rfc6221), the DHCP server has complete policies for address assignments and prefixes useable on every edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address/address-prefix into the routing table of the edge router which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the Domain (the same. > > There is no comprehensive standardization of these solutions. RFC3633 section 14. for example simply refers to "a [non-defined] protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router". > > 5.2 Prefix management with ANI/GRASP > > With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model is intended to look as follows: > > |<................... ANI Domain / ACP...................>| (...) ............-> > > Roles > | > v "Edge routers" > GRASP parameter +----------------+ > Network wide parameters/policy | PM-ASA | downstream interfaces > | |(DHCP-functions)| ------ > v "central device" +----------------+ > +-------+ ^ +--------+ > |PM-ASA | <................... GRASP .... .... | CPE |-+ ( LANs ) > +-------+ . v |(PM-ASA)| | ----| > . +........+ +----------------+ +--------+ | > +...........+ . PM-ASA . | PM-ASA | ------ +---------+ > .DHCP server. +........+ |(DHCP-functions)| SLAAC / > +...........+ "intermediate router"+----------------+ DHCP / DHCP-pd > > > The network runs an ANI domain with ACP between some central device (eg: router or ANI enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between the devices and enables the use of GRASP not only for p2p communication, but also for distribution/flooding. > > The central devices and edge-routers run software to support this documents autonomic > IPv6 edge prefix management (PM). In the autonomic networking terminology, such software are called "Autonomic Service Agents" (ASA). The ASA for Prefix Management are called PM-ASA in this document and form together the Autonomic Prefix Management Function. > > Edge-routers can have different roles based on the type and number of CPE attaching to them. > Consider edge routers could be RSG, ASG CSG in mobile aggregation networks (see Section 6.1). > Mechanisms outside the scope of this document make routers aware of their role. > > 1. In a minimum Prefix Managmeent solution, the central device uses the "PrefixManager.Params" > GRASP Objective introduced in this document to disseminate network wide, per-role parameters to edge routers. The PM-ASA use the parameters applying to its role to locallly "configuring" > pre-existing addressing functions. Because PM-ASA do not manage the dynamic assignment of actual > IPv6 address prefixes in this case, the following options can be considered: > > 1.a The edge router connects via downstream interfaces to (host) CPE that each require an address. > The PM-ASA sets up for each such interface a DHCP requesting router (according to RFC3633) to request an IPv6 prefix for the interface. The routers address on the downstream interface can be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to RFC3633) is required. Its address can be another parameter from the GRASP Objective. > > 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in 1.a. > > 2. In a solution without a central DHCP server, the PM-ASA on the edge routers do not only learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. > In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device. These addresses are then used by the PM-ASA on the edge routers to edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting > IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It need to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded. > > This solution is quite similar to the initial described IPv6 DHCP deployment model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provides the automation to make this approach work more easily than it is possible today. > > 3. The address pool(s) from which prefixes are allocated do not need to be taken all from one central location. Edge router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further > (smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can not get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed. > > 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built (indicated in he picture via a dotted intermediate router). This would require additional parameters to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the prefixes can be delegated. This is not detailed further below. > > 5. In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE"), then GRASP will extend into the actual customer sites and can equally run a PM-ASA. All the options described in points > 1..4 above would then apply to the CPE as the edge router with the mayor changes being that > a) a CPE router will most likley not need to run DHCPv6 PD itself, but only DHCP address assignment, > b) The edge routers to which the CPE connect would most likely become ideal places to run a hierarchical instance of PD-ASAs on as outlined in point 1. -- --- tte@cs.fau.de From nobody Wed Jun 7 13:25:10 2017 Return-Path: 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 E2226129B38; Wed, 7 Jun 2017 13:25:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 f1HIMSLrMfby; Wed, 7 Jun 2017 13:25:07 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 6B408129AEE; Wed, 7 Jun 2017 13:25:07 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id u26so2636063pfd.2; Wed, 07 Jun 2017 13:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6kfGY9YNcwQIVf9MoWXMkoEMSegaZWE/D0vM+z5lYvg=; b=k+2fdTbFH/lUoSi0jNs1hGtzjD/4SG6r1rag+8sIP4V4t4Qd5Fi1E/ZtlyQuNYS2y7 vX/aGO69s2arj9PntV544OpOsL//bERHaGZ0OVEicXurH6xmzrzmaPyaO9ziXb+nkXjo 2yW11YixZOzUUFaD2JIldCsiPoaAx9qbqGD1hfJyLFDFVwvQo4qy0hu3VWGp5J1AKoYD FWzwTLAQjlbC6Ai2qDJbBwAArNsqK6ZQl0agO28wrrzQ2sAkrByt6wfMgdg4AS/RWLVX 9wn74PgH1JqvhVU8nl8mnMthlM6+e+ObNQMQ04LBHohbniBiWVgeAWCXA/a414Gclcvj ICCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6kfGY9YNcwQIVf9MoWXMkoEMSegaZWE/D0vM+z5lYvg=; b=flCmep+9wdOH07FJY/HavGcjXHA3QK1uNWQ3gX6ExK1WCBQGI7tbSpnyt+juFor9Km DUCcm2uubDvWvYJwAbUjI3pNwOextflQEPmQsnKffuk2ocnGIAQg90Rw0Ec8hxYsLBEC U1uftmd46taNyRAp83GjN3YPZbdMuMkvW9RKoX8YI/vgtyrLCHIwah/DLVHCtgMO3ktT HigtHQGMGEvBQB8NhM8pKm/fG2n5MCdp5r9CFbIbO/BUtNaKeuFBYMbmYR+QA8/nOq6o HuCHavLBU5E9w/ct9QQg4zPrpYLL2W3J0+McgdShjbJDjqV4/jzOYhV8MAjSX6wh3QM0 PJPg== X-Gm-Message-State: AODbwcCSEDIyHcwR8YSpgFWrZMtFH+vdPV21kcWJpU2Tt48YcsGJ4LaF OYdWjT7gex4hcmNw X-Received: by 10.84.130.65 with SMTP id 59mr30369919plc.233.1496867106879; Wed, 07 Jun 2017 13:25:06 -0700 (PDT) Received: from [192.168.178.21] (44.219.69.111.dynamic.snap.net.nz. [111.69.219.44]) by smtp.gmail.com with ESMTPSA id u85sm6144698pfg.73.2017.06.07.13.25.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 13:25:06 -0700 (PDT) To: Toerless Eckert , Duzongpeng Cc: "anima@ietf.org" , "draft-ietf-anima-prefix-management@ietf.org" References: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> <20170607192438.GB20021@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1e2ffffe-766c-ef75-4bd4-6b501689ee3a@gmail.com> Date: Thu, 8 Jun 2017 08:25:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170607192438.GB20021@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [draft-ietf-anima-prefix-management-03] review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:25:09 -0000 On 08/06/2017 07:24, Toerless Eckert wrote: ... >> I agree with Brian's suggestion about deleting the PD issue from this document. >> >> It is a realization problem and deleting it will not cause too much misunderstanding. > > Instead of deletion it might be more helpful to write text that explains as i did To be clear, my idea is to delete the PD flag from the objective, since it actually serves no purpose. Explaining how DHCPv6/PD might be used along with the GRASP mechanism is useful. Explaining how RADIUS might be used is useful too. Anyway, there will be a new draft to discuss. Brian From nobody Wed Jun 7 13:37:45 2017 Return-Path: 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 454E3129AC7 for ; Wed, 7 Jun 2017 13:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 5mtZlIL5dVBS for ; Wed, 7 Jun 2017 13:37:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDFA124BE8 for ; Wed, 7 Jun 2017 13:37:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 51535E245; Wed, 7 Jun 2017 16:38:29 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54BB96380F; Wed, 7 Jun 2017 16:37:40 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" cc: "Roberta Maglione \(robmgl\)" In-Reply-To: References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] RPL alternatives in ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:37:43 -0000 --=-=-= Content-Type: text/plain Roberta Maglione (robmgl) wrote: >> But in some closed solutions, multi-vendor interoperation is not the >> No.1 consideration for customers. > If you think that multi-vendor interoperability is not needed what's > the point of making a standard? Why discussing it here? You could make > your own choice for protocol without asking for WG opinion/consensus. Exactly, well said. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk4ZBQACgkQgItw+93Q 3WUVTgf8DJnuNdyvbJs+7aI2ckgLhajafWwCH+Cnc4bX3ZJnrDUi7MjeuLv7T8au Fk1eaQO6CjA2OgKIUiXvyP6iYMpMo4Cp+B7S7TUgO9Ty7Egjg3KivS1yrox6yo23 10h86SD3bhpz2ueKUOCOiFdAzDBn3mSl39Y0zII5Pp/Mx0riNZ2QYwg2uisC7H0H Vy30uTCmVn3BGgiefI5tKht9t2BzQua9h+cluTJLmnw0LafT6gN76mhz8uIosPQ5 f31I31X8KjEuufVXdDfl9FpLXz2Ze1dwB/dU/zLd/nRY0RCMPM0VY1yWM8IWwzpP /zzt8ri+urlvN6gO2AYTjTveWmDUCg== =q4ys -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 7 13:55:43 2017 Return-Path: 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 C3996128854 for ; Wed, 7 Jun 2017 13:55:41 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 Apyg8IwvbSmc for ; Wed, 7 Jun 2017 13:55:39 -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 CB3E5124BE8 for ; Wed, 7 Jun 2017 13:55:38 -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 3A13C58C4EC; Wed, 7 Jun 2017 22:55:34 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 20306B0C21B; Wed, 7 Jun 2017 22:55:33 +0200 (CEST) Date: Wed, 7 Jun 2017 22:55:33 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:55:42 -0000 On Wed, Jun 07, 2017 at 12:38:42PM +1200, Brian E Carpenter wrote: > EKR didn't like the loose mention of TLS. It would be perfectly > fine to revive SONN in the ACP draft or even in a separate > ACP 'profile' draft. But I had the impression that IPSec was > the preferred model for ACP. In either case you will have exactly > the same discussion with EKR, and he's probably right ;-). In other > words you have to fully describe how cert/key management works. > Ack. see PM with Eric. I think we can have all that text in ACP. > I think DULL is more fundamental to GRASP. Yes. > and it doesn't contain any undefined mechanism. Well... i disagree (SONN didn't have this either), but not worth arguing. > A reminder: assuming GRASP is approved by the IESG, it will > block at the RFC Editor until the ACP is also approved. So I > think it makes sense to focus all the security details in the > ACP draft, to minimise loops between the documents. Well... I would love if the GRASP RFC would make it obvious that GRASP could proliferate into as many environments as its beneficial. To me this means that GRASP should say that it can run on any secure transport and that ACP is just an example thereof. Maybe specify the requirements of the secure transport. But ACP should not need to be a normative reference. Now i don't know if you even want to have this argument with the IESG... Right now thhe text does tie GRAASP very tightly to the ACP. Would IP have to be a normative reference for a new transport protocol built today ? [lots of ignored proposed text deleted] > I think your text and the existing text intend to say the same thing. > But do you really want to go back to the IESG with a completely new > text? Can we wait and see what the DISCUSSing ADs think about the > changes so far? I can only make sugestions, you decide. > > So... IMHO, it would be great if we had some clear terminology, eg: > > > > GRASP domain: a connected graph of nodes. Each node in the graph is a (normal) > > instance of GRASP running on a different (virtual) device. > > I have always ducked this because I understood that discussing domains > and domain boundaries was future work for Anima. But logically, > that makes sense. I think this is today quite simple. I also think that one can not really explain what a "secure transport is without having the term of a GRASP domain: The secure transport needs to provide authentication (and optionally encryption) for unicast packets between any GRASP peers in the GRASP domain. It must prohibit traffic between any GRASP peers in the GRASP domain and nodes outside the GRASP domain. ACP can provide secure transport for a GRASP domain that extends across a complete ACP because it offers these security functions. > > GRASP neighbors: grasp nodes to which an instance has an edge in the graph > > GRASP peers: all nodes (GRASP instances) in the graph > > > > Instances of GRASP expect that they can unicast send/receive packets to all peers. > > GRASP does not need to know the addresses of neighbors because it addresses > > neighbors via link-local multicast (M_DISCOVERY and M_FLOOD). > > > > The section 2.5.2 about constrained instances : > > > > With my proposed text qove IMHO you would not need any additional text for the > > non-ACP case. > > I'd need to read the whole thing to be sure of that. > > > I also do no not understand where outside of DULL you would need the consideration > > of not doing Rapid Mode. > > Can we assume secure multicast except inside the ACP? > I don't think so. Multicast is a red herring. The fact that we use link-local-scope multicast is to make life easier for GRASP, but when using the ACP you would not even need it, because you do know upfront the IPv6 link-local unicast addresses of your GRASP peers. Instead of sending link-local multicast you could therefore also send link-local unicast. Consider a non-ACP solution for GRASP: You just rely on the autonomic domain certificate. You use DULL to on all interfaces to discover your GRASP neighbors. You set up persistent TLS connections to your GRASP neighbors. You set up dynamic TLS connections to your (remote) GRASP peers. Aka: Same thing as when using ACP except that you replace TCP with TLS. Consider physcial security based secure transport (which the IETF crypto mafia would of course argue is totally unacceptable): The physcial infrastructure is secured, eg: Data Center internal network. Any links outside the physcial secure domain have filters for GRASP link-local multicast. Maybe even filters for some GRASP specific TCP port to be even more secure. Again, you run DULL for GRASP neighbor discovery. You build GRASP TCP to all neighbors, you build dynamic TCP to all GRASP peers. Its not really rocket science. Aka: the non-DULL "multicast is always inside whatever you define to be your secure transport. Cheers Toerless > > On Tue, Jun 06, 2017 at 10:22:20AM +1200, Brian E Carpenter wrote: > >> This version includes a second round of responses to IESG comments. > >> > >> We may not be done yet, but please check the diffs. Here are the main changes: > >> > >> Removed all mention of TLS, including SONN, since it was under- > >> specified. > >> > >> Clarified other text about trust and security model. > >> > >> Banned Rapid Mode when multicast is insecure. > >> > >> Explained use of M_INVALID to support extensibility > >> > >> Corrected details on discovery cache TTL and discovery timeout. > >> > >> Improved description of multicast UDP w.r.t. RFC8085. > >> > >> Clarified when transport connections are opened or closed. > >> > >> Noted that IPPROTO values come from the Protocol Numbers registry > >> > >> Protocol change: Added protocol and port numbers to URI locator. > >> > >> Removed inaccurate text about routing protocols > >> > >> Moved Requirements section to an Appendix. > >> > >> Other editorial and technical clarifications. > >> > >> Regards > >> Brian > >> > >> On 06/06/2017 08:57, internet-drafts@ietf.org wrote: > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >>> This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > >>> > >>> Title : A Generic Autonomic Signaling Protocol (GRASP) > >>> Authors : Carsten Bormann > >>> Brian Carpenter > >>> Bing Liu > >>> Filename : draft-ietf-anima-grasp-13.txt > >>> Pages : 79 > >>> Date : 2017-06-05 > >>> > >>> Abstract: > >>> This document specifies the GeneRic Autonomic Signaling Protocol > >>> (GRASP), which enables autonomic nodes and autonomic service agents > >>> to dynamically discover peers, to synchronize state with each other, > >>> and to negotiate parameter settings with each other. GRASP depends > >>> on an external security environment that is described elsewhere. The > >>> technical objectives and parameters for specific application > >>> scenarios are to be described in separate documents. Appendices > >>> briefly discuss requirements for the protocol and existing protocols > >>> with comparable features. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-anima-grasp-13 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13 > >>> > >>> > >>> 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. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jun 7 14:04:34 2017 Return-Path: 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 16D621294CE for ; Wed, 7 Jun 2017 14:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 q-Rxnym0aBIH for ; Wed, 7 Jun 2017 14:04:31 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 36EF8124BE8 for ; Wed, 7 Jun 2017 14:04:31 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id q97so10974609wrb.2 for ; Wed, 07 Jun 2017 14:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PAE32LmMURKwFlzLvONuADBeNkYAht+g9OhvPQOxrjc=; b=jEqhON7/1oBUkJV8QlvwOJfPg3a8H5KB0AsfN0T7C2Od3k4AHD6Jalpc9F3+RMqHRK qM8egh+HloYJtk3beI0WIEKbUZCZBubDbufmWxWJ/IMsLliT1FN2Ifei5nzogFVgUGzR gYPKUd/WWjqnAogG526QbQPI2JErCoGmhTlkC3yNlmxUzTLynSKwLgf4X4AjYNWwBllc X5J21jsOS5aKITvidL8H2+nYQJqUxEN+DnjH7dCGnZ1RdGen10Zv/qe9Nuf4G6orDNcl 1k799w2LmPWxd5kArA6srgwikBDvBM/7Gwyrfah2dkkoWatHxtXw027i8tmFwHmsVDLB f2gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=PAE32LmMURKwFlzLvONuADBeNkYAht+g9OhvPQOxrjc=; b=Ag/BMMv0T+Pk4V7EFRug7zMZmusaGzAjVzMvLuO0/nILlUW72lstjkMpvHcypDVfNp VxZk9xAd6b9jT8jeiwgw8ImprQGpxflPgKUUcGyUjpM+O5/NkXZ6uVRxPkuqi2YGlVdQ iSA4zK0i9OBcPgJ+vx8d/I1tEjQxNS4FJ9Qbicoc4juGhE80vPPfvpSYiq2UodqZZVdR OcenFGD053KZYudsh9gN43ZmdGsk4ogJgN6FfdwwAwz8WN6fvY00FH+NX1o2lVQLR1kW WwKKVCklMt9KwgIL840augFqrqn4PoA2OWp+882Gm4+IH7pSNmlaBD1M9zTuAPNXgPpm 4Z/g== X-Gm-Message-State: AODbwcB2ZxU4PHNGl6aVsrChCd2fID/LMhs8MUBV9IpUPfJ2vEJMdGc/ e6FAQRIqdiIiXZ/H+AgEgnQ5TO3SeQ== X-Received: by 10.223.176.85 with SMTP id g21mr22987564wra.26.1496869469786; Wed, 07 Jun 2017 14:04:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.210 with HTTP; Wed, 7 Jun 2017 14:04:29 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: <29765.1496867860@obiwan.sandelman.ca> References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> <29765.1496867860@obiwan.sandelman.ca> From: Behcet Sarikaya Date: Wed, 7 Jun 2017 16:04:29 -0500 Message-ID: To: Michael Richardson Cc: "anima@ietf.org" , "Roberta Maglione (robmgl)" Content-Type: multipart/alternative; boundary="001a11498306059a7805516515fa" Archived-At: Subject: Re: [Anima] RPL alternatives in ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:04:33 -0000 --001a11498306059a7805516515fa Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 3:37 PM, Michael Richardson wrote: > > Roberta Maglione (robmgl) wrote: > >> But in some closed solutions, multi-vendor interoperation is not the > >> No.1 consideration for customers. > > > If you think that multi-vendor interoperability is not needed what's > > the point of making a standard? Why discussing it here? You could > make > > your own choice for protocol without asking for WG opinion/consensus. > > Exactly, well said. > > I think the quote is taken out of context, that is not the main message in Bing's mail as far as I understood. Your mailer is chopping off the content which I copy here: >> Hi all, >> >> When I discuss ACP with some product people, they are always curious >> about why we choose RPL for routing. >> I understand the benefits of RPL in ACP, it is lightweight and much >> more scalable in a single routing area, but most of the non-IoT >> network devices seem like lack the support of RPL. >> >> So, please pardon my iteration on this problem, can we possibly make >> another more traditional IGP literally legal in the ACP document? (e.g. >> ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple >> protocols would potentially cause interoperation issue. But in some >> closed solutions, multi-vendor interoperation is not the No.1 >> consideration for customers. If ACP allows ISIS-autoconf or >> OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT network devices. >> >> Any comments? Or eggs :) >> >> B.R. >> Bing Behcet > > --001a11498306059a7805516515fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 3:37 PM, Michael Richardson &l= t;mcr+ietf@sande= lman.ca> wrote:

Roberta Maglione (robmgl) <robmgl@ci= sco.com> wrote:
=C2=A0 =C2=A0 >> But in some closed solutions, multi-vendor interoper= ation is not the
=C2=A0 =C2=A0 >> No.1 consideration for customers.

=C2=A0 =C2=A0 > If you think that multi-vendor interoperability is not n= eeded what's
=C2=A0 =C2=A0 > the point of making a standard? Why discussing it here? = You could make
=C2=A0 =C2=A0 > your own choice for protocol without asking for WG opini= on/consensus.

Exactly, well said.


I think the quote is taken out of cont= ext, that is not the main message in Bing's mail=C2=A0as far as I under= stood.

Your mailer is chopping off the content wh= ich I copy here:

>> Hi all,
>>
= >> When I discuss ACP with some product people, they are always curio= us
>> about why we choose RPL for routing.
>> I understan= d the benefits of RPL in ACP, it is lightweight and much
>> more s= calable in a single routing area, but most of the non-IoT
>> netwo= rk devices seem like lack the support of RPL.
>>
>> So, = please pardon my iteration on this problem, can we possibly make
>>= ; another more traditional IGP literally legal in the ACP document? (e.g.>> ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple
= >> protocols would potentially cause interoperation issue. But in som= e
>> closed solutions, multi-vendor interoperation is not the No.1=
>> consideration for customers. If ACP allows ISIS-autoconf or>> OSPFv3-autoconf, I think ACP could be more widely adopted in non-= IoT network devices.
>>
>> Any comments? Or eggs :)
&= gt;>
>> B.R.
>> Bing

Behcet= =C2=A0

--001a11498306059a7805516515fa-- From nobody Wed Jun 7 14:29:30 2017 Return-Path: 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 E84D1128CDB; Wed, 7 Jun 2017 14:29:28 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 lmn-ubxiQhUs; Wed, 7 Jun 2017 14:29:25 -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 58C20127180; Wed, 7 Jun 2017 14:29:25 -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 C540158C4EC; Wed, 7 Jun 2017 23:29:20 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A880EB0C21C; Wed, 7 Jun 2017 23:29:20 +0200 (CEST) Date: Wed, 7 Jun 2017 23:29:20 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: anima@ietf.org, draft-ietf-anima-prefix-management@ietf.org Message-ID: <20170607212920.GE20021@faui40p.informatik.uni-erlangen.de> References: <20170607001104.GD23319@faui40p.informatik.uni-erlangen.de> <85488f61-1772-df24-4171-6275aa85abc0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85488f61-1772-df24-4171-6275aa85abc0@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] [draft-ietf-anima-prefix-management-03] review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:29:29 -0000 On Wed, Jun 07, 2017 at 01:01:34PM +1200, Brian E Carpenter wrote: > > The note in 4.3 makes it sound as if there is a concern by the authors that this proposal > > could potentially be seen as being in conflict with DHCPv6. > > Yes, and I think that is a mistake. It would be an equal mistake to > see this as in conflict with Radius. Rather than discussing DHCPv6/PD > or Radius, I think they are really out of scope. So... i'll wait for the next rev wrt. to seeing an answer of how the text can improve on better motivating an answer to the question "how does the current solution suite suck and how could i imagine a PM solution to look and operate like in deployment". > As in a previous > message to the WG, my idea is to drop the "PD" flag in the proposed > objective. I'd like that very much. Btw: While we're at naming: The whole thing is IMHO in terms of the reference model an "autonomic function". Would help cross-doc consistency to use that term. > An ASA that uses this GRASP objective to obtain a pool of prefixes > can then use DHCPv6/PD, Radius, or any other method it wants > to hand prefixes out to client routers. It should be completely > independent. Pls. do not forget the most simple case where there are no "prefixes" handed out, but just individual addresses and the PM-ASA just runs on an edge-router setting up the interface prefixes locally. > (But including some 'serving suggestions' may well be useful, > as in your items 5.1 and 5.2.) > > Skipping ahead: > > ... > > > 2. Prefix Management Parameters > > > > I do not understand from the text what prefix length is described in 6.1. Maybe i am misunderstanding > > how the proposed PD mechanism should work, but in my understanding, a device has at least > > TWO type of prefixes: > > > > GRASP/(+DHCP-PD) +---------+ > > requested | router | ------ Interfaces with assigned prefixes > > <-----------------> | with | ... "Assigned prefix-length 'APL'" > > prefix-length | PM-ASA | ------ or > > 'RPL' +---------+ GRASP/DHCP-PD requests via downstream PM-ASA > > > > If RPL == APL, then there is no prefix aggregation. This may be acceptable (==scale well enough) > > at GRASP/DHCP-PD signaling level. If thats what the authors have in mind then that should > > be written explicitly. > > > > Note that if RPL == APL, then this will result in more prefixes at the routing level because > > all APLs can be from different prefixes and may not be aggregateable. IMHO, achieving aggregation > > and managing that via PM-ASA would be a big benefit of PM-ASA. > > > > Aka: If the document intends to support RPL < APL, then that should be better described. For > > example, section 6.1 could for each role have simply those two parameters (requested_prefix_length, > > assigned_prefix_length): > > > > [ > > [["role", "RSG"],["requested_prefix_length", 34], ["assigned_prefix_length", 56] ], > > [["role", "ASG"],["requested_prefix_length", 44], ["assigned_prefix_length", 64] ], > > [["role", "CSG"],["requested_prefix_length", 56], ["assigned_prefix_length", 64] ] > > ] > > The intention is "assigned_prefix_length", i.e. what the gateway > concerned will assign to connected routers. I'm not sure that > we need to specify the requested length; that could be decided > by a heuristic in the gateway when its pool is getting low. > I don't have a strong opinion about that, but I did code a > heuristic in https://www.cs.auckland.ac.nz/~brian/graspy/pfxm2.py > so it can be done. Thats fine. But the text didn't explain that. Aka: some understandable example of how aggregation can happen. > > Thre assigned_prefix_length is of course most important if the downstream is an interface > > where the router with PM-ASA needs to configure the prefix and the addresses are assigned > > by SLAAC or DHCP from the router itself. If the downstream is not a local interface but > > requests from PM-ASA, then the prefix can be determined by the downstream PM-ASA. > > The prefix that the client would like, yes, but the prefix length > that the network allows surely has to be defined by the NOC. > So maybe it should be "minimum_allowed_prefix_length" > > The text about these parameters is intentionally not definitive. > I think only experience will tell us the correct answer(s). Right. But its IMHO a mayor important design aspect so it should be mentioned. > > 3. Mobile network roles > > > > section 6.1: Please expand (in parenthesis) the abbreviations you use on first use, eg: > > IPRAN, RNC in section 6.1. Please check any other unexplained TLAs in the document. > > > > A good picture with RSG, ASG, CSG would be great and help. Especially if you want to take > > the prior suggestion into account of what prefix length would be required in which role device. > > > > 4. If you read the point 5 below, i think there are a lot of options how PDs with ASAs can be done. > > All of these options would require further details such as more GRASP objective parameters, > > more description of the ASA state machinery, the individual GRASP negotiation steps etc. > > I do not think we want to go through all that detail work because that is IMHO easier done by > > first building prototypes, and instead having the document rather be a "framework" or > > "architecture document instead of an ASA functional specification. To that end, it would IMHO be > > prudent to say so, for example before the last two paragraphs of the introduction: > > Yes. And as far as I can see, we might need to express anything > that the CASM people can express, for the same reasons: > draft-sun-casm-address-pool-management-yang push(enless-reading-list, draft-sun-casm-address-pool-management-yang) > > proposed text, as 3rd last paragraph of introduction: > > > > This document is not a functional specification of the proposed autonomic function > > "prefix management" or all detail all the aspects of GRASP objective parameters and ASA procedures > > necessary to achieve all the different options of building a complete system. Instead it > > describes the architectural framework utilizing the components of the ANI and outlines the > > different deployment options and aspects and defines simple type of objectives in GRASP to > > start building the system as well as some basic parameter examples. > > Yes, it's Informational for a reason. > > Thanks > Brian Thanks, Toerless > > > > 5. Abstract deployment pictures / solution overview: > > > > I think it would help in understanding the document if it would include a logical deployment > > model pictures with explanations of the target deployment models. Ideally comparing to how this > > is done with DHCP. > > > > For example: In the introduction, there are some high level, very suggestive statements about limitations > > of DHCP (non-autonomicity). Its really hard to detail why/how the PD solution improves over > > this without a more explicit comparison of some DHCP deployment model example and a PD > > deployment model example. > > > > So, i have appended two proposed texts: 5.1 for what i understand to be the two most common > > DHCP deployment models, and 5.2 for what i understand to be the proposed PD deployment model. > > > > I would strongly suggest to consider using 5.2 in the document - or something equivalent. > > Otherwise its IMHO hard to follow / understand how PD is meant to work. > > > > Brian Carpenter already proved the feedback that a section like 5.1 might be contentuous and > > also incomplete because centralized address management has a wide range of options not only > > limited to DHCP but also involving Radius and other protocols - and there is even a whole working group > > in the making (CASM - coordinated address space management). > > > > So maybe my proposed 5.1 would better go into an appended with sufficient preface stating > > exactly that these are just examples, and that there are many more deployment models, and > > that there are no current IETF recommendations or documents laying out such complete deployment > > pictures. (which IMHO is exactly one of the may problems). If folks feel that any more > > explicit description of even exemplary DHCP deployment models is inappropriate because > > it would get too contentuous, then its almost impossible to make statements about > > the limitations about DHCP in the introduction. But without trying to give an example > > and getting backpressure from reviewers, its IMHO a dead end:wq > > > > > > 5.1. Address & Prefix management with DHCP > > > > edge > > dynamic, "netconf/YANG" interfaces > > <-----------------> +-------------+ > > +-------------+ <- telemetry | edge router/|+ ------ +--------+ > > |config server| ..... Domain .... | DHCP server || ... | CPE |-+ LANs > > +-------------+ +-------------+| ------ +--------+ | (----| ) > > +-------------+ DHCP/ +---------+ > > DHCPv6 / PD > > > > Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server > > assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD (RF3633) > > for IPv6 capable CPE that are router and have LANs behind them. > > > > This requires various coordination functions via some backend system depicted > > as "config server": The address prefixes on the edge interfaces should be slightly larger > > than required for the number of CPE connected so that the overall address space is best used. > > The config server needs to provision edge interface address prefixes and DHCP parameters > > for every edge router. If too fine grained prefixes are used, this will result in large routing > > tables across the "Domain". If too coase grained prefixes are used, address space is wasted. > > > > There is no standard describing algorithms for how config servers would best perform this > > ongoing dynamic provisioning to optimize routing table size and address space utilization. > > There are currently no complete YANG models that a config server could use to perform > > these actions (including telemetry of assigned adddresses from such distributed DHCP servers). > > For example, a YANG model for controlling DHCP server operations is still in draft > > (draft-liu-dhc-dhcp-yang-model-06). > > > > Due to these and other problems of the above model, the more common DHCP deployment model is as > > follows: > > > > edge > > +-------------+ initial, "CLI" interfaces > > |config server| -----------------> +-------------+ > > +-------------+ | edge router/|-+ ------ +--------+ > > | ..... Domain .... | DHCP relay | | ... | CPE |-+ LANs > > +-------------+ +-------------+ | ------ +--------+ | (----| ) > > |DHCP server | +--------------+ DHCP/ +---------+ > > +-------------+ DHCPv6 / PD > > > > > > Dynamic provisioning changes to edge routers are avoided by using a central DHCP server > > and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the > > edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber > > identifying options into DHCP requests from CPE (eg: rfc3046, rfc6221), the DHCP server > > has complete policies for address assignments and prefixes useable on every > > edge-router/interface/subscriber-group. When the DHCP relay sees the DHCP reply, it inserts > > static routes for the assigned address/address-prefix into the routing table of the edge router > > which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE > > and LANs reachable across the Domain (the same. > > > > There is no comprehensive standardization of these solutions. RFC3633 section 14. for example > > simply refers to "a [non-defined] protocol or other out-of-band communication to add routing > > information for delegated prefixes into the provider edge router". > > > > 5.2 Prefix management with ANI/GRASP > > > > With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model > > is intended to look as follows: > > > > |<................... ANI Domain / ACP...................>| (...) ............-> > > > > Roles > > | > > v "Edge routers" > > GRASP parameter +----------------+ > > Network wide parameters/policy | PM-ASA | downstream interfaces > > | |(DHCP-functions)| ------ > > v "central device" +----------------+ > > +-------+ ^ +--------+ > > |PM-ASA | <................... GRASP .... .... | CPE |-+ ( LANs ) > > +-------+ . v |(PM-ASA)| | ----| > > . +........+ +----------------+ +--------+ | > > +...........+ . PM-ASA . | PM-ASA | ------ +---------+ > > .DHCP server. +........+ |(DHCP-functions)| SLAAC / > > +...........+ "intermediate router"+----------------+ DHCP / DHCP-pd > > > > > > The network runs an ANI domain with ACP between some central device (eg: router or ANI > > enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch > > communication channel between the devices and enables the use of GRASP not only for p2p > > communication, but also for distribution/flooding. > > > > The central devices and edge-routers run software to support this documents autonomic > > IPv6 edge prefix management (PM). In the autonomic networking terminology, such software are called > > "Autonomic Service Agents" (ASA). The ASA for Prefix Management are called PM-ASA in this document > > and form together the Autonomic Prefix Management Function. > > > > Edge-routers can have different roles based on the type and number of CPE attaching to them. > > Consider edge routers could be RSG, ASG CSG in mobile aggregation networks (see Section 6.1). > > Mechanisms outside the scope of this document make routers aware of their role. > > > > 1. In a minimum Prefix Managmeent solution, the central device uses the "PrefixManager.Params" > > GRASP Objective introduced in this document to disseminate network wide, per-role parameters > > to edge routers. The PM-ASA use the parameters applying to its role to locallly "configuring" > > pre-existing addressing functions. Because PM-ASA do not manage the dynamic assignment of actual > > IPv6 address prefixes in this case, the following options can be considered: > > > > 1.a The edge router connects via downstream interfaces to (host) CPE that each require an address. > > The PM-ASA sets up for each such interface a DHCP requesting router (according to RFC3633) to > > request an IPv6 prefix for the interface. The routers address on the downstream interface can > > be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via > > RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the > > CPEs. A central DHCP server acting as the DHCP delegating router (according to RFC3633) is > > required. Its address can be another parameter from the GRASP Objective. > > > > 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are > > routers and act as DHCPv6 requesting routers. The need to support this could be derived from > > role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests > > to the central DHCP server as in 1.a. > > > > 2. In a solution without a central DHCP server, the PM-ASA on the edge routers do not only > > learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate > > actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. > > In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA > > in the central device. These addresses are then used by the PM-ASA on the edge routers > > to edge routers to configure prefixes on their downstream interfaces to assign addresses > > via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign > > addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting > > IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the > > address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the > > local DHCP servers it starts. It need to monitor the address utilization and accordingly request > > more address prefixes if its existing prefixes are exhausted, or return address prefixes when they > > are unneeded. > > > > This solution is quite similar to the initial described IPv6 DHCP deployment model without > > central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provides the automation to make this > > approach work more easily than it is possible today. > > > > 3. The address pool(s) from which prefixes are allocated do not need to be taken all from > > one central location. Edge router PM-ASA that received a big (short) prefix from a central > > PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used > > in such a way that the PM-ASA would find and select the objective from the closest neighboring > > PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further > > (smaller/shorter) prefixes when it exhausts its own poll (from the central location) and can > > not get further large prefixes from that central location anymore. Because > > the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes > > that have to be injected into the routing tables is limited and the topological proximity > > increases the chances that aggregation of prefixes in the IGP can most likely limit > > the geography in which the longer prefixes need to be routed. > > > > 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built > > (indicated in he picture via a dotted intermediate router). This would require additional parameters > > to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the > > prefixes can be delegated. This is not detailed further below. > > > > 5. In cases where CPEs are also part of the ANI Domain (eg: "Managed CPE"), then GRASP will extend > > into the actual customer sites and can equally run a PM-ASA. All the options described in points > > 1..4 above would then apply to the CPE as the edge router with the mayor changes being that > > a) a CPE router will most likley not need to run DHCPv6 PD itself, but only DHCP address assignment, > > b) The edge routers to which the CPE connect would most likely become ideal places to run a > > hierarchical instance of PD-ASAs on as outlined in point 1. > > > > -- --- tte@cs.fau.de From nobody Wed Jun 7 14:55:46 2017 Return-Path: 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 452F212EB53 for ; Wed, 7 Jun 2017 14:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 1HTyPrZXVHuW for ; Wed, 7 Jun 2017 14:55:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB2F129AD1 for ; Wed, 7 Jun 2017 14:55:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DCCCFE248; Wed, 7 Jun 2017 17:56:29 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BED186380F; Wed, 7 Jun 2017 17:55:40 -0400 (EDT) From: Michael Richardson To: Anima WG cc: Brian E Carpenter , Toerless Eckert In-Reply-To: <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:55:44 -0000 --=-=-= Content-Type: text/plain EXEC SUMM: SONN was extra plumbing with no clear benefits and significant downsides for the security analysis of the entire system. The document is fine as it is. Toerless Eckert wrote: > I was surprised to see SONN go away. I do not understand what was considered to be > underspecified about it. Everything about that text was IMHO "OK". Now i was > not a big fan of the text, but if you do not want to bring it back then IMHO > we would need some other equivalent explanation. > Just as a reminder: The use-case for SONN is the ACP: > - you discover a candidate ACP neighbor with DULL > - You build a TLS connection to that candidate ACP neighbor > - You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg: IPsec > with/without GRE, or dTLS or IP over CoAP or what the heck. 1) I object to negotiating the use of which negotiation protocol to use. It's just asking for complicated state machines with very hard to analyze bid-down attacks at multiple layers. 2) We have no meaningful specification for IP over *TLS thing. (but that, I mean a deployed protocol with an RFC and widespread implementation. We aren't here to invent protocols, but rather to put them together) 3) I have been trying to understand the MACsec KMP, as some would like to run the ACP over MACsec. I originally was led to believe that there was no KMP, but after finding the full specifications, it's clear that there is support for PSK and other things and even IDevID are mentioned. I'd still like to suggest that we negotiate the use of MACsec (or of some yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard, and if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2 minimal implementation can be very small; lwig has some good advice, but it assumes initiator only, and we need both. I can not see a purpose for SONN, and I do not think we can do a proper security analysis, and it forces TLS to be MTI. SONN will therefore add a significant (3-5 pages) of text on how to use TLS properly. I believe that this will confuse the market, and slow implementations significantly (both the writing of, and the performance of). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk4dlwACgkQgItw+93Q 3WV1HwgAwKjVa/TB2CUCeG85z3Ia1i1puJUXzhHQQxdtm20OGUeET1IRFYzyVsR6 GUoFVqtPzbqodwUnRTClCzxsIuWQdFSgcQBOiQaNYjZrD9IijbRbL1EPe+9MFpMW dw/4/qOI2geV4afwnDTDM1htB7b+tjbpcaty7jMtUusBk1GUtXIP3fOK96g2g0Pj bDUeOsu7GUK/qHuocaIjoqqjdImLvaxn+GCvFEjh40W2P1+D/u89h6Ew8M3CJsci 3+3CJVa7wf9R/xeoJRL9U0v+FY4XCk+k9/+UdqOZP5BMR9myuhplQFeRlOW8+IUp L009K5pavKN/tFObXgbXX7iBK1+zng== =8m/P -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 7 15:21:50 2017 Return-Path: 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 8B1DA129527 for ; Wed, 7 Jun 2017 15:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 jD_DrLYdu4in for ; Wed, 7 Jun 2017 15:21:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF8C129494 for ; Wed, 7 Jun 2017 15:21:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F4B720183; Wed, 7 Jun 2017 18:22:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5FA4F6380F; Wed, 7 Jun 2017 18:21:45 -0400 (EDT) From: Michael Richardson To: anima cc: Brian E Carpenter , pthubert@cisco.com, Toerless Eckert In-Reply-To: <20170607000240.GA23319@faui40p.informatik.uni-erlangen.de> References: <20170607000240.GA23319@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] draft-ietf-anima-autonomic-control-plane-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:21:48 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I may be wrong, but it looks to me as if MichaelRs comments and reference to > this new draft about RPL IPinIP header stuff makes it sound as if we MUST > somehow support these IPinIP headers in ACP: It's an argument that we have to have in the ACP document. Yes, we can get away without the RPI header. I'm not happy about it, but I can live with it. I'd like to be tolerant of including them, however. RFC2460bis text lets us clearly state this, and the useofrplinfo revised document will, I think make it clearly ignorable. > Also, during the last IETF, i think MichaelR said something to the extend that > the "profile" defined for RPL via the latest -06 version should rather go into > some form of RPL profile draft.... But if i remember correctly, Pascal told me > there is no such "RPPL profile" draft format. Not at all. The RPL profile template is at: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ (yes, it's expired, never to be published) https://datatracker.ietf.org/doc/rfc7733/ (section 4) https://datatracker.ietf.org/doc/rfc8036/ (section 7) are examples of the RPL profile. > This is something i would prefer as the mandatory minimum ACP requirements > because i am fearful of asking all type of equipment to support RPL routing > protocol specific IPinIP header processing. I am not even sure if i could > today expect to get this IPinIP header processing in all linux that i > might At present RPI is not supported in current Linux kernels, but there are people working on it. RPI headers are produced by OpenWSN and Contiki implementations now. > Not using IPinIP headers does of course come at the limitation of - if i > understand it correctly - a single instance with a single (active) root. > As long as we can have automatic root election so that we have root redundancy, > i think this is a sufficient minimum functionality for ACP. There is always one root per instance, RPI lets you have multiple instances. RPI provides for loop detection (and the resulting: fast repair) which I think that we actually rather need if we expect this to be used for critical function. If we aren't going to depend RPI, we'll need to carefully tweak the RPL parameters so that we get frequent enough announcements. We may be able to leverage the IPsec DPD messages to detect link down's and do reparent events though. That should be easily written up in the ACP document. > - It seems to be easy to make IPinIP support SHOULD for endpoints. Such an > endpoint could only use the default instance/root of RPL. Right ? Yes. > - It is less clear to me if/how its possible to introduce partial support > for IPinIP on transit nodes. I am hping that RPL can automatically > figure out that additional instances/dodags can only work across paths > where all transit nodes support IPinIP. Then the problem is solved. > If this si something RPL can not singnal, then it seems as if a > transit node without IPinIP support would kill non-default instance/transit > paths. We have to do this globally, I think, we will need to define a signal for this, and we have to put this into the DIO. I think this will be generally useful for RPL. Probably it deserves a seperate draft, but let's start it in the ACP document first. > - I am very interested to make non IPinIP capable transit nodes sufficient > for MUST ACP requirements because i am quite sure that a relevant part of > HW accelerated forwarding engines will not support IPinIP routing, so any > mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO > would make me ask to rethink the choice of ACP default routing > protocol. I agree. Note that the worst situation of IPinIP is that the header has to be added and removed at each hop, and the outer IP is a link-local address. Inside the IPsec tunnel, it probably looks like: IPll ESP RPI IP ULP With the IPll ESP RPI part being added/removed at each hop. Based upon 20 years of building drivers for hardware acceleration, I don't think that this will matter much to HW accel. > Q1: Do we agree on this direction ? > Q2: How can we finalize the sufficient/necessary text mods to ACP to express > this ? (profile definition etc..) We need to convene an ACP design team call. I don't think that we can get to that until the voucher and brski and grasp documents are into WGLC. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk4fHkACgkQgItw+93Q 3WUIWQf7Bu7f+WFqH0gkHKH4Idgs7Fq7EEHws8FD98l5UmIJv8lB/EVnp4DYEvuB npx0VsyDZHefUnkI+0cAn0XjMRm+gwZqXo5ruBLs1EqpAi6tzxkkW16+7A59oAjb Y9JlN2as2hzblzeoDPqn0DssnskONYLZPUXm4Cau8D6Wer47hWn9QuX8qSFpIGd1 zHT8qkl682OyAq6qA8Tmsh5D0s/xPcZUPlImBMaqRBTVUOdfCz5640b90pF2Hp5W sBU+rZNlgiqGLFGHaxF50Idr7KBJJ2b2N2LF9jK5i4sc7ZZWYQSAQxAVF0bortbn 3nArurTj6sIGhegiqkvJTkp2joWu+Q== =alwf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 7 15:45:24 2017 Return-Path: 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 D4C67128CD5 for ; Wed, 7 Jun 2017 15:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 9JZ-EaLpoRtG for ; Wed, 7 Jun 2017 15:45:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFCC1270A7 for ; Wed, 7 Jun 2017 15:45:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 19B472009E; Wed, 7 Jun 2017 18:46:09 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D12576380F; Wed, 7 Jun 2017 18:45:19 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: Kent Watsen , "Max Pritikin \(pritikin\)" In-Reply-To: <0397B0D9-151A-4894-9CE1-B615853F53D2@juniper.net> References: <1605740D-96FE-48E0-8E2A-4538CC3C816F@juniper.net> <0397B0D9-151A-4894-9CE1-B615853F53D2@juniper.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] comments on changes to voucher draft coming: Re: pushed voucher files to github X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:45:23 -0000 --=-=-= Content-Type: text/plain Kent asked me to review the changes, and I thought it best to just post to the list since I think my text is a good short summary. Much are based on edits two weeks as as a result of Sheng's thorough review. https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-anima-voucher-02&url2=https://raw.githubusercontent.com/anima-wg/voucher/master/draft-ietf-anima-voucher.txt I didn't find reading the diffs of the XML too informative, so I did the above diff... So summary is: Removed terms: Voucher, Domain, Domain CA. Added terms: Pledge, TOFU. Word smithing on terms. We simplified the voucher contents (in the YANG) as a result of considerations for short-lived vouchers. We added RFC2119 language to the YANG definitions. I'm extremely pleased with your section 6.1 text. Very well done! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk4gf8ACgkQgItw+93Q 3WUj0AgAuZW8z9kXYs1yucKlk74x9nDStfmId+31819y5LnID5H/oKWP8zsk4v+j IVevIdKU7sEoRCW+04/anucpz4WwxeeNlwYhTKWGwM7Q+6zDO7nhsJL1gkDZuSeg 66BESHbwOhOxVtVDB2JcX8Tfm66+aF0qCd0gHF+5IYuj+s2TukHnASO9hb19do23 1nUU0pmGs/wO9KASGnMsfgSiw8GrJ72dOdUHG48/+ex2Ej32ZsokrzKNtXu9XgVe 7ylSsFAV3afucN42vSGRVAMkwJNCD6O53n8j0nhxRvT9pUPXrqNWETa63hZ1hka/ qV5Pk7+r3HHIOJsg1bmdxu2GD5CkOg== =Z47J -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 7 15:56:33 2017 Return-Path: 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 C92161270A7 for ; Wed, 7 Jun 2017 15:56:31 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 L0t39FyhrrlM for ; Wed, 7 Jun 2017 15:56:29 -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 EA55E120454 for ; Wed, 7 Jun 2017 15:56:28 -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 D2A6E58C4EC; Thu, 8 Jun 2017 00:56:24 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B2A44B0C1D5; Thu, 8 Jun 2017 00:56:24 +0200 (CEST) Date: Thu, 8 Jun 2017 00:56:24 +0200 From: Toerless Eckert To: Michael Richardson Cc: Anima WG , Brian E Carpenter Message-ID: <20170607225624.GF20021@faui40p.informatik.uni-erlangen.de> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <15560.1496872540@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15560.1496872540@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 22:56:32 -0000 Thanks, Michael - inline. On Wed, Jun 07, 2017 at 05:55:40PM -0400, Michael Richardson wrote: > > EXEC SUMM: SONN was extra plumbing with no clear benefits and significant > downsides for the security analysis of the entire system. > The document is fine as it is. > > Toerless Eckert wrote: > > I was surprised to see SONN go away. I do not understand what was considered to be > > underspecified about it. Everything about that text was IMHO "OK". Now i was > > not a big fan of the text, but if you do not want to bring it back then IMHO > > we would need some other equivalent explanation. > > > Just as a reminder: The use-case for SONN is the ACP: > > > - you discover a candidate ACP neighbor with DULL > > - You build a TLS connection to that candidate ACP neighbor > > - You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg: IPsec > > with/without GRE, or dTLS or IP over CoAP or what the heck. > > 1) I object to negotiating the use of which negotiation protocol to use. > It's just asking for complicated state machines with very hard to analyze > bid-down attacks at multiple layers. So, in some near term future, ANI/ACP is so successfully that we have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and 802.1ae Question: How would you negotiate between two ANI peers which protocol to use ? Lets say that the negotiation was also somewhat complex in so far that devices may have two levels of performance support for a particular protocol "i suck, but i do it to be compatible (software)" "i do it with hardware acceleration" So the negotiation would have to be done in a way that both sides will agree on the protocol they both support und suck the least with. The answer that the current ACP spec has to do this is incomplete but AFAIK still the most simple one: a) We need a security association before we negotiate so the negotiation does not become an attack vector. Solution: We build a a TLS connection b) We need a negotiation protocol. Well. GRASP proposes we use it for this purpose. So we just run GRASP (no IP etc.) inside the TLS. Its incomplee because we have not defined the exact name of objective/ parameters for this type of negotiation though. ACP spec also specifies how to select a protocol without this degree of negotiatio, which is that you start the subset of all the possible protocols that you support, and once you have working connections you use a simple decider to select which of the two peers takes the master role and closes the unneeded connections. Thats the only solution to avoid the additional layer of negotiation, but it is of course limited, because it will not allow to negotiate any parameter not known via the existing (negotiation) protocols. Such as the aforementioned performance of any of the possible protocols. Aka: Without the GRASP/TLS negotiation i could not figure out that in one case both sides have best performance via eg: 802.1ae. > 2) We have no meaningful specification for IP over *TLS thing. > (but that, I mean a deployed protocol with an RFC and widespread > implementation.) The negotiation is just GRASP inside TLS. No IP needed. > (We aren't here to invent protocols, but rather to put them together) See above, i think it's not relevant to this discus. > 3) I have been trying to understand the MACsec KMP, as some would like to run > the ACP over MACsec. I originally was led to believe that there was no > KMP, but after finding the full specifications, it's clear that there is > support for PSK and other things and even IDevID are mentioned. > I'd still like to suggest that we negotiate the use of MACsec (or of some > yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard, and > if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2 minimal > implementation can be very small; lwig has some good advice, but it > assumes initiator only, and we need both. > > I can not see a purpose for SONN, and I do not think we can do a proper > security analysis, and it forces TLS to be MTI. SONN will therefore add > a significant (3-5 pages) of text on how to use TLS properly. Would be great if you could point me to some example RFC where something like this ("how to use TLS appropriately") is done! I have sent a question to the same end to the SEC ADs. Its fine with me not to have SONN defined in the GRASP document even though i did like the text. Instead i would have to add more text to the ACP spec explaining how to use GRASP across TLS to achieve above described negotiation. And as you said: finding the minimum necessary definition of a TLS profile would then be up to me. If we make progress with the rest of ACP faster than with this piece, then i will yank that section of GRASP negotiated ACP channel selection from ACP draft and we can put it into a separate document. > I believe that this will confuse the market, and slow implementations > significantly (both the writing of, and the performance of). Sure. Hope the above strategy of pushing this up in the doc stack (GRASP -> ACP -> separate document) as needed makes sense. Cheers Toerless > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > -- --- tte@cs.fau.de From nobody Wed Jun 7 16:10:30 2017 Return-Path: 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 AF2621293E9 for ; Wed, 7 Jun 2017 16:10:28 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 j-ht14OZ7GqF for ; Wed, 7 Jun 2017 16:10:25 -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 443C9126D45 for ; Wed, 7 Jun 2017 16:10:25 -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 73CB558C4EC; Thu, 8 Jun 2017 01:10:21 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 52061B0C209; Thu, 8 Jun 2017 01:10:21 +0200 (CEST) Date: Thu, 8 Jun 2017 01:10:21 +0200 From: Toerless Eckert To: Michael Richardson Cc: anima , Toerless Eckert , pthubert@cisco.com Message-ID: <20170607231021.GG20021@faui40p.informatik.uni-erlangen.de> References: <20170607000240.GA23319@faui40p.informatik.uni-erlangen.de> <21494.1496874105@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21494.1496874105@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] draft-ietf-anima-autonomic-control-plane-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 23:10:29 -0000 Thanks, Michael. Inline. On Wed, Jun 07, 2017 at 06:21:45PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > I may be wrong, but it looks to me as if MichaelRs comments and reference to > > this new draft about RPL IPinIP header stuff makes it sound as if we MUST > > somehow support these IPinIP headers in ACP: > > It's an argument that we have to have in the ACP document. > Yes, we can get away without the RPI header. I'm not happy about it, but I > can live with it. I'd like to be tolerant of including them, however. > RFC2460bis text lets us clearly state this, and the useofrplinfo revised > document will, I think make it clearly ignorable. > > > Also, during the last IETF, i think MichaelR said something to the extend that > > the "profile" defined for RPL via the latest -06 version should rather go into > > some form of RPL profile draft.... But if i remember correctly, Pascal told me > > there is no such "RPPL profile" draft format. > > Not at all. The RPL profile template is at: > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ > (yes, it's expired, never to be published) > > https://datatracker.ietf.org/doc/rfc7733/ (section 4) > https://datatracker.ietf.org/doc/rfc8036/ (section 7) > > are examples of the RPL profile. Great. I thought in Chicago you said you would volunteer converting the current section about Roll profile in ACP spec into that format. Is that offer still valid ? > > This is something i would prefer as the mandatory minimum ACP requirements > > because i am fearful of asking all type of equipment to support RPL routing > > protocol specific IPinIP header processing. I am not even sure if i could > > today expect to get this IPinIP header processing in all linux that i > > might > > At present RPI is not supported in current Linux kernels, but there are > people working on it. RPI headers are produced by OpenWSN and Contiki > implementations now. > > > Not using IPinIP headers does of course come at the limitation of - if i > > understand it correctly - a single instance with a single (active) root. > > As long as we can have automatic root election so that we have root redundancy, > > i think this is a sufficient minimum functionality for ACP. > > There is always one root per instance, RPI lets you have multiple instances. > RPI provides for loop detection (and the resulting: fast repair) which I think > that we actually rather need if we expect this to be used for critical function. I hope i am restating Pascals argument correctly that the RPI based repair is only needed when you do want to be lazy on DAO state maintenance. Given how our profile asks for aggressive starte maintenance, tht should be sufficient (as it is on any other routing protocols). > If we aren't going to depend RPI, we'll need to carefully tweak the RPL > parameters so that we get frequent enough announcements. We may be able to > leverage the IPsec DPD messages to detect link down's and do reparent events > though. That should be easily written up in the ACP document. Good point. I guess thats details that would go beyond RPL profile. Text suggestions welcome, otherwise i'll try to make up something. > > - It seems to be easy to make IPinIP support SHOULD for endpoints. Such an > > endpoint could only use the default instance/root of RPL. Right ? > > Yes. > > > - It is less clear to me if/how its possible to introduce partial support > > for IPinIP on transit nodes. I am hping that RPL can automatically > > figure out that additional instances/dodags can only work across paths > > where all transit nodes support IPinIP. Then the problem is solved. > > If this si something RPL can not singnal, then it seems as if a > > transit node without IPinIP support would kill non-default instance/transit > > paths. > > We have to do this globally, I think, we will need to define a signal for > this, and we have to put this into the DIO. I think this will be generally > useful for RPL. Probably it deserves a seperate draft, but let's start it > in the ACP document first. Like with the GRASP discuss in the last email, i would like to see that we keep the option of pushing out difficult, longer-term stuff stuff into separate drafts to finally close on some ANI Minimum-to-implement option. Btw: I am very interested to have some more high-available ACP option, but that would be even more work, eg: Something like MRT support with RPL. Maybe we can discuss in Prague.. > > - I am very interested to make non IPinIP capable transit nodes sufficient > > for MUST ACP requirements because i am quite sure that a relevant part of > > HW accelerated forwarding engines will not support IPinIP routing, so any > > mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO > > would make me ask to rethink the choice of ACP default routing > > protocol. > > I agree. > Note that the worst situation of IPinIP is that the header has to be added > and removed at each hop, and the outer IP is a link-local address. Inside > the IPsec tunnel, it probably looks like: > > IPll ESP RPI IP ULP > > With the IPll ESP RPI part being added/removed at each hop. Based upon 20 > years of building drivers for hardware acceleration, I don't think that this > will matter much to HW accel. Well... If i look at the routing requirements that i see: - ability to have different NOCs are separate roots - ability to have MRTs I think i could easier resolve those requirements with (S/M,D) based forwarding entries than with IPinIP header fields to specify an instance. But i guess that such approaches would be novel for RPL and (see above) therefore require more work. > > Q1: Do we agree on this direction ? > > > Q2: How can we finalize the sufficient/necessary text mods to ACP to express > > this ? (profile definition etc..) > > We need to convene an ACP design team call. > > I don't think that we can get to that until the voucher and brski and grasp > documents are into WGLC. Sure. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Wed Jun 7 16:45:51 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41713148B; Wed, 7 Jun 2017 16:45:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149687914861.25640.11433787093634115213@ietfa.amsl.com> Date: Wed, 07 Jun 2017 16:45:48 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 23:45:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Voucher Profile for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-03.txt Pages : 18 Date : 2017-06-07 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has been signed using a PKCS#7 structure. The voucher artifact is generated by the pledge's manufacture or delegate (i.e. the MASA). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-03 https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 7 16:49:44 2017 Return-Path: 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 1F779129439 for ; Wed, 7 Jun 2017 16:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 JhqueqBG5deZ for ; Wed, 7 Jun 2017 16:49:41 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0105.outbound.protection.outlook.com [104.47.40.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A441A128CD5 for ; Wed, 7 Jun 2017 16:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QFiSB0nCsAoO6Lznzy4FkNrvyAacg8fvPUWW5dboxYo=; b=eTXR7Ld5f4qfp+jLJvHYgo/KnBAPc7sfGtoEsdKVkQ5Sym67ZdxB+YowM7JfCpD+YSSMb9Qt65oyK1Tvdux4oCvggRvGij9zLC16xN3+WgNyMZpgm0Rw8Zhnpdxym7cBq0XkLu7b6BD0F53tCrwHC1hE7a0InXIruEjropUTT/8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1604.namprd05.prod.outlook.com (10.161.217.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Wed, 7 Jun 2017 23:49:40 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1157.010; Wed, 7 Jun 2017 23:49:40 +0000 From: Kent Watsen To: "anima@ietf.org" CC: Benoit Claise Thread-Topic: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt Thread-Index: AQHS3+gzGqbknn56gEG7+ZquT237Z6IZzpWA Date: Wed, 7 Jun 2017 23:49:40 +0000 Message-ID: <0B3BBFCC-FAB6-4BC4-A2ED-7AE178647067@juniper.net> References: <149687914861.25640.11433787093634115213@ietfa.amsl.com> In-Reply-To: <149687914861.25640.11433787093634115213@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1604; 7:GGgItxIsEV0mAxb3uLVhhCXf/MEPHO9Tm95V4GeJEV1QECzfRhArfCFcKMbWyoEg2iy/MpLOKjDu2Ggc0BVLvz1BK8P1oKRa9yy2XQgeWdaCoAb3JSua24bh3iNYNHp1J1qTIDSe8VRaQBEYL7pT/Lv0thircPBCHz0rT7iks2CSH4+2aBkZLHV/XgPMLHb5yr/5t/8I0k5pOMrk6+6VanyZN0j8qbpIIodJ6SlAxuGQmlZfCouPf1jf7DB7WYmsbNs7LVx6TPgaRwINhmQx4zb3KeLL+7F+Qa7JI+g/IEPrQUDeRLb9brK8bjLEDZK1KyzcL3b6oUX15yfogomYIw== x-ms-traffictypediagnostic: BN3PR0501MB1604: x-ms-office365-filtering-correlation-id: 90c727c8-c91a-4367-9856-08d4adffdd12 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1604; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1604; x-forefront-prvs: 03319F6FEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39410400002)(39840400002)(39400400002)(39450400003)(377424004)(1730700003)(6306002)(4326008)(99286003)(5640700003)(66066001)(50986999)(54356999)(76176999)(4001350100001)(2950100002)(81166006)(8676002)(25786009)(33656002)(53936002)(189998001)(6512007)(6246003)(38730400002)(6916009)(86362001)(110136004)(82746002)(966005)(7736002)(478600001)(2906002)(122556002)(36756003)(305945005)(2900100001)(5660300001)(83506001)(229853002)(14454004)(2351001)(77096006)(6486002)(6506006)(2501003)(230783001)(6436002)(102836003)(6116002)(3846002)(3280700002)(83716003)(3660700001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1604; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2017 23:49:40.1830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1604 Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 23:49:44 -0000 WytiZW5vaXQsIGZvciB5YW5nLXZhbGlkYXRpb24gZXJyb3IgaXNzdWVdDQoNClBlciBNaWNoYWVs J3Mgbm9kLCBJIGp1c3QgcG9zdGVkIC0wMyB0aGF0IHNob3VsZCBhZGRyZXNzIFNoZW5nJ3MgcmV2 aWV3IGZyb20gYSBjb3VwbGUgd2Vla3MgYmFjayAoc29ycnkgaXQgdG9vayBzbyBsb25nKS4NCg0K U2hlbmcsIHRoZXJlIGlzIHN0aWxsIGEgeWFuZy12YWxpZGF0aW9uIGVycm9yIGR1cmluZyB0aGUg c3VibWlzc2lvbiBwcm9jZXNzLCBidXQgaXQgaXMgZHVlIHRvIGEgYnVnIGluIHRoZSB5YW5nIHZh bGlkYXRpb24gdG9vbHMgc2F5aW5nIHRoYXQgaXQgY2FuJ3QgZmluZCB0aGUgImlldGYtcmVzdGNv bmYiIG1vZHVsZSB3aGVuIGl0J3MgcmlnaHQgdGhlcmUgaW4gUkZDIDgwNDAuICBDQy1pbmcgQmVu b2l0IHRvIHNlZSBpZiBoZSBjYW4gaGVscCBmaXggdGhpcy4NCg0KVGhhbmtzLA0KS2VudA0KDQot LQ0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBBdXRvbm9taWMgTmV0d29ya2luZyBJbnRlZ3JhdGVkIE1vZGVsIGFuZCBBcHByb2FjaCBv ZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBWb3VjaGVyIFByb2ZpbGUg Zm9yIEJvb3RzdHJhcHBpbmcgUHJvdG9jb2xzDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEtl bnQgV2F0c2VuDQogICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgQy4gUmljaGFyZHNv bg0KICAgICAgICAgICAgICAgICAgICAgICAgICBNYXggUHJpdGlraW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgVG9lcmxlc3MgRWNrZXJ0DQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1hbmltYS12b3VjaGVyLTAzLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDE4DQoJRGF0ZSAgICAg ICAgICAgIDogMjAxNy0wNi0wNw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhIHN0cmF0ZWd5IHRvIHNlY3VyZWx5IGFzc2lnbiBhIHBsZWRnZSB0byBhbg0KICAgb3duZXIs IHVzaW5nIGFuIGFydGlmYWN0IHNpZ25lZCwgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSwgYnkgdGhl DQogICBwbGVkZ2UncyBtYW51ZmFjdHVyZXIuICBUaGlzIGFydGlmYWN0IGlzIGtub3duIGFzIGEg InZvdWNoZXIiLg0KDQogICBUaGUgdm91Y2hlciBhcnRpZmFjdCBpcyBhIFlBTkctZGVmaW5lZCBK U09OIGRvY3VtZW50IHRoYXQgaGFzIGJlZW4NCiAgIHNpZ25lZCB1c2luZyBhIFBLQ1MjNyBzdHJ1 Y3R1cmUuICBUaGUgdm91Y2hlciBhcnRpZmFjdCBpcyBnZW5lcmF0ZWQNCiAgIGJ5IHRoZSBwbGVk Z2UncyBtYW51ZmFjdHVyZSBvciBkZWxlZ2F0ZSAoaS5lLiB0aGUgTUFTQSkuDQoNCiAgIFRoaXMg ZG9jdW1lbnQgb25seSBkZWZpbmVzIHRoZSB2b3VjaGVyIGFydGlmYWN0LCBsZWF2aW5nIGl0IHRv IG90aGVyDQogICBkb2N1bWVudHMgdG8gZGVzY3JpYmUgc3BlY2lhbGl6ZWQgcHJvdG9jb2xzIGZv ciBhY2Nlc3NpbmcgaXQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWFuaW1hLXZvdWNoZXIvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2 YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFuaW1h LXZvdWNoZXItMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1hbmltYS12b3VjaGVyLTAzDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWFuaW1hLXZvdWNoZXItMDMNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0 DQpBbmltYUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h bmltYQ0KDQoNCg== From nobody Wed Jun 7 19:21:34 2017 Return-Path: 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 69BF7128B8D for ; Wed, 7 Jun 2017 19:21:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 APv7lYvVf6Kr for ; Wed, 7 Jun 2017 19:21:30 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 8F775126B71 for ; Wed, 7 Jun 2017 19:21:30 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id l89so11770844pfi.2 for ; Wed, 07 Jun 2017 19:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=L3Tsx+/vhFxn22Lvv2SLYT7Ybf2tB9A0aljW3W+9P5M=; b=dFgWAby+qDBXwsjUEK+BFhW36ZDuQBxAANp63jE71E/5iX+mOIiZXAkpmyfw1kyIDt obPvEkw2vGBiutSc9Rcgb5V20+nB+dPfaePxh9oQzAd3Tep4+1+bMjhxNdj1Pd8/U6DC rQCTV2YAWzaavemD2HIaj+XtG1sHRNk5aawQ0g9SCuO/jK89BwaTr/q7cwK08sBiDr+o IYmT7hh9hqYWM76YN6GubI5sJD/IHFQraIZtswYFvbizA+3KUuS6tfQjTiRXdlXpaQbI n5tVSXXLXXinHcAGOmIXvTKvszgUFeXrJsWGpGNseFFSAs9ePN3TTiEcRdvWf59bqbu5 bQsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=L3Tsx+/vhFxn22Lvv2SLYT7Ybf2tB9A0aljW3W+9P5M=; b=PEp2euaqI8rVVh8hytPJ6PvHFGBhiloh7mbElkbQaIE7tA0/a3JWs0kuIdI1v3NgJu al7MCBNfMRytdq2kAuzzuMWTG0P8yctX/V7mhqSEcxkgFptUk9a0c8GvvEu1ZL/RfHe4 nKc0WkFAmtIrzPjOJd/27FBWMB7LjM8ffeGOS5At8STgslTs1vYBIoYZymEhv/SomIEZ IIpn84IC9pMfGc+d8QIdZdyXYnMDJMpZnVzl2x4sYza2BrArJT7fBu2RC5BvBfuxJoeE wcPwEsEUPoIKBH0J5Ejewsri0Tv6d0ioba81Of5JdUVV1f1QB+JnWhRBR9PwM+QFcqxY gwFw== X-Gm-Message-State: AODbwcBLX4FOjqcxtlLLCC8sxHvzPQlrCb9V0IP1qPZz9hpIMXGKu1uB 4ZxYryJWQDCA5bZU X-Received: by 10.98.58.83 with SMTP id h80mr34327131pfa.50.1496888489753; Wed, 07 Jun 2017 19:21:29 -0700 (PDT) Received: from [192.168.178.21] (44.219.69.111.dynamic.snap.net.nz. [111.69.219.44]) by smtp.gmail.com with ESMTPSA id k192sm5432123pgc.31.2017.06.07.19.21.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 19:21:28 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> Date: Thu, 8 Jun 2017 14:21:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:21:33 -0000 Mainly agreed, but see in line.. On 08/06/2017 08:55, Toerless Eckert wrote: > On Wed, Jun 07, 2017 at 12:38:42PM +1200, Brian E Carpenter wrote: >> EKR didn't like the loose mention of TLS. It would be perfectly >> fine to revive SONN in the ACP draft or even in a separate >> ACP 'profile' draft. But I had the impression that IPSec was >> the preferred model for ACP. In either case you will have exactly >> the same discussion with EKR, and he's probably right ;-). In other >> words you have to fully describe how cert/key management works. >> > > Ack. see PM with Eric. I think we can have all that text in ACP. > >> I think DULL is more fundamental to GRASP. > > Yes. > >> and it doesn't contain any undefined mechanism. > > Well... i disagree (SONN didn't have this either), but not worth arguing. > >> A reminder: assuming GRASP is approved by the IESG, it will >> block at the RFC Editor until the ACP is also approved. So I >> think it makes sense to focus all the security details in the >> ACP draft, to minimise loops between the documents. > > Well... I would love if the GRASP RFC would make it obvious that > GRASP could proliferate into as many environments as its beneficial. > > To me this means that GRASP should say that it can run on any > secure transport and that ACP is just an example thereof. Maybe > specify the requirements of the secure transport. But ACP should not > need to be a normative reference. > > Now i don't know if you even want to have this argument with the IESG... > Right now thhe text does tie GRAASP very tightly to the ACP. > > Would IP have to be a normative reference for a new transport protocol built today ? > > [lots of ignored proposed text deleted] > >> I think your text and the existing text intend to say the same thing. >> But do you really want to go back to the IESG with a completely new >> text? Can we wait and see what the DISCUSSing ADs think about the >> changes so far? > > I can only make sugestions, you decide. > >>> So... IMHO, it would be great if we had some clear terminology, eg: >>> >>> GRASP domain: a connected graph of nodes. Each node in the graph is a (normal) >>> instance of GRASP running on a different (virtual) device. >> >> I have always ducked this because I understood that discussing domains >> and domain boundaries was future work for Anima. But logically, >> that makes sense. > > I think this is today quite simple. I also think that one can not really explain > what a "secure transport is without having the term of a GRASP domain: > > The secure transport needs to provide authentication (and optionally encryption) > for unicast packets between any GRASP peers in the GRASP domain. > It must prohibit traffic between any GRASP peers in the GRASP domain and > nodes outside the GRASP domain. > > ACP can provide secure transport for a GRASP domain that extends across > a complete ACP because it offers these security functions. > >>> GRASP neighbors: grasp nodes to which an instance has an edge in the graph >>> GRASP peers: all nodes (GRASP instances) in the graph >>> >>> Instances of GRASP expect that they can unicast send/receive packets to all peers. >>> GRASP does not need to know the addresses of neighbors because it addresses >>> neighbors via link-local multicast (M_DISCOVERY and M_FLOOD). >>> >>> The section 2.5.2 about constrained instances : >>> >>> With my proposed text qove IMHO you would not need any additional text for the >>> non-ACP case. >> >> I'd need to read the whole thing to be sure of that. >> >>> I also do no not understand where outside of DULL you would need the consideration >>> of not doing Rapid Mode. >> >> Can we assume secure multicast except inside the ACP? >> I don't think so. > > Multicast is a red herring. The fact that we use link-local-scope multicast > is to make life easier for GRASP, but when using the ACP you would not even > need it, because you do know upfront the IPv6 link-local unicast addresses > of your GRASP peers. Instead of sending link-local multicast you could therefore > also send link-local unicast. Well yes, but for discovery & flooding you actually need to emulate multicast. GRASP assumes that the ACP VRF will do that. If not, GRASP would have to access the adjacency table and send N copies. I could code that, but I don't think I should need to. > Consider a non-ACP solution for GRASP: You just rely on the autonomic domain > certificate. You use DULL to on all interfaces to discover your GRASP neighbors. > You set up persistent TLS connections to your GRASP neighbors. You set up > dynamic TLS connections to your (remote) GRASP peers. Aka: Same thing as when > using ACP except that you replace TCP with TLS. Well yes. Wouldn't you rather sub-contract all that to the ACP? I would. > Consider physcial security based secure transport (which the IETF crypto mafia would > of course argue is totally unacceptable): The physcial infrastructure is secured, > eg: Data Center internal network. Any links outside the physcial secure domain have > filters for GRASP link-local multicast. Maybe even filters for some GRASP specific > TCP port to be even more secure. Again, you run DULL for GRASP neighbor discovery. You > build GRASP TCP to all neighbors, you build dynamic TCP to all GRASP peers. > > Its not really rocket science. Well, it's just an ACP by another name. We aren't disagreeing. However, relying on physical integrity of the network might work for an enterprise IT manager, but that is a bit out of the IETF's scope. > Aka: the non-DULL "multicast is always inside whatever you define to be your > secure transport. Yes. Brian > > Cheers > Toerless > >>> On Tue, Jun 06, 2017 at 10:22:20AM +1200, Brian E Carpenter wrote: >>>> This version includes a second round of responses to IESG comments. >>>> >>>> We may not be done yet, but please check the diffs. Here are the main changes: >>>> >>>> Removed all mention of TLS, including SONN, since it was under- >>>> specified. >>>> >>>> Clarified other text about trust and security model. >>>> >>>> Banned Rapid Mode when multicast is insecure. >>>> >>>> Explained use of M_INVALID to support extensibility >>>> >>>> Corrected details on discovery cache TTL and discovery timeout. >>>> >>>> Improved description of multicast UDP w.r.t. RFC8085. >>>> >>>> Clarified when transport connections are opened or closed. >>>> >>>> Noted that IPPROTO values come from the Protocol Numbers registry >>>> >>>> Protocol change: Added protocol and port numbers to URI locator. >>>> >>>> Removed inaccurate text about routing protocols >>>> >>>> Moved Requirements section to an Appendix. >>>> >>>> Other editorial and technical clarifications. >>>> >>>> Regards >>>> Brian >>>> >>>> On 06/06/2017 08:57, internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. >>>>> >>>>> Title : A Generic Autonomic Signaling Protocol (GRASP) >>>>> Authors : Carsten Bormann >>>>> Brian Carpenter >>>>> Bing Liu >>>>> Filename : draft-ietf-anima-grasp-13.txt >>>>> Pages : 79 >>>>> Date : 2017-06-05 >>>>> >>>>> Abstract: >>>>> This document specifies the GeneRic Autonomic Signaling Protocol >>>>> (GRASP), which enables autonomic nodes and autonomic service agents >>>>> to dynamically discover peers, to synchronize state with each other, >>>>> and to negotiate parameter settings with each other. GRASP depends >>>>> on an external security environment that is described elsewhere. The >>>>> technical objectives and parameters for specific application >>>>> scenarios are to be described in separate documents. Appendices >>>>> briefly discuss requirements for the protocol and existing protocols >>>>> with comparable features. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ >>>>> >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-anima-grasp-13 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13 >>>>> >>>>> >>>>> 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. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Jun 7 19:36:14 2017 Return-Path: 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 63F7A129420 for ; Wed, 7 Jun 2017 19:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 a1nH4xsIOfZX for ; Wed, 7 Jun 2017 19:36:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CAC1200F1 for ; Wed, 7 Jun 2017 19:36:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70F15E1A1; Wed, 7 Jun 2017 22:36:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A59146380F; Wed, 7 Jun 2017 22:36:09 -0400 (EDT) From: Michael Richardson To: Anima WG cc: Toerless Eckert , Brian E Carpenter In-Reply-To: <20170607225624.GF20021@faui40p.informatik.uni-erlangen.de> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <15560.1496872540@obiwan.sandelman.ca> <20170607225624.GF20021@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:36:13 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > So, in some near term future, ANI/ACP is so successfully that we > have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and > 802.1ae That's only three, btw. And the answer is that you'd use IKEv2 to negotiate which one of them to use, because IKEv2 was designed *SPECIFICALLY* to do this kind of thing. > a) We need a security association before we negotiate so the negotiation does > not become an attack vector. Solution: We build a a TLS connection You just assumed TLS. If you can assume TLS, I can assume IKEv2, and save a lot more code, and pages less And you have to assume TLS 1.3 (so you need new code and new libraries on every device). The process will still be suspectible to trivial TCP RST attacks. So please add some security for that part too! >> 2) We have no meaningful specification for IP over *TLS thing. >> (but that, I mean a deployed protocol with an RFC and widespread >> implementation.) > The negotiation is just GRASP inside TLS. No IP needed. I'm talking about the "dTLS" option above you just named. What is it? "IP in DTLS" isn't anywhere near enough. Why not add OpenVPN to the list too? At least it has widely used, extensively tested reference code, even if it has no public specification. Some developer in Mumbai will still have no idea what that means. Is there an IXIA or SPIRENT module so that I can test it at 10G? or 100G? That's a serious objection: you can't just make stuff up like that. >> 3) I have been trying to understand the MACsec KMP, as some would like to run >> the ACP over MACsec. I originally was led to believe that there was no >> KMP, but after finding the full specifications, it's clear that there is >> support for PSK and other things and even IDevID are mentioned. >> I'd still like to suggest that we negotiate the use of MACsec (or of some >> yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard, and >> if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2 minimal >> implementation can be very small; lwig has some good advice, but it >> assumes initiator only, and we need both. >> >> I can not see a purpose for SONN, and I do not think we can do a proper >> security analysis, and it forces TLS to be MTI. SONN will therefore add >> a significant (3-5 pages) of text on how to use TLS properly. > Would be great if you could point me to some example RFC where something like > this ("how to use TLS appropriately") is done! I think that the Opportunistic Security specification, https://tools.ietf.org/html/rfc7435 tried to do this. I'm not a TLS guy, so go ask one of them. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk4uBkACgkQgItw+93Q 3WWQLAf/b3Gcm52wuFD5jWgsRAHEpNvc5D2jXK1CkWWzP8FuInfOkViEjfEhWyN3 es+fa/OAZUhN3UHHYl/gOIgqLBmz6jhJ9AKY4OLYDCAcGzNtJYGTqp+FJt3tnpnr 1Gc8lIm1zUAwvUJAvNDoN6V7Xll0SS5IBUmKqkvo8Y5ejorO5ifiTBI9xJ/DwgWm 2EB+wYV9u75wcKbiutVtT9jt2NcLfC6X/nZd97FdPVwHJindjb6w7e9Z5x5lU2eJ 7I6f+7tx6Vd2TDQhMoBv2rc2CoF4rj9ZkmGgBvnX7671MdalqdicjQDENw79uesf 0abs4UdVnYvm6JQe1nd4fGgfbYz8Cw== =Yc6o -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 7 19:40:30 2017 Return-Path: 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 0B106129A8E for ; Wed, 7 Jun 2017 19:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 MOYlrhMwItO3 for ; Wed, 7 Jun 2017 19:40:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8667412957F for ; Wed, 7 Jun 2017 19:40:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E0FEE1A1; Wed, 7 Jun 2017 22:41:10 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D1FBA6380F; Wed, 7 Jun 2017 22:40:20 -0400 (EDT) From: Michael Richardson To: anima cc: Toerless Eckert , pthubert@cisco.com In-Reply-To: <20170607231021.GG20021@faui40p.informatik.uni-erlangen.de> References: <20170607000240.GA23319@faui40p.informatik.uni-erlangen.de> <21494.1496874105@obiwan.sandelman.ca> <20170607231021.GG20021@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] draft-ietf-anima-autonomic-control-plane-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 02:40:28 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: >> Not at all. The RPL profile template is at: >> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ >> (yes, it's expired, never to be published) >> >> https://datatracker.ietf.org/doc/rfc7733/ (section 4) >> https://datatracker.ietf.org/doc/rfc8036/ (section 7) >> >> are examples of the RPL profile. > Great. I thought in Chicago you said you would volunteer converting the current section > about Roll profile in ACP spec into that format. Is that offer still > valid ? Yes, I'll still do that, but there are some other BRSKI edits that seem to take priority :-) >> If we aren't going to depend RPI, we'll need to carefully tweak the RPL >> parameters so that we get frequent enough announcements. We may be able to >> leverage the IPsec DPD messages to detect link down's and do reparent events >> though. That should be easily written up in the ACP document. > Good point. I guess thats details that would go beyond RPL profile. > Text suggestions welcome, otherwise i'll try to make up something. That's actually exactly what the RPL Profile addresses. > Btw: I am very interested to have some more high-available ACP option, but > that would be even more work, eg: Something like MRT support with RPL. > Maybe we can discuss in Prague.. What is "MRT" in this context? >> the IPsec tunnel, it probably looks like: >> >> IPll ESP RPI IP ULP >> >> With the IPll ESP RPI part being added/removed at each hop. Based upon 20 >> years of building drivers for hardware acceleration, I don't think that this >> will matter much to HW accel. > Well... If i look at the routing requirements that i see: > - ability to have different NOCs are separate roots > - ability to have MRTs > I think i could easier resolve those requirements with (S/M,D) based > forwarding entries than with IPinIP header fields to specify an instance. > But i guess that such approaches would be novel for RPL and (see above) > therefore require more work. Different NOCs could create different DODAGs, yes, but it requires InstanceIDs. There may be some other options. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk4uRQACgkQgItw+93Q 3WVYkggAlO4v9SidvuM+XLtQSuFmHZFtJV6lgodG5QaNC08XKF8xDTtI2SdCn5ol Vg+gYWE+yyL18+S9WwN0T5CFYrh3Seou3/5EZFyPY1oiyBXn5hTFsQIE75sreBOw hlsyZMYII0x/9kpl1o37k+zMJjotDVwyELl8ISSbict0jTggrs4k+FG7io2062NV 212Opjiokyk/x2NfJJ2R5SgPZgW334JlLz+L6XiK5ZQLWce1YZ5vL5R4V9ki97lZ 1+IEDEmarObHXcV2pG9QfjqIyFftoeTqeGiv3H4ftxfcsL6kfL3OItiCpafKvXTz IZJXkdNFRLIooEsDfOaZcYjMwQMy3w== =taVq -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 8 02:19:18 2017 Return-Path: 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 AD6C5129C73 for ; Thu, 8 Jun 2017 02:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 eDN69rR5stP8 for ; Thu, 8 Jun 2017 02:19:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A913129B7A for ; Thu, 8 Jun 2017 02:19:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIC86771; Thu, 08 Jun 2017 09:19:13 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 8 Jun 2017 10:19:11 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 8 Jun 2017 17:19:08 +0800 From: "Liubing (Leo)" To: "Roberta Maglione (robmgl)" , "anima@ietf.org" Thread-Topic: [Anima] RPL alternatives in ACP? Thread-Index: AQHS32/QIeRiasoAA0KDMBX/JFMH2qIYzKwAgAHI8+A= Date: Thu, 8 Jun 2017 09:19:07 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F488F5@nkgeml514-mbx.china.huawei.com> References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59391691.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9474b64c3d6a54abca8c4ee2d2946f5c Archived-At: Subject: Re: [Anima] RPL alternatives in ACP? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 09:19:18 -0000 Hi Roberta, Thanks for your comments. Inline. > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Roberta > Maglione (robmgl) > Sent: Wednesday, June 07, 2017 8:23 PM > To: anima@ietf.org > Subject: Re: [Anima] RPL alternatives in ACP? >=20 > Hello Bing, > I'm not sure I fully understand and agree with what you are trying to say= with > this sentence: >=20 > > But in some closed solutions, multi-vendor interoperation is not the No= .1 > consideration for customers. >=20 > If you think that multi-vendor interoperability is not needed what's the = point > of making a standard? Why discussing it here? You could make your own > choice for protocol without asking for WG opinion/consensus. My thought (maybe wrong) is that it's about perception of the user/customer= s: is a non-RPL ACP still be "the ACP"? In other words, when using some other IGPs that some old-fashion developers= /customers are more familiar with and have more confidence, and it could be= still identified as standard ACP, maybe it's good for the adoption of this= technology? Especially when users don't care about multi-vendor interopera= bility in some scenarios. But to be clarified, I do like RPL from technical aspect. The above thought= is kind of compromise to peoples' perception when promoting a new technolo= gy. Best regards, Bing > Roberta >=20 >=20 > On 07/06/2017 06:04, Liubing (Leo) wrote: > > Hi ACP co-authors, > > > > (Maybe you missed my last mail "Regarding ACP routing protocol", let > > me re-post it with a clearer title and CC to you.) > > > > When I discuss ACP with some product people, they are always curious > about why we choosed RPL for routing. > > I understand the benefits of RPL in ACP, it is lightweight and much mor= e > scalable in a single routing area, but most of the non-IoT network device= s > seem lacking the support of RPL. > > > > So, please pardon my iteration on this problem, can we possibly make > another traditional IGP literally legal in the ACP document? (e.g. > ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols > would potentially cause interoperation issues. But in some closed solutio= ns, > multi-vendor interoperation is not the No.1 consideration for customers. = If > ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more > widely adopted in non-IoT network scenarios. > > > > Any comments/eggs? :) > > > > B.R. > > Bing > > > >> -----Original Message----- > >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing > >> (Leo) > >> Sent: Tuesday, May 23, 2017 5:53 PM > >> To: Anima WG > >> Subject: [Anima] Regarding ACP routing protocol > >> > >> Hi all, > >> > >> When I discuss ACP with some product people, they are always curious > >> about why we choose RPL for routing. > >> I understand the benefits of RPL in ACP, it is lightweight and much > >> more scalable in a single routing area, but most of the non-IoT > >> network devices seem like lack the support of RPL. > >> > >> So, please pardon my iteration on this problem, can we possibly make > >> another more traditional IGP literally legal in the ACP document? (e.g= . > >> ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple > >> protocols would potentially cause interoperation issue. But in some > >> closed solutions, multi-vendor interoperation is not the No.1 > >> consideration for customers. If ACP allows ISIS-autoconf or > >> OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT > network devices. > >> > >> Any comments? Or eggs :) > >> > >> B.R. > >> Bing > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Jun 8 08:59:44 2017 Return-Path: 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 7FD02129479 for ; Thu, 8 Jun 2017 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 70jBpaAuCmvi for ; Thu, 8 Jun 2017 08:59:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B960129473 for ; Thu, 8 Jun 2017 08:59:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 91BFBE263 for ; Thu, 8 Jun 2017 12:00:23 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D1F7F636BB for ; Thu, 8 Jun 2017 11:59:31 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:59:38 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Well yes, but for discovery & flooding you actually need to emulate > multicast. GRASP assumes that the ACP VRF will do that. If not, GRASP > would have to access the adjacency table and send N copies. I could > code that, but I don't think I should need to. GRASP is doing application layer multicast. That's why we have those session-IDs, and the checking and the caching, etc. It's news to me that the ACP will emulate layer-2 multicast! I expected GRASP to send a copy on each interface (you do that now!), and the ACP will present each link in the VRF as an interface. If you want multicast support in the ACP, would you like: 1) PIM? (dense or sparse) 2) MPL? 3) something totally bleeding edge (but very cool) like BIER? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk5dGMACgkQgItw+93Q 3WVBWAgAuni9EkjWsePgUW7wEmxje8Sr1/95DmVrXTMA8q8rv9gerOLsOlCEU/z2 /c7DGarvDJCNqWTqhBLleKvcNo+OFElncpFtUwFfSN+fJGLR9P5to6CM2BxUoTE+ FWwOJUsCamY9Neu8baxfwvS1z6n4aLc1S5s7VnLFchrXKJqLFF5zzoEzWWgKA62F 676R/cucShvtDSDYXZKbWZZtuoAnd6xVcjsDnECmz8vW0tcNh4CsWWlj57RNY5LT NEW6kbH6F5bDYukhromKt5k8/LVwcQ99wPot9IcEteP/GmE/yG1c1cixmvug5SKH H92wCSTUnQj92s0vH/Y/shqAmLlTEg== =zh8E -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 8 11:25:33 2017 Return-Path: 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 56705129464 for ; Thu, 8 Jun 2017 11:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 rhIbgcAeDmYk for ; Thu, 8 Jun 2017 11:25:28 -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 4B65C12025C for ; Thu, 8 Jun 2017 11:25:28 -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 3403C58C4B0; Thu, 8 Jun 2017 20:25:24 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1F00AB0C22D; Thu, 8 Jun 2017 20:25:23 +0200 (CEST) Date: Thu, 8 Jun 2017 20:25:23 +0200 From: Toerless Eckert To: Michael Richardson Cc: Anima WG , Brian E Carpenter Message-ID: <20170608182523.GH20021@faui40p.informatik.uni-erlangen.de> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <15560.1496872540@obiwan.sandelman.ca> <20170607225624.GF20021@faui40p.informatik.uni-erlangen.de> <16530.1496889369@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16530.1496889369@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 18:25:31 -0000 Thanks, Michael: Any examples of how IKEv2 is used to negotiate other non-IPsec protocols ? [ I have not found examples describing the use of IKE(v2) for dissimilar crypto associations outside of IPsec, except for maybe RFC4595. If i wanted for example to negotiate between 802.1ae or IPsec, i wonder what amount of trouble/work that would be to define that as an IKEv2 extension vs. defining this just as a GRASP negotiation in TLS. ] Yes, we just made up TLS, and yes, if we can't come to a conclusion that IKEv2 is not the most feasible approach (see above for my concerns), TLS may potentially also not be the most widely accepted transport given the constrained IoT worlds preference to use CoAP/dTLS if i am not mistaken. In any case this discussion seems to point to need to take the more intelligent negotiation out of the ACP document into a separate draft where we can continue to ponder and decide on the best option. Right ? Eg: Maybe a "lightweight heterogenous security association negotiation mechanism" would have to be GRASP/CoAP/dTLS. and the negotiation functions should defintely be able to argue how they did inherit or differ from IKEv2. In the end this may simple be a more strategic modularization direction, to reuse evolving building blocks eg: IKEv2 was built as a silo when there where no widely adopted initial security association protocols like TLS/dTLS. And the message formats used in IKEv2 where predating evolving industry preferences over a reuse of request/response exchange standards such as those of HTTP/CoAP/(hopefully GRASP) or encoding rules such as those of XML or JSON/CBOR. If using IKEv2 to negotiate into eg: 802.1ae would be easier and make adoption easier, i'd be all for it. Past experience just makes me think this to be less likely. Wrt to IP in dTLS: This would of course only be a candidate ACP channel. For negotiation we would not need IP, it would just be GRASP/(d)TLS or GRASP/CoAP/dTLS. We had the argument in Chigaco or before whether it would be necessary to have a 1 paragraph separate document to state that IP packets can be carried in dTLS, and i thought we did in the meeting come to the conclusion that that was not necessary. But that may have been premature. I was looking at: draft-mavrogiannopoulos-openconnect-00. That certainly is mostly complexity because it combines TLS for connection negotiation and dTLS for the data. Gee, i wonder why they didn't use IKEv2 ;-)) Nevertheless: Would be interesting to find the most simple RFC example of an application protocol that just uses dTLS to have an example of what dTLS parameters one would need to specify. (i assume OpenVPN is just an implementation of openconnect mechanism, right ?, i have not used it myself but just linux openconnect and Cisco Anyconnect) Btw: Eric recommended to take a look at https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-09 as a recent example how to specify security profiles for (d)TLS. Cheers toerless On Wed, Jun 07, 2017 at 10:36:09PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > So, in some near term future, ANI/ACP is so successfully that we > > have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and > > 802.1ae > > That's only three, btw. > And the answer is that you'd use IKEv2 to negotiate which one of them to use, > because IKEv2 was designed *SPECIFICALLY* to do this kind of thing. > > > a) We need a security association before we negotiate so the negotiation does > > not become an attack vector. Solution: We build a a TLS connection > > You just assumed TLS. > If you can assume TLS, I can assume IKEv2, and save a lot more code, and > pages less > > And you have to assume TLS 1.3 (so you need new code and new libraries on > every device). The process will still be suspectible to trivial TCP RST > attacks. So please add some security for that part too! > > > >> 2) We have no meaningful specification for IP over *TLS thing. > >> (but that, I mean a deployed protocol with an RFC and widespread > >> implementation.) > > > The negotiation is just GRASP inside TLS. No IP needed. > > I'm talking about the "dTLS" option above you just named. > What is it? "IP in DTLS" isn't anywhere near enough. > Why not add OpenVPN to the list too? > At least it has widely used, extensively tested reference code, even if it > has no public specification. > > Some developer in Mumbai will still have no idea what that means. > Is there an IXIA or SPIRENT module so that I can test it at 10G? or 100G? > That's a serious objection: you can't just make stuff up like that. > > >> 3) I have been trying to understand the MACsec KMP, as some would like to run > >> the ACP over MACsec. I originally was led to believe that there was no > >> KMP, but after finding the full specifications, it's clear that there is > >> support for PSK and other things and even IDevID are mentioned. > >> I'd still like to suggest that we negotiate the use of MACsec (or of some > >> yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard, and > >> if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2 minimal > >> implementation can be very small; lwig has some good advice, but it > >> assumes initiator only, and we need both. > >> > >> I can not see a purpose for SONN, and I do not think we can do a proper > >> security analysis, and it forces TLS to be MTI. SONN will therefore add > >> a significant (3-5 pages) of text on how to use TLS properly. > > > Would be great if you could point me to some example RFC where something like > > this ("how to use TLS appropriately") is done! > > I think that the Opportunistic Security specification, https://tools.ietf.org/html/rfc7435 > tried to do this. I'm not a TLS guy, so go ask one of them. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > From nobody Thu Jun 8 13:03:41 2017 Return-Path: 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 DB7BC12778E for ; Thu, 8 Jun 2017 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 kDERENSOadlF for ; Thu, 8 Jun 2017 13:03:37 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 03B371242F5 for ; Thu, 8 Jun 2017 13:03:36 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v58K3V3I005385; Thu, 8 Jun 2017 16:03:31 -0400 To: anima@ietf.org, Toerless Eckert , Michael Richardson References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <15560.1496872540@obiwan.sandelman.ca> <20170607225624.GF20021@faui40p.informatik.uni-erlangen.de> <16530.1496889369@obiwan.sandelman.ca> <20170608182523.GH20021@faui40p.informatik.uni-erlangen.de> From: William Atwood Organization: Concordia University, Montreal Message-ID: <278e5e7f-5b09-f886-2fcb-25cd597c6ca6@concordia.ca> Date: Thu, 8 Jun 2017 16:03:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170608182523.GH20021@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-06-08 16:03:31 EDT Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 20:03:40 -0000 Toerless, The idea to extend IKEv2 for "wider scope" negotiation can certainly be seen in the KARP documents. In this case: 1) for unicast negotiation, the protocols being keyed include IPsec and TCP-AO 2) for multicast negotiation, the base model was GDOI (adapted to IKEv2), but an election procedure was added The addition is because GDOI's administratively-assigned group controller/key server was not suitable for a negotiation whose scope was a single network segment. KARP needed something that would work on its own. Sounds as if "autonomic" would be a good descriptor for this case... Unfortunately, these two documents never made it past the "draft-author" stage. However, they were well-enough defined that I have a student who has formally validated some of their security properties. documents (all four that I believe are pertinent): draft-mahesh-karp-rkmp draft-hartman-karp-mrkmp draft-yeung-g-ikev2 draft-chunduri-karp-using-ikev2-with-tcp-ao Bill On 08/06/2017 2:25 PM, Toerless Eckert wrote: > Thanks, Michael: > > Any examples of how IKEv2 is used to negotiate other non-IPsec protocols ? > > [ I have not found examples describing the use of IKE(v2) for dissimilar > crypto associations outside of IPsec, except for maybe RFC4595. If i > wanted for example to negotiate between 802.1ae or IPsec, i wonder what > amount of trouble/work that would be to define that as an IKEv2 extension > vs. defining this just as a GRASP negotiation in TLS. ] > > Yes, we just made up TLS, and yes, if we can't come to a conclusion that > IKEv2 is not the most feasible approach (see above for my concerns), > TLS may potentially also not be the most widely accepted transport given the > constrained IoT worlds preference to use CoAP/dTLS if i am not mistaken. > > In any case this discussion seems to point to need to take the more intelligent > negotiation out of the ACP document into a separate draft where we can continue to > ponder and decide on the best option. Right ? > > Eg: Maybe a "lightweight heterogenous security association negotiation mechanism" > would have to be GRASP/CoAP/dTLS. and the negotiation functions should > defintely be able to argue how they did inherit or differ from IKEv2. > > In the end this may simple be a more strategic modularization direction, > to reuse evolving building blocks eg: IKEv2 was built as a silo when there > where no widely adopted initial security association protocols like TLS/dTLS. > And the message formats used in IKEv2 where predating evolving industry > preferences over a reuse of request/response exchange standards such as those > of HTTP/CoAP/(hopefully GRASP) or encoding rules such as those of XML or JSON/CBOR. > > If using IKEv2 to negotiate into eg: 802.1ae would be easier and make > adoption easier, i'd be all for it. Past experience just makes me think this > to be less likely. > > Wrt to IP in dTLS: > > This would of course only be a candidate ACP channel. For negotiation we would not > need IP, it would just be GRASP/(d)TLS or GRASP/CoAP/dTLS. > > We had the argument in Chigaco or before whether it would be necessary to have a > 1 paragraph separate document to state that IP packets can be carried in dTLS, > and i thought we did in the meeting come to the conclusion that that was not > necessary. But that may have been premature. I was looking at: > draft-mavrogiannopoulos-openconnect-00. That certainly is mostly complexity > because it combines TLS for connection negotiation and dTLS for the data. > Gee, i wonder why they didn't use IKEv2 ;-)) > > Nevertheless: Would be interesting to find the most simple RFC example of > an application protocol that just uses dTLS to have an example of what dTLS > parameters one would need to specify. > > (i assume OpenVPN is just an implementation of openconnect mechanism, right ?, > i have not used it myself but just linux openconnect and Cisco Anyconnect) > > Btw: Eric recommended to take a look at https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-09 as a recent example how to specify security profiles for (d)TLS. > > Cheers > toerless > > On Wed, Jun 07, 2017 at 10:36:09PM -0400, Michael Richardson wrote: >> >> Toerless Eckert wrote: >> > So, in some near term future, ANI/ACP is so successfully that we >> > have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and >> > 802.1ae >> >> That's only three, btw. >> And the answer is that you'd use IKEv2 to negotiate which one of them to use, >> because IKEv2 was designed *SPECIFICALLY* to do this kind of thing. >> >> > a) We need a security association before we negotiate so the negotiation does >> > not become an attack vector. Solution: We build a a TLS connection >> >> You just assumed TLS. >> If you can assume TLS, I can assume IKEv2, and save a lot more code, and >> pages less >> >> And you have to assume TLS 1.3 (so you need new code and new libraries on >> every device). The process will still be suspectible to trivial TCP RST >> attacks. So please add some security for that part too! >> >> >> >> 2) We have no meaningful specification for IP over *TLS thing. >> >> (but that, I mean a deployed protocol with an RFC and widespread >> >> implementation.) >> >> > The negotiation is just GRASP inside TLS. No IP needed. >> >> I'm talking about the "dTLS" option above you just named. >> What is it? "IP in DTLS" isn't anywhere near enough. >> Why not add OpenVPN to the list too? >> At least it has widely used, extensively tested reference code, even if it >> has no public specification. >> >> Some developer in Mumbai will still have no idea what that means. >> Is there an IXIA or SPIRENT module so that I can test it at 10G? or 100G? >> That's a serious objection: you can't just make stuff up like that. >> >> >> 3) I have been trying to understand the MACsec KMP, as some would like to run >> >> the ACP over MACsec. I originally was led to believe that there was no >> >> KMP, but after finding the full specifications, it's clear that there is >> >> support for PSK and other things and even IDevID are mentioned. >> >> I'd still like to suggest that we negotiate the use of MACsec (or of some >> >> yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all hard, and >> >> if IKEv2 is the MTI, then we need it implemented anyway. An IKEv2 minimal >> >> implementation can be very small; lwig has some good advice, but it >> >> assumes initiator only, and we need both. >> >> >> >> I can not see a purpose for SONN, and I do not think we can do a proper >> >> security analysis, and it forces TLS to be MTI. SONN will therefore add >> >> a significant (3-5 pages) of text on how to use TLS properly. >> >> > Would be great if you could point me to some example RFC where something like >> > this ("how to use TLS appropriately") is done! >> >> I think that the Opportunistic Security specification, https://tools.ietf.org/html/rfc7435 >> tried to do this. I'm not a TLS guy, so go ask one of them. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Thu Jun 8 14:10:08 2017 Return-Path: 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 021DC126DCA for ; Thu, 8 Jun 2017 14:10:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 asL5FilM5eZn for ; Thu, 8 Jun 2017 14:10:06 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 2A50B1205F0 for ; Thu, 8 Jun 2017 14:10:06 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 9so21165059pfj.1 for ; Thu, 08 Jun 2017 14:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=APX/nUso18Ki73X/Si1M0mSUo7Y4g2Dtth/W5UKzx50=; b=Ip8KvGuCUlLr4mjDv7qVzkHCuvm92C3/2KQ7+pWka4gWrvpK+0GkhWePyvIlZ2/h2f oETYGnMmGqTO494g7W8H7/5Sq4oAv+cRvfADmVkRfuabxxJekG4gtsUKwx34kujwQrp8 WeNGtKMb19SvEdaG6Qtw/r/dp++LQa5fxztmQ+qd376NsWwxbBpDEf4D0dsRIGjUiH/t vRvyEi2j+qdnXToR/VHm0+GIrtRsvZKxQ+Z6gZCLur07J+mJgGkd9JNRZKob+YguOB3I j/nk9K9u9KgXfSzUNDrYkj719f+MzDxuXGwnzqnm8Co8T8MZlHui01xYuhycKnGOv6G5 c2UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=APX/nUso18Ki73X/Si1M0mSUo7Y4g2Dtth/W5UKzx50=; b=CNOEdwvTOHxY/lXdGhQoxWfxWc4XXIU/0j4vPndJPd1eRjuWcuLw/VzQKh+LIbUB0J 0+GzOuvI110Lq1HnO478DrpwGC54h3OT++D77c27qPcW0h6nuF02voYS5PORKiFXAciy 7Us7isIepX5gP7HpaXEztu4BVo+LI/YG6MzCw0dgvsJ57cBUSZEF3+3P+E/843W7kylO ckzu76lQ2x89eONNalONtneBKqlfWKktR9BUVXP8RdtlCtgSsDQT+mbZTlEXkHzlbSQ+ XDlxzz7/zLMCSSTk9S3SFbWTqKAI5rK1fYYcSy2ZjjTsw7Lfa/i1b0aaSxSq9t5OBacR QXig== X-Gm-Message-State: AODbwcBpD4vy0szjtI39vZurTCY4QOLXDkspUE8RjVNIraCYrZq+ZeAP hA+yWGEydAo0e9W8 X-Received: by 10.84.224.74 with SMTP id a10mr37564841plt.173.1496956205180; Thu, 08 Jun 2017 14:10:05 -0700 (PDT) Received: from ?IPv6:2406:e001:38e2:1:28cc:dc4c:9703:6781? ([2406:e001:38e2:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i2sm10211956pfe.89.2017.06.08.14.10.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 14:10:04 -0700 (PDT) To: Michael Richardson , Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 9 Jun 2017 09:10:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3434.1496937571@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 21:10:08 -0000 On 09/06/2017 03:59, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Well yes, but for discovery & flooding you actually need to emulate > > multicast. GRASP assumes that the ACP VRF will do that. If not, GRASP > > would have to access the adjacency table and send N copies. I could > > code that, but I don't think I should need to. > > GRASP is doing application layer multicast. That's why we have those > session-IDs, and the checking and the caching, etc. Wel, I think the session IDs are equally relevant for unicast, especially if we do develop a UDP-unicast model later. But the model described in GRASP relies explicitly on link-local IP multicast, that's why we have a LL multicast address assigned. We do not rely on multicast routing, because that makes us dependent on the data plane. But we do rely on discovery and flood being sent to all neighbours. How else can they work? So this is why I've been asking the ACP authors to be precise about the service they will offer to GRASP, over many months. They tell me it will be a VRF instance providing a reasonably small number of (virtual) interfaces to GRASP. GRASP will send LL multicasts to each of those interfaces, and the VRF instance has to do the right thing, i.e. replicate those multicasts as needed. But that's layer 3, it just has LL scope. Nothing new here that I can see. Brian > > It's news to me that the ACP will emulate layer-2 multicast! > > I expected GRASP to send a copy on each interface (you do that now!), and the > ACP will present each link in the VRF as an interface. > > If you want multicast support in the ACP, would you like: > 1) PIM? (dense or sparse) > 2) MPL? > 3) something totally bleeding edge (but very cool) like BIER? > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Jun 9 00:46:29 2017 Return-Path: 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 AEC44129454 for ; Fri, 9 Jun 2017 00:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 mvmwVHSh5_Sw for ; Fri, 9 Jun 2017 00:46:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AB1127444 for ; Fri, 9 Jun 2017 00:46:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIE43986; Fri, 09 Jun 2017 07:46:24 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 9 Jun 2017 08:46:23 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 9 Jun 2017 15:46:18 +0800 From: Sheng Jiang To: Kent Watsen , "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt Thread-Index: AQHS3+g9Mgtxgs3X5kWSUchOl5OFu6IZi4gAgAKbvrA= Date: Fri, 9 Jun 2017 07:46:16 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDC077C@NKGEML515-MBX.china.huawei.com> References: <149687914861.25640.11433787093634115213@ietfa.amsl.com> <0B3BBFCC-FAB6-4BC4-A2ED-7AE178647067@juniper.net> In-Reply-To: <0B3BBFCC-FAB6-4BC4-A2ED-7AE178647067@juniper.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.593A5251.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 28be21a85cfeffc38e86d8eebe7c4faf Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 07:46:29 -0000 Kent, Thanks for taking care my review comments. The chairs will launch the WGLC = soon. Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Thursday, June 08, 2017 7:50 AM > To: anima@ietf.org > Cc: Benoit Claise > Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt >=20 > [+benoit, for yang-validation error issue] >=20 > Per Michael's nod, I just posted -03 that should address Sheng's review f= rom a > couple weeks back (sorry it took so long). >=20 > Sheng, there is still a yang-validation error during the submission proce= ss, but it > is due to a bug in the yang validation tools saying that it can't find th= e > "ietf-restconf" module when it's right there in RFC 8040. CC-ing Benoit = to see > if he can help fix this. >=20 > Thanks, > Kent >=20 > -- >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Autonomic Networking Integrated Model an= d > Approach of the IETF. >=20 > Title : Voucher Profile for Bootstrapping Protocols > Authors : Kent Watsen > Michael C. Richardson > Max Pritikin > Toerless Eckert > Filename : draft-ietf-anima-voucher-03.txt > Pages : 18 > Date : 2017-06-07 >=20 > Abstract: > This document defines a strategy to securely assign a pledge to an > owner, using an artifact signed, directly or indirectly, by the > pledge's manufacturer. This artifact is known as a "voucher". >=20 > The voucher artifact is a YANG-defined JSON document that has been > signed using a PKCS#7 structure. The voucher artifact is generated > by the pledge's manufacture or delegate (i.e. the MASA). >=20 > This document only defines the voucher artifact, leaving it to other > documents to describe specialized protocols for accessing it. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-voucher-03 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-anima-voucher-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Jun 9 00:52:23 2017 Return-Path: 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 42C4D129526; Fri, 9 Jun 2017 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Dqf-piOXm7jS; Fri, 9 Jun 2017 00:52:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E88C127444; Fri, 9 Jun 2017 00:52:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIE44883; Fri, 09 Jun 2017 07:52:10 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 9 Jun 2017 08:52:10 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 9 Jun 2017 15:52:05 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 Thread-Index: AdLg9TuO0F/blLQWSGq9Y55AfK7T0A== Date: Fri, 9 Jun 2017 07:52:04 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDC079F@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CDC079FNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.593A53AA.02A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 72d9ad0a846c6e44ee75c60ca78b3639 Archived-At: Subject: [Anima] WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 07:52:15 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CDC079FNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This message starts the two-week ANIMA Working Group Last Call to advance d= raft-ietf-anima-voucher-03, Voucher Profile for Bootstrapping Protocols. Th= is document's intended status is Standards Track. At present, there is no I= PR file against this document. Please send your comments by June 23, 2017. If you do not feel this docume= nt should advance, please state your reasons why. Sheng JIANG is the assigned shepherd. Regards, Sheng & Toerless --_000_5D36713D8A4E7348A7E10DF7437A4B927CDC079FNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi all,
 
This message st=
arts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima=
-voucher-03, Voucher Profile for Bootstrapping Protocols. This document's i=
ntended status is Standards Track. At present, there is no IPR file against=
 this document.
 
Please send you=
r comments by June 23, 2017. If you do not feel this  document should =
advance, please state your reasons why.
 
Sheng JIANG is =
the assigned shepherd.
 
Regards,
 
Sheng & Toe=
rless

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CDC079FNKGEML515MBXchi_-- From nobody Fri Jun 9 07:48:22 2017 Return-Path: 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 2320F129B72 for ; Fri, 9 Jun 2017 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Z1Qsv6TUpzcq for ; Fri, 9 Jun 2017 07:48:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257DB129B71 for ; Fri, 9 Jun 2017 07:48:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FAC7200A5; Fri, 9 Jun 2017 10:49:11 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 83FDB636BB; Fri, 9 Jun 2017 10:48:16 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 14:48:20 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > So this is why I've been asking the ACP authors to be precise about the > service they will offer to GRASP, over many months. They tell me it > will be a VRF instance providing a reasonably small number of (virtual) > interfaces to GRASP. GRASP will send LL multicasts to each of those > interfaces, and the VRF instance has to do the right thing, i.e. replicate > those multicasts as needed. But that's layer 3, it just has LL scope. > Nothing new here that I can see. Since all the links will be PPP links, there will be no "replication". -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk6tTAACgkQgItw+93Q 3WXhxAf/cY7Kdi6Eotcdc1g6Dq5Eh75FDY+uTur0DcbNr+TsXEVCtcCNGV1+uGop UF/nXJbzpf8xyI8sXSScc77jV8prwAwS2aL2JytLrlDkziCHt6hfV9eUI5BonqIb dySWPNVcyg0G9KrABgjwgEiwCgp4UDORrntsjFvJ+3tqFbohonHUfm/MZPW7zdEt 6mH/04g2X7SecUO+ti+QKkxN91fq+8MeJAihiQkz/bdu+qaNnBkkMRB/mfidJ8v9 Ghvavxgh82Ld/2hD5YkCd9S9qieSPt5JPH9nFfZil40Fl2xgmuTvI054iYuO2oSf pvAymrYGYgT6GIYnODOyYUlIKHWiyA== =hUfs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 9 10:58:53 2017 Return-Path: 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 46EEC12708C for ; Fri, 9 Jun 2017 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 mQVmMfBBOTq9 for ; Fri, 9 Jun 2017 10:58:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0744C1267BB for ; Fri, 9 Jun 2017 10:58:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIF27950; Fri, 09 Jun 2017 17:58:43 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 9 Jun 2017 18:58:42 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.56]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Fri, 9 Jun 2017 10:58:33 -0700 From: Uma Chunduri To: William Atwood , "anima@ietf.org" , Toerless Eckert , Michael Richardson Thread-Topic: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN Thread-Index: AQHS3xwbVfg4udml4EeRuqp+C3FTHaIaaLsAgAAQ+ACAAD1mgIABCTaAgAAbbACAAPeskA== Date: Fri, 9 Jun 2017 17:58:33 +0000 Message-ID: <25B4902B1192E84696414485F5726854018BEED6@SJCEML701-CHM.china.huawei.com> References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <15560.1496872540@obiwan.sandelman.ca> <20170607225624.GF20021@faui40p.informatik.uni-erlangen.de> <16530.1496889369@obiwan.sandelman.ca> <20170608182523.GH20021@faui40p.informatik.uni-erlangen.de> <278e5e7f-5b09-f886-2fcb-25cd597c6ca6@concordia.ca> In-Reply-To: <278e5e7f-5b09-f886-2fcb-25cd597c6ca6@concordia.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.593AE1D4.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5205cdecc632df224577a0683e014ad9 Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 17:58:52 -0000 Agree with Bill below. As a co-author of the pair-wise key drafts https://www.ietf.org/archive/id= /draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt & https://tools.ietf.or= g/html/draft-mahesh-karp-rkmp-05 or=20 adaptation of IKEv2 for TCP-AO, I can say there was lot of effort done in K= ARP for this.=20 However, eventually KARP WG decided routing protocols don't need automated= key exchange protocol for both pair-wise or for group-keying (out of KARP = charter) and the effort was not progressed. I am not fully clear on the exact requirements current context (*) but can = answer any specific questions around usage of IKEv2 other than IPSec. -- Uma C. * I don't closely follow all Anima WG posts, Sorry! -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of William Atwood Sent: Thursday, June 08, 2017 1:04 PM To: anima@ietf.org; Toerless Eckert ; Michael Richardson Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN Toerless, The idea to extend IKEv2 for "wider scope" negotiation can certainly be see= n in the KARP documents. In this case: 1) for unicast negotiation, the protocols being keyed include IPsec and TCP= -AO 2) for multicast negotiation, the base model was GDOI (adapted to IKEv2), b= ut an election procedure was added The addition is because GDOI's administratively-assigned group controller/k= ey server was not suitable for a negotiation whose scope was a single netwo= rk segment. KARP needed something that would work on its own. Sounds as i= f "autonomic" would be a good descriptor for this case... Unfortunately, these two documents never made it past the "draft-author" stage. However, they were well-enough defined that I have a student who ha= s formally validated some of their security properties. documents (all four that I believe are pertinent): draft-mahesh-karp-rkmp draft-hartman-karp-mrkmp draft-yeung-g-ikev2 draft-chunduri-karp-using-ikev2-with-tcp-ao Bill On 08/06/2017 2:25 PM, Toerless Eckert wrote: > Thanks, Michael: >=20 > Any examples of how IKEv2 is used to negotiate other non-IPsec protocols = ? >=20 > [ I have not found examples describing the use of IKE(v2) for dissimilar > crypto associations outside of IPsec, except for maybe RFC4595. If i > wanted for example to negotiate between 802.1ae or IPsec, i wonder what > amount of trouble/work that would be to define that as an IKEv2 extensi= on > vs. defining this just as a GRASP negotiation in TLS. ] >=20 > Yes, we just made up TLS, and yes, if we can't come to a conclusion=20 > that > IKEv2 is not the most feasible approach (see above for my concerns),=20 > TLS may potentially also not be the most widely accepted transport=20 > given the constrained IoT worlds preference to use CoAP/dTLS if i am not = mistaken. >=20 > In any case this discussion seems to point to need to take the more=20 > intelligent negotiation out of the ACP document into a separate draft=20 > where we can continue to ponder and decide on the best option. Right ? >=20 > Eg: Maybe a "lightweight heterogenous security association negotiation me= chanism" > would have to be GRASP/CoAP/dTLS. and the negotiation functions should=20 > defintely be able to argue how they did inherit or differ from IKEv2. >=20 > In the end this may simple be a more strategic modularization=20 > direction, to reuse evolving building blocks eg: IKEv2 was built as a=20 > silo when there where no widely adopted initial security association prot= ocols like TLS/dTLS. > And the message formats used in IKEv2 where predating evolving=20 > industry preferences over a reuse of request/response exchange=20 > standards such as those of HTTP/CoAP/(hopefully GRASP) or encoding rules = such as those of XML or JSON/CBOR. >=20 > If using IKEv2 to negotiate into eg: 802.1ae would be easier and make=20 > adoption easier, i'd be all for it. Past experience just makes me=20 > think this to be less likely. >=20 > Wrt to IP in dTLS: >=20 > This would of course only be a candidate ACP channel. For negotiation=20 > we would not need IP, it would just be GRASP/(d)TLS or GRASP/CoAP/dTLS. >=20 > We had the argument in Chigaco or before whether it would be necessary=20 > to have a > 1 paragraph separate document to state that IP packets can be carried=20 > in dTLS, and i thought we did in the meeting come to the conclusion=20 > that that was not necessary. But that may have been premature. I was look= ing at: > draft-mavrogiannopoulos-openconnect-00. That certainly is mostly=20 > complexity because it combines TLS for connection negotiation and dTLS fo= r the data. > Gee, i wonder why they didn't use IKEv2 ;-)) >=20 > Nevertheless: Would be interesting to find the most simple RFC example=20 > of an application protocol that just uses dTLS to have an example of=20 > what dTLS parameters one would need to specify. >=20 > (i assume OpenVPN is just an implementation of openconnect mechanism,=20 > right ?, i have not used it myself but just linux openconnect and=20 > Cisco Anyconnect) >=20 > Btw: Eric recommended to take a look at https://tools.ietf.org/html/draft= -ietf-dprive-dtls-and-tls-profiles-09 as a recent example how to specify se= curity profiles for (d)TLS. >=20 > Cheers > toerless >=20 > On Wed, Jun 07, 2017 at 10:36:09PM -0400, Michael Richardson wrote: >> >> Toerless Eckert wrote: >> > So, in some near term future, ANI/ACP is so successfully that we >> > have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS a= nd >> > 802.1ae >> >> That's only three, btw. >> And the answer is that you'd use IKEv2 to negotiate which one of them=20 >> to use, because IKEv2 was designed *SPECIFICALLY* to do this kind of thi= ng. >> >> > a) We need a security association before we negotiate so the negot= iation does >> > not become an attack vector. Solution: We build a a TLS=20 >> connection >> >> You just assumed TLS. >> If you can assume TLS, I can assume IKEv2, and save a lot more code,=20 >> and pages less >> >> And you have to assume TLS 1.3 (so you need new code and new=20 >> libraries on every device). The process will still be suspectible to=20 >> trivial TCP RST attacks. So please add some security for that part too! >> >> >> >> 2) We have no meaningful specification for IP over *TLS thing. >> >> (but that, I mean a deployed protocol with an RFC and widespread >> >> implementation.) >> >> > The negotiation is just GRASP inside TLS. No IP needed. >> >> I'm talking about the "dTLS" option above you just named. >> What is it? "IP in DTLS" isn't anywhere near enough. >> Why not add OpenVPN to the list too? >> At least it has widely used, extensively tested reference code, even=20 >> if it has no public specification. >> >> Some developer in Mumbai will still have no idea what that means. >> Is there an IXIA or SPIRENT module so that I can test it at 10G? or 100G= ? >> That's a serious objection: you can't just make stuff up like that. >> >> >> 3) I have been trying to understand the MACsec KMP, as some would= like to run >> >> the ACP over MACsec. I originally was led to believe that ther= e was no >> >> KMP, but after finding the full specifications, it's clear that t= here is >> >> support for PSK and other things and even IDevID are mentioned. >> >> I'd still like to suggest that we negotiate the use of MACsec (or= of some >> >> yet-to-be-well-defined IP over TLS) via IKEv2. It's not at all h= ard, and >> >> if IKEv2 is the MTI, then we need it implemented anyway. An IKEv= 2 minimal >> >> implementation can be very small; lwig has some good advice, but = it >> >> assumes initiator only, and we need both. >> >> >> >> I can not see a purpose for SONN, and I do not think we can do a = proper >> >> security analysis, and it forces TLS to be MTI. SONN will theref= ore add >> >> a significant (3-5 pages) of text on how to use TLS properly. >> >> > Would be great if you could point me to some example RFC where som= ething like >> > this ("how to use TLS appropriately") is done! >> >> I think that the Opportunistic Security specification,=20 >> https://tools.ietf.org/html/rfc7435 >> tried to do this. I'm not a TLS guy, so go ask one of them. >> >> -- >> Michael Richardson , Sandelman Software Works =20 >> -=3D IPv6 IoT consulting =3D- >> >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 --=20 Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Fri Jun 9 13:43:08 2017 Return-Path: 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 DA2C4129407 for ; Fri, 9 Jun 2017 13:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8b4GabKsROaX for ; Fri, 9 Jun 2017 13:43:04 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 13BCF127BA3 for ; Fri, 9 Jun 2017 13:43:04 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id f185so29895207pgc.0 for ; Fri, 09 Jun 2017 13:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WcFFsYOpxRToYjp7f9Mf0eP3Mj5JJmtNNhpcqd7rVfk=; b=Bfwg95+bVjRkyhdjdNzrYXa1yxlOPFznv/NtfEiMxLOniV71PDw4kERIynhwSTA8lT G9TSGqH8UqCyQ1hDjHSBFOy2eBx5kov5Frz+IveQhiJBDc2RAlHyJKe1lfVkhMoetc5g 6g1GJiob4DBU68n8EZSrXhcpxL5Mqj+PaLjxvJGB18t9DWTeeEX15GNwRHevYMmsOWNw TAkFbYV0/+adEUmZRIimY5VFVzndlt+HJ941sOBAo47cN17sCMdKajqChOXy2VMnBmIX 7LX+e7ic4SR6donPn11asTiprlXkRtBjr3aFVaJLsMM2nBmtCe4Z9PBXR4mbchjUbBGf YNZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=WcFFsYOpxRToYjp7f9Mf0eP3Mj5JJmtNNhpcqd7rVfk=; b=fnmOCrQnCp5hoOMH+oX0rUqGaUuY04pTyXF0uKwMPOpltYfSE1rJ1dWUJINVvFA5cn wPMpGjhL8qEynKnjo0PgyHlyrSzdj1R6xnNnKzy9Q1FaA4R/FS3kW6EXJ+erfuWxfQc+ taCRfBjejQcel38qjyFSlzzMiO7kvN/Qocl277EJEnlP3jmWvY98oWAprGL+Pd+g/IuZ 7a7ylNi5DwNRJxDBOnWj9IgXKmGMZLu45akpXKqyDHdbM5m7vrXKrp64fo9rkJ8m4RYy VIxRM6X72pnghlvzGZb7rjUFA8ZWvStIRKV6d42OUAYxw5iyUGhcQzbsaATU6Hz7xrx4 gF6A== X-Gm-Message-State: AODbwcAQOt6SHq8IRVKa78lA7G94c/heKySET6AvF4oJvGQ7Yr4/OXzF VYO3tOED0M2C0ji3 X-Received: by 10.98.218.65 with SMTP id w1mr13607973pfl.234.1497040983507; Fri, 09 Jun 2017 13:43:03 -0700 (PDT) Received: from [192.168.178.21] ([118.148.119.180]) by smtp.gmail.com with ESMTPSA id t20sm3446720pgo.29.2017.06.09.13.43.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 13:43:02 -0700 (PDT) To: Michael Richardson Cc: Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> <21716.1497019696@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <588e1953-4db1-086b-d441-2371e352ad73@gmail.com> Date: Sat, 10 Jun 2017 08:43:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <21716.1497019696@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 20:43:06 -0000 On 10/06/2017 02:48, Michael Richardson wrote: > > Brian E Carpenter wrote: > > So this is why I've been asking the ACP authors to be precise about the > > service they will offer to GRASP, over many months. They tell me it > > will be a VRF instance providing a reasonably small number of (virtual) > > interfaces to GRASP. GRASP will send LL multicasts to each of those > > interfaces, and the VRF instance has to do the right thing, i.e. replicate > > those multicasts as needed. But that's layer 3, it just has LL scope. > > > Nothing new here that I can see. > > Since all the links will be PPP links, there will be no "replication". I think that's our choice to make. Please see: https://mailarchive.ietf.org/arch/msg/anima/-vOvFVQr6zcognXJxwKKB9_t5-Q GRASP discovery and flood, by their nature, must be received by all GRASP neighbours. How it happens isn't actually very important - if there was such a thing as secure link-local multicast, we'd use it. But if not, *somebody* is going to replicate the packets. If the VRF doesn't do it, GRASP itself will have to do it. That doesn't seem optimal to me. I would like the ACP VRF to emulate link-local multicast to all nodes listed in the adjacency table as neighbours on the same physical interface. If it doesn't, then GRASP will. IMHO we need a precise statement of the service the ACP will provide at the API it presents to GRASP. That can't be left as an implementation detail. Brian From nobody Fri Jun 9 14:16:20 2017 Return-Path: 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 76FBC126BF7 for ; Fri, 9 Jun 2017 14:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rUJPxk4Do0B7 for ; Fri, 9 Jun 2017 14:16:18 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7C9120724 for ; Fri, 9 Jun 2017 14:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v59LFnLp026760; Fri, 9 Jun 2017 23:15:49 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wkw7T1mR2z3ZfM; Fri, 9 Jun 2017 23:15:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <588e1953-4db1-086b-d441-2371e352ad73@gmail.com> Date: Fri, 9 Jun 2017 23:15:48 +0200 Cc: Anima WG X-Mao-Original-Outgoing-Id: 518735748.00666-4b7b7d3eee054bd7d134152a13408107 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> <21716.1497019696@obiwan.sandelman.ca> <588e1953-4db1-086b-d441-2371e352ad73@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 21:16:19 -0000 On Jun 9, 2017, at 22:43, Brian E Carpenter = wrote: >=20 > But if not, *somebody* is going to replicate the packets. If the VRF > doesn't do it, GRASP itself will have to do it. That doesn't seem = optimal > to me. I wonder why you are saying this. Generally, where information needs to be disseminated to a group, there = is an end-to-end argument giving the application a big role in that. = Supporting this directly in the network can only really be motivated by = performance considerations(*); do you think this function here is = performance-critical? Gr=C3=BC=C3=9Fe, Carsten (*) or where the topology defines the group, but I don=E2=80=99t think = this is the case here. From nobody Fri Jun 9 16:33:30 2017 Return-Path: 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 D61A5126BF6 for ; Fri, 9 Jun 2017 16:33:28 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZcbKk9DUVpgL for ; Fri, 9 Jun 2017 16:33:27 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 481161200B9 for ; Fri, 9 Jun 2017 16:33:27 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 15so5458383pfc.1 for ; Fri, 09 Jun 2017 16:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nNYTnDW7BcEeU82dXpaF00rRCHq/2TxIO6LsWspo+08=; b=nnkRisECwyeYkVL9ATwUBfQ08tPjcLQ30Kg1tlOChq8S1P+pLxdp8+piyjD4WkPjlY iiUKzIXoYEfO0TEoL48aflP30HsDoRQSAVhN/Snl7aJav2fOsUy/P0XqvkOvmz7CPBZW 6WLn2ImTi7RzlEbdNnNNhda6fM2pp0AS+2dsuEelMqh9FRiP97X6L1OsL4Plp/XulGxY Hqj2OME1eZevisZDmeahtFKF1A0yCdxuZBqK2LqjOSp49w2hPRWsvxIeCxnJyDszk0tb yILAamSZzvX7oAwaf316nCsBbRXzubE49BFjnhpIjPzPEEF1nqYC1JLDuZEvPOfXLlX4 avuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=nNYTnDW7BcEeU82dXpaF00rRCHq/2TxIO6LsWspo+08=; b=Z6b99H5nYvPAvMUW4NnGHwtrx2XAExiOHgta/TcpnmYGNUYSX9tqJJGrSz6PPvaf67 ckQdPWEfiYBma1rHWR3eMYUlDQn+raunYbUrnbNAj547yrGOW1XxGnyH8XZPQVKjNBVP Hnr2yRfXACNGyY6iQDP7Z/a8wQEuLFCSVGbVkDaWIHorGntdlrXeVX0fotzUPRvvn57B YETmigj3yCiLtZy7U5q3101c2NR9moRS2C8lxsZjALuxQCk95XAaiys0htJaMbjLTOBg WGGVHZH9lThNxG2scXJRG6/A5aXTgUXIPxZWKwklRey9Yklc45hNtm3ro5qfKThyqYaB zcoA== X-Gm-Message-State: AODbwcB+Nc0vAgJ8YYhhW4GmUTwlpQwgoU6oSN4vnhN3w7nj3E6wNoUA n4lldHtIkH62kP2b X-Received: by 10.84.194.226 with SMTP id h89mr29153395pld.58.1497051206695; Fri, 09 Jun 2017 16:33:26 -0700 (PDT) Received: from [192.168.178.21] ([118.148.119.180]) by smtp.gmail.com with ESMTPSA id b2sm4281933pgc.16.2017.06.09.16.33.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 16:33:25 -0700 (PDT) To: Carsten Bormann Cc: Anima WG References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> <21716.1497019696@obiwan.sandelman.ca> <588e1953-4db1-086b-d441-2371e352ad73@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 10 Jun 2017 11:33:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 23:33:29 -0000 On 10/06/2017 09:15, Carsten Bormann wrote: > On Jun 9, 2017, at 22:43, Brian E Carpenter wrote: >> >> But if not, *somebody* is going to replicate the packets. If the VRF >> doesn't do it, GRASP itself will have to do it. That doesn't seem opti= mal >> to me. >=20 > I wonder why you are saying this. >=20 > Generally, where information needs to be disseminated to a group, there= is an end-to-end argument giving the application a big role in that. Su= pporting this directly in the network can only really be motivated by per= formance considerations(*); do you think this function here is performanc= e-critical? Well, we are talking about encryption here, so there is a run-time cost that we can never optimise if it's an upper layer that replicates the packets. However, my main concern is that the GRASP code will have to track each neighbour relationship as a distinct virtual interface with its own interface index, and in particular the discovery relaying code will have to track each one separately. That is stateful, because discovery responses have to be matched to the discovery request. And it goes like N(neighbours). If the VRF simply emulates multicast sending, that is a trvial stateless process, and the GRASP state goes like N(interfaces). Either will work, but as far as I can see having the VRF handle LL multicast is much, much simpler. To be clear, it doesn't have to do any multicast routing; that's why GRASP does its own relaying. The VRF has to do something like if message.destination_address =3D=3D ALL_GRASP_NEIGHBORS_6: for i in neighbors: secure_send(message, i) and then it can forget about it, because it's UDP. Brian >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) or where the topology defines the group, but I don=E2=80=99t think = this is the case here. >=20 >=20 From nobody Sun Jun 11 11:16:23 2017 Return-Path: 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 C6E03129A97 for ; Sun, 11 Jun 2017 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 BSFAIslXgZCd for ; Sun, 11 Jun 2017 11:16:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E94C129A96 for ; Sun, 11 Jun 2017 11:16:14 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id EAD1A1F922 for ; Sun, 11 Jun 2017 18:16:12 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id ADC3A227F; Sat, 10 Jun 2017 11:20:07 -0400 (EDT) From: Michael Richardson To: Anima WG In-reply-to: References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> <21716.1497019696@obiwan.sandelman.ca> <588e1953-4db1-086b-d441-2371e352ad73@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Sat, 10 Jun 2017 11:33:32 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 10 Jun 2017 11:20:07 -0400 Message-ID: <14942.1497108007@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:16:17 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > If the VRF simply emulates multicast sending, that is a trvial > stateless process, and the GRASP state goes like N(interfaces). Again, the ACP VRF is a set of PPP links over IPsec tunnels. It will show up as interfaces with seperate ifindex. (Replacing IPsec with another IP-level security mechanism won't change this) A long time ago, I asked carefully if it was intended that GRASP to be providing application layer multicast (vs supporting multicast across the ACP via PIM or MPL), and the response I got was that GRASP would do it. And GRASP do it the right thing now, so I'm really lost as to what the concern is. Putting on my ISP architect hat: In a realistic ISP situations, the occurances of having more than one or two ACP peers on a single physical link is pretty rare. The exception would be at access networks that look like ethernet. (Cable, FTTH, GPONs). xDSL networks tend to use PPPoE, so have a seperate interface per CPE device. b2b ISPs that use GPON tend to split off the customer traffic into seperate VLANs, although both they and Cable networks usually put the GPON terminals/Cable_modem management into a VLAN seperate from the customer traffic. At this point, these networks are using TR-069 for management with a transition from SOAP to NETCONF apparently on the way. So for initial deployment of ACP, I expect not to see more than 3-4 devices per link. The interface between the access devices and the core devices may initially have a higher fan-out, until one looks at the actual wires, and realizes that the layer-2 switching hardware in between ought to be involved in the ACP, and then the ACP devolves to point to point ethernet cables. Whether Metro-Ethernet rings will be presented to the ACP as a single link with many nodes (ignoring all the layer-2 topology), or whether the layer-2 topology will be revealed will, I think be a question of evolution. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZPA4nAAoJEJVM4Vb9/EKQHTYH/RZkTJsZ40hYPZHuJCyoKOBe BosntRtN5YbL4Sg4ckvgo8+wBc5Wdy8fBfbLyfDXi3EXAcg1+ZoyBXZw+nTIvn1M q42nPTMIuJVy5SwUP22aHmU0VCeQCKAd2KdY8V/S6Og+EqFs/Qce2UlyfBbwpm6a 5TVVbr+V1cw6S8tEXwLsC4P8oHaZoWqFLLDeNHpHvQI3odSFt+GLBCbwNY1cLcQ6 BXmYiNd0BmYr0QJNq//CRmjWFoZcM5bQi8axcAD59fv4ERWdrBXBuZzCfHmfJmT0 PALIl/uSxYtLa5do41NBIIdz9GRpQiW9OHCCxKGnzRqoCP+K34W35hCcVY2Ukw8= =9leA -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 11 16:43:16 2017 Return-Path: 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 5755B129ADE for ; Sun, 11 Jun 2017 16:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MdmUircJN3kJ for ; Sun, 11 Jun 2017 16:43:12 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 677EB12946A for ; Sun, 11 Jun 2017 16:43:12 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id f185so39708477pgc.0 for ; Sun, 11 Jun 2017 16:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2UGHijTuoWbNpLBb0fD27YZ4emSpOg8cQHUq1EyR3Zg=; b=MmKACAVCy0gY9oKmIZ2vdwf4G8u8JEUD9AyTDsOfsKWVPAILSb+dunLdhtiECbUCOw nz0IgSD1mNHdrZBEBO7D47/MqjFQjyxehQtfG3eMQPMDfJXqlouXYFpo9TUbJzdvUImn 4+hyQ6TEdeeeK3+VXgGCG+AtD86cP/uX0IrvnfkI6GbnWJi3gWTjEoJJPpR5gCsiRJDD 4dGRVdyHXkpzRccRGtuTusa4mN7VIjxUy5ImbxJzR+UqrQBik4vEf7/2rwHbilsFCnpR OI4NBNJgHJLfjoiFgVwUKsrzpzE/oBWneksPp9glUxhoawhbpYfanxCa9T65VqXUnqDw V3CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2UGHijTuoWbNpLBb0fD27YZ4emSpOg8cQHUq1EyR3Zg=; b=Vbw8hpJvgC+IzaQ79NaInjZMRFJIwXe0OP7KzGj/B8ciNwXgdFZMWYKztzw/iR3vzG 8Oq41+D+exI744YRnc+OOJqPovBpzOm+nEzRI17HIBO0nTRvIqTVDzR5grKsXYHSkUgM gbFwN11PgoouYNjyde+vsiY0TbMpTjVqD8AP7OF09gXVGKj7SzYj7kphP1xkd/dYlgYq PxRZ4YC4LG2V32L1kU5DZ8a1sfucnxowr+6vKKFJkkWJAwybto2iurRBu43SYmmb34n1 lHyeo5QDKqpYyfREK/NaoP5lGJPTAdSqNF0rK4HSCUASNyx7mXrHfu6ZzBm1RnqeKjUF jElA== X-Gm-Message-State: AODbwcD24y0xZTcSPkNfaez76v+MWt9A2r9HypN5RKXz02UZhAjTGeA4 mgRGavbwiwajZluY X-Received: by 10.98.8.142 with SMTP id 14mr53991287pfi.35.1497224591329; Sun, 11 Jun 2017 16:43:11 -0700 (PDT) Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id k9sm19604132pga.40.2017.06.11.16.43.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 16:43:10 -0700 (PDT) To: Michael Richardson References: <149669625424.3230.10151704455578829166@ietfa.amsl.com> <20170606232417.GJ12427@faui40p.informatik.uni-erlangen.de> <41e0a6fc-9410-4d84-cae6-74dbd3fdfa74@gmail.com> <20170607205533.GD20021@faui40p.informatik.uni-erlangen.de> <7dd77b25-2319-3999-bf4a-2274eb0728a1@gmail.com> <3434.1496937571@obiwan.sandelman.ca> <21716.1497019696@obiwan.sandelman.ca> <588e1953-4db1-086b-d441-2371e352ad73@gmail.com> <14942.1497108007@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Cc: anima@ietf.org Message-ID: Date: Mon, 12 Jun 2017 11:43:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <14942.1497108007@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 23:43:14 -0000 On 11/06/2017 03:20, Michael Richardson wrote: > > Brian E Carpenter wrote: > > If the VRF simply emulates multicast sending, that is a trvial > > stateless process, and the GRASP state goes like N(interfaces). > > Again, the ACP VRF is a set of PPP links over IPsec tunnels. > It will show up as interfaces with seperate ifindex. > (Replacing IPsec with another IP-level security mechanism won't change this) Yes, I understand that, which is why I was asking about the number of interfaces that a GRASP instance will see in the earlier thread that I referenced. I still need to see an API for the adjacency table to be certain, but I believe I understand how GRASP will use those interfaces. > A long time ago, I asked carefully if it was intended that GRASP to be > providing application layer multicast (vs supporting multicast across the ACP > via PIM or MPL), and the response I got was that GRASP would do it. Right, there is absolutely no need for a multicast routing protocol. > And GRASP do it the right thing now, so I'm really lost as to what the > concern is. Efficiency, basically. Reading on... > Putting on my ISP architect hat: > > In a realistic ISP situations, the occurances of having more than > one or two ACP peers on a single physical link is pretty rare. > The exception would be at access networks that look like ethernet. (Cable, > FTTH, GPONs). > > xDSL networks tend to use PPPoE, so have a seperate interface per CPE device. > b2b ISPs that use GPON tend to split off the customer traffic into seperate > VLANs, although both they and Cable networks usually put the GPON > terminals/Cable_modem management into a VLAN seperate from the customer > traffic. At this point, these networks are using TR-069 for management > with a transition from SOAP to NETCONF apparently on the way. > > So for initial deployment of ACP, I expect not to see more than 3-4 devices > per link. OK, let's work with that. If a node has 4 interfaces and 4 GRASP neighbours per interface, your model will have the GRASP core replicating each discovery and flood message 16 times, because it will see 16 ACP interfaces. So there will be 16 separately encrypted messages. That's not a disaster. But for discovery, there will also be 16 potential responses, all of which have to be waited for and collected up. It will work (although I wouldn't recommend coding it the way I coded the prototype, because it would also generate 16 threads). It just doesn't feel optimal. Anyway my real request, before I feel ready for an ACP WGLC, is to see at least notionally what the ACP's API will look like, including the API for the adjacency table. Thanks Brian > The interface between the access devices and the core devices may > initially have a higher fan-out, until one looks at the actual wires, and > realizes that the layer-2 switching hardware in between ought to be involved > in the ACP, and then the ACP devolves to point to point ethernet cables. > > Whether Metro-Ethernet rings will be presented to the ACP as a single link > with many nodes (ignoring all the layer-2 topology), or whether the layer-2 > topology will be revealed will, I think be a question of evolution. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Sun Jun 11 19:15:44 2017 Return-Path: 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 A25C2129B59; Sun, 11 Jun 2017 19:15:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 svn6rX2vkFtF; Sun, 11 Jun 2017 19:15:40 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 B36B2129B55; Sun, 11 Jun 2017 19:15:39 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id v18so12943023pgb.3; Sun, 11 Jun 2017 19:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FcpGC8vCJ6xqI5izwOok2AQUJxXbJxUw/tVhYlq8zVk=; b=sSzqadyoMa3+JTfTYiO4O71pboFn2n5qeNhuV6DbiUsS7ppddRpNTvWoGqJxQNmLcd 4hfF9Cyl2hPyYYW3k9zJ85PaX5j7PRd3WWtszgCF2wiYEOCKEW/l1SAtzJYrVRTVnTVa dQJC3D0RVz4LD8dVTtbXj2y1Jta/umZsDXwVE9AxTmXWdws2RrWZ2fSiwt7lGcX0K9fL CUzpPYuEnyyy0E/A5RCBA6y7KP5UlASNSOv4oPQVOdGOSCZF8ke+uThz3iQfxh6EwPFO V9B7zmtw+OcKYzNq5Wu46HRUrN2glUtUza/oanHDak9YgxU1VVtzPfQMN005iR8gnbtc tpZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FcpGC8vCJ6xqI5izwOok2AQUJxXbJxUw/tVhYlq8zVk=; b=csy14AyxJ+2HOxVwCns4EPrr7jkLNGIxEnMiT7u1LEdpUzXyImBnCDcF6yfJBrO3Ii 6zdI7b69jx02wraFh0RonjkHOshARuIVBWg3ZsVzK8r1ZHdsK1YDjwUG+LmIyY8EZs1f IPkUfVS3FZpAk7XPTazhFr46BrkMHTDcCIwzKDvkHR/Kf6VGSBZZCcSO0pb060tk5UDs mMtX7yWU/qiaiTCjhUMecbM1oya3V6jWpmlvbsu3PUn5W4MaFiHE8R55ptRUBZs7RV+b +uar2pquzlnAKpCmiCl/OKAUGDjIx9gkOy09iEE4y5d7iPmwnC75gYrRHnBEcWGErH9K PIjg== X-Gm-Message-State: AODbwcBPCJyD1q6HqNoznLSk/RKSrVDMKpm2ILhbZd6T+DipEVboVY8s /q+WbYDLQ5lBhKT3 X-Received: by 10.84.233.139 with SMTP id l11mr53653923plk.217.1497233739117; Sun, 11 Jun 2017 19:15:39 -0700 (PDT) Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id 188sm13170423pgc.49.2017.06.11.19.15.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 19:15:38 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927CDC079F@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 12 Jun 2017 14:15:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDC079F@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 02:15:42 -0000 Hi, I am no expert but this draft seems good to me. One question. If I understand correctly, the only assertions defined so far are 'verified' and 'logged'. Presumably 'verified' applies to pledges whose ID is known in advance and 'logged' applies to pledges that just show up on the network? So I assume that protocols using this voucher format must define the conditions. For example it seems to me that in an ANIMA network, we will not accept 'logged' devices, but will insist on 'verified'. If so, perhaps this statement > Pledges MUST > ensure that the assertion provided is acceptable before > processing the voucher. is not quite enough. I think we need to require that each specification of a use case for the voucher format MUST specify how pledges will decide whether the assertion is acceptable. Also, it isn't just the pledge. In an ANIMA network, surely the registrar should block any pledge that is only 'logged'? Regards Brian On 09/06/2017 19:52, Sheng Jiang wrote: > Hi all, > > > > This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-voucher-03, Voucher Profile for Bootstrapping Protocols. This document's intended status is Standards Track. At present, there is no IPR file against this document. > > > > Please send your comments by June 23, 2017. If you do not feel this document should advance, please state your reasons why. > > > > Sheng JIANG is the assigned shepherd. > > > > Regards, > > > > Sheng & Toerless > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Jun 11 20:11:11 2017 Return-Path: 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 937E31294BC; Sun, 11 Jun 2017 20:11:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ciCpEbk4TwVT; Sun, 11 Jun 2017 20:11:07 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 AC40D126DED; Sun, 11 Jun 2017 20:11:06 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id x63so46524736pff.3; Sun, 11 Jun 2017 20:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:organization:to:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TlTOpdsxKr5dDWajY6ZqL97kVwbV9yfqH9zvmlmUg8s=; b=Yxr5PNkILXFfgmCBGLchw0/xjM0qHOZ0UoC6BBtYYNu7oGaLu2BVTwR5ac2HzjsMhj DD/nzm7Y7Yuw6JJpdMur/unpqY84p5gioQMWN1rPHWuUvF+1mIGVgZDF62a5FSMXbqUl 4U/7XOvjXYluyO/UpnBll9D++sVjc0Z2zm1rjqm5R/cB/556w5ZZaZ031A8/6cal/hrN 3BEm2cWiOoZpqySdmbzbP5BuiOjqGt7TtL3c8RB/ZIxP/7ZMV1qOU+d7+OmJARd8X1It evyD+ZE/10POajtRf8VhflBpwoTSdi6r8PgoYL9V2SWnqUXMd7NkB8NRyTYaJe0JKkGD Qxmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:organization:to:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TlTOpdsxKr5dDWajY6ZqL97kVwbV9yfqH9zvmlmUg8s=; b=oj8ySaK/rPaP2XIfUK/p3I6jw5tHiiGjAihi0zWY4SbtT4OicrXnTrfzyv8g4FoHd+ EG1DcbntB67fotqb06XY1BYI2QjQfvA2D64/6haLlg8o8Rk07U/AgeMwoHgPFbddc6xb PEEL1vCev/UKxEINsItVMAvPFnSmh7SO0Zfzi+uw9a6Ph/XSSd2C+KN2KSbN5kqdCyvP Ydmyrr/hjysz24K1A+qasjmBTi4DdRd0j9P8Dtgz7DfNI8+skSL+Ax9TK5LqPtawNtsw S/hWgGPwtC4Cgc77DtB+cmdOvzrodHKEmyQW+ituxx4qAf8Cs6mYNTiypj7ImFYto5Mo oi+A== X-Gm-Message-State: AODbwcAQmMvxknwvpO2fDTjiEEMldoplVij/sAwVJbDw+mc1f6TTVRN0 gMTOPghJ4g67mMX7 X-Received: by 10.84.224.5 with SMTP id r5mr55354265plj.267.1497237066035; Sun, 11 Jun 2017 20:11:06 -0700 (PDT) Received: from [192.168.178.21] ([118.148.117.140]) by smtp.gmail.com with ESMTPSA id 62sm12862383pfz.39.2017.06.11.20.11.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 20:11:05 -0700 (PDT) References: <149566389334.8737.940293315082013190@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland To: draft-ietf-anima-bootstrapping-keyinfra@ietf.org Cc: Anima WG Message-ID: Date: Mon, 12 Jun 2017 15:11:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149566389334.8737.940293315082013190@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:11:10 -0000 Hi, About the GRASP usage in BRSKI: > 3.1.1. Proxy Discovery Protocol Details > > The proxy uses the GRASP M_FLOOD mechanism to announce itself. This > announcement is done with the same message as the ACP announcement > detailed in [I-D.ietf-anima-autonomic-control-plane]. Can we make it: This announcement SHOULD be done with the same message... That's only an optimisation, really. > > proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, > transport-proto, port-number ] ] > > ipv6-address - the v6 LL of the proxy > transport-proto - 6, for TCP 17 for UDP > port-number - the TCP or UDP port number to find the proxy 1. We need to agree on the objective name; at the moment the draft is inconsistent. What's wrong with "AN_Proxy"? It also needs to go in the IANA Considerations since it needs to be registered. 2. It would be better to make normative references for the items that are taken directly from the GRASP spec: ipv6-address: as defined in [I-D.ietf-anima-grasp] but REQUIRED to be link-local transport-proto: as defined in [I-D.ietf-anima-grasp] port-number: as defined in [I-D.ietf-anima-grasp] > 3.1.2. Registrar Discovery Protocol Details > > A Registrar is typically configured manually. When the Registrar > joins an Autonomic Control Plane > ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP > ([I-D.ietf-anima-grasp]) M_NEG_SYN message. That's kind of jumping into the middle. Perhaps start by saying ...it MUST support the GRASP objective "AN_registrar" for discovery and synchronization. > The registrar responds to discovery messages from the proxy (or GRASP > caches between them) as follows: (XXX changed from M_DISCOVERY) > > objective = ["AN_registrar", F_DISC, 255 ] > discovery-message = [M_NEG_SYN, session-id, initiator, objective] No, that isn't a discovery message. In fact, it isn't a GRASP message type at all. Now we need to decide whether you want to support GRASP rapid mode. If not, there needs to be an M_DISCOVERY, followed by an M_RESPONSE, followed by an M_REQ_SYN, followed by an M_SYNCH. But you don't need to specify *any* of that, if you specify a GRASP synchronization objective. It's just bog standard GRASP. Similarly if you want to support rapid mode. Really, all you need to specify is the format of the objective, the fact that it supports synchronization, and whether it supports rapid mode. > Figure 6: Registrar Discovery > > The response from the registrar (or cache) will be a M_RESPONSE with > the following parameters: > > response-message = [M_RESPONSE, session-id, initiator, ttl, > (+locator-option // divert-option), ?objective)] > initiator = ACP address of Registrar > locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] > locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] So now I'm lost. Using M_FLOOD gives you the option of attaching arbitrary locators, but here you seem to be attaching arbitrary locators to a response message. 1) The initiator field in M_RESPONSE echoes the initiator field in the M_DISCOVERY. That's non-negotiable because it's required for matching responses to the correct discoverer. 2) The locators in M_RESPONSE are supposed to be GRASP locators for starting a GRASP M_REQ_* session. It's kind of weird to use them for communicationg the BRSKI locators. I can't see a big reason why it won't work, but it needs to be called out explicitly. (After the discussion back in Berlin, we added a feature to M_FLOOD to allow arbitrary locators to be attached to a given flood message. I thought that was what the BRSKI team wanted at that time. Seems not.) What I had assumed is that you'd return the BRKSI information as the *value* of the "AN_registrar" objective. That would give 100% freedom, independent of GRASP inner workings. That's what you have done in the "AN_proxy" objective. It would be simpler to do the same here. Also, 41 is not a protocol type defined in GRASP today. And does protocol 6 actually mean TLS in this case? Let me know your thoughts. I'm very willing to write text (and Python demo code) but I need to know what you want that's consistent with GRASP. Regards Brian From nobody Mon Jun 12 00:43:10 2017 Return-Path: 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 792B71273E2 for ; Mon, 12 Jun 2017 00:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 yItqFBJFffMi for ; Mon, 12 Jun 2017 00:43:07 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311F5128D16 for ; Mon, 12 Jun 2017 00:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2530; q=dns/txt; s=iport; t=1497253387; x=1498462987; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=7FsRFFzgytpSoYhlRMRxZNJWV/7/XJbuF4YZ/pFo30A=; b=DzcPeA0H7gmOCc0QNZKs7HiN9OZ1FYNP0vdMXKDla/auZTmAfmiduQl1 SP7G15EwtURB95ovdVjB/XaZ1eLsETkLEJ2/F7r1t8tnEnDnAxySh3Ty3 p0zhchvTrcelaMUdJhwkGU4G5APNf1llbH2as0eDyCTYt5oUZp0ho185v Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAQAQRT5Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYN0ihhzkFqWJIIRIQuFeAKDRhgBAgEBAQEBAQFrKIUZAgE?= =?us-ascii?q?DAQEhFTYbCw4MAiYCAicwBgEMBgIBAYooEK89giaLZAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBASCBC4VWgWArC4JqgyaBCYNNgmEBBIlXlGiHK4weggZVhG6DS4ZyjC+IPR8?= =?us-ascii?q?4gQowIQgbFR4qhxA+NochDRcHghIBAQE?= X-IronPort-AV: E=Sophos;i="5.39,332,1493683200"; d="scan'208";a="655351327" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2017 07:43:05 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5C7h5OB000750; Mon, 12 Jun 2017 07:43:05 GMT To: Kent Watsen , "anima@ietf.org" References: <149687914861.25640.11433787093634115213@ietfa.amsl.com> <0B3BBFCC-FAB6-4BC4-A2ED-7AE178647067@juniper.net> From: Benoit Claise Message-ID: <0b487182-b19c-7542-b40e-5452be27869f@cisco.com> Date: Mon, 12 Jun 2017 09:43:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <0B3BBFCC-FAB6-4BC4-A2ED-7AE178647067@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 07:43:09 -0000 Hi Kent, > [+benoit, for yang-validation error issue] https://github.com/xym-tool/xym/issues/9 Regards, Benoit > > Per Michael's nod, I just posted -03 that should address Sheng's review from a couple weeks back (sorry it took so long). > > Sheng, there is still a yang-validation error during the submission process, but it is due to a bug in the yang validation tools saying that it can't find the "ietf-restconf" module when it's right there in RFC 8040. CC-ing Benoit to see if he can help fix this. > > Thanks, > Kent > > -- > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : Voucher Profile for Bootstrapping Protocols > Authors : Kent Watsen > Michael C. Richardson > Max Pritikin > Toerless Eckert > Filename : draft-ietf-anima-voucher-03.txt > Pages : 18 > Date : 2017-06-07 > > Abstract: > This document defines a strategy to securely assign a pledge to an > owner, using an artifact signed, directly or indirectly, by the > pledge's manufacturer. This artifact is known as a "voucher". > > The voucher artifact is a YANG-defined JSON document that has been > signed using a PKCS#7 structure. The voucher artifact is generated > by the pledge's manufacture or delegate (i.e. the MASA). > > This document only defines the voucher artifact, leaving it to other > documents to describe specialized protocols for accessing it. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-voucher-03 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-03 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > From nobody Mon Jun 12 03:43:08 2017 Return-Path: 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 BC27C1294D8 for ; Mon, 12 Jun 2017 03:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 P7YngJuIXxFx for ; Mon, 12 Jun 2017 03:42:56 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457851294B7 for ; Mon, 12 Jun 2017 03:42:55 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud2.xs4all.net with ESMTP id Xmit1v00W4qMJlQ01mitVj; Mon, 12 Jun 2017 12:42:54 +0200 Received: from AMontpellier-654-1-119-36.w90-0.abo.wanadoo.fr ([90.0.134.36]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 12 Jun 2017 12:42:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Jun 2017 12:42:53 +0200 From: peter van der Stok To: ace@ietf.org, anima@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <149726370019.10357.2434726817483988279.idtracker@ietfa.amsl.com> References: <149726370019.10357.2434726817483988279.idtracker@ietfa.amsl.com> Message-ID: <1da3b214e4be22e843701e1694b29954@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [Anima] Fwd: New Version Notification for draft-vanderstok-ace-coap-est-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 10:43:00 -0000 Dear all, A new version of est-coaps draft has been submitted to the ACE working group. Apart from many editorial changes, this version includes: - a first security considerations section - a section about http/coap proxying - DTLS Proof of possession has been clarified - discovery of content formats - better link with text of anima keyinfra draft. We hope that the ACE WG likes this work and may consider promoting this draft to a WG document. Greetings peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-ace-coap-est-02.txt Datum: 2017-06-12 12:35 Afzender: internet-drafts@ietf.org Ontvanger: "Panos Kampanakis" , "Sandeep S. Kumar" , "Sandeep Kumar" , "Peter Van der Stok" , "Peter van der Stok" , "Martin Furuhed" , "Shahid Raza" A new version of I-D, draft-vanderstok-ace-coap-est-02.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-ace-coap-est Revision: 02 Title: EST over secure CoAP (EST-coaps) Document date: 2017-06-12 Group: Individual Submission Pages: 37 URL: https://www.ietf.org/internet-drafts/draft-vanderstok-ace-coap-est-02.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/ Htmlized: https://tools.ietf.org/html/draft-vanderstok-ace-coap-est-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanderstok-ace-coap-est-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-vanderstok-ace-coap-est-02 Abstract: Low-resource devices in a Low-power and Lossy Network (LLN) can operate in a mesh network using the IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer standards. Provisioning these devices in a secure manner with keys (often called secure bootstrapping) used to encrypt and authenticate messages, is the subject of Bootstrapping of Remote Secure Key Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra] and 6tisch Secure Join [I-D.ietf-6tisch-dtsecurity-secure-join]. Enrollment over Secure Transport (EST) [RFC7030], based on TLS and HTTP, is used in BRSKI. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252] for message exchanges. This document defines how low-resource devices are expected to use EST over secure CoAP (EST-coaps) for secure bootstrapping and certificate enrollment. 6LoWPAN fragmentation management and extensions to CoAP registries are needed to enable EST-coaps. 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 From nobody Mon Jun 12 08:45:02 2017 Return-Path: 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 91ECC129C67 for ; Mon, 12 Jun 2017 08:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 y_v89z1lresd for ; Mon, 12 Jun 2017 08:44:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466C212940E for ; Mon, 12 Jun 2017 08:38:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 85DBE203B8; Mon, 12 Jun 2017 11:39:57 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2386B636BB; Mon, 12 Jun 2017 11:38:52 -0400 (EDT) From: Michael Richardson To: Anima WG In-Reply-To: References: <149566389334.8737.940293315082013190@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:45:01 -0000 --=-=-= Content-Type: text/plain {note subject line change} Brian E Carpenter wrote: >> 3.1.1. Proxy Discovery Protocol Details >> >> The proxy uses the GRASP M_FLOOD mechanism to announce itself. This >> announcement is done with the same message as the ACP announcement >> detailed in [I-D.ietf-anima-autonomic-control-plane]. bc> Can we make it: bc> This announcement SHOULD be done with the same message... bc> That's only an optimisation, really. Agreed. I think we all agree that the announcement of the proxy (and the search for ACP peers) is something that M_FLOOD is good for. bc> (After the discussion back in Berlin, we added a feature to bc> M_FLOOD to allow arbitrary locators to be attached to a given bc> flood message. I thought that was what the BRSKI team wanted bc> at that time. Seems not.) yes, we asked for two locators to be attached to a flood message so that we could announce ACP and Proxy in the same message. Given the experience with rate limiting that you experienced, this seems doubly prudent since this M_FLOOD will occur outside any ACP, and will have to traverse any number of layer-2 devices. (This will be worse at the beginning of ANIMA deployment, as the layer-2 devices will not be ACP aware, but will get better as more devices get with the program...) So, let's leave this part, which is https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1 As there is no dispute about it, I think. If it should be named AN_PROXY, that's fine. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlk+tYkACgkQgItw+93Q 3WVqewf/aKRlTRxNY/o+cEnzsrMOVaIRpCJszogqLirVyRlyjYGNed+iCaqKB8Av hMz4rZhZohErTobGfObKmO1XRJiwZuJ8E5cR5nIXhEcTQ983Kjagef/j0fytXM5w SheV3uVN16+H5j55RixZEl084OB0dmggSOIhpLKtVnU9VFfR6HUGs7kZJKdatTVW VqkKJrpoq0BTr35Vpw24c1ZU2tKIuV5LlNcg0T6Zxl8PBd3B0KBvXFTxVf7zAETZ u+90YGX0/sZeLeZMSgchV28VgsvNzQE9j6t7cuKorH7Et70GjvB1WRlXq1kO2rdR zyDZqazM+V/F7a634MD4pVz5UDi+Jg== =bZ1I -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 12 22:12:25 2017 Return-Path: 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 C8ED812955A for ; Mon, 12 Jun 2017 22:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nevzX4QEjv_O for ; Mon, 12 Jun 2017 22:12:20 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 BA7151294C4 for ; Mon, 12 Jun 2017 22:12:20 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id x63so61637510pff.3 for ; Mon, 12 Jun 2017 22:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dH8iW1LT449fW2zgxcUiI54QiyhQj6QxIuvZ1Z0VTMQ=; b=ufrwZmbDeGXBddC6A3PMTt/am+A5CMKZ8UzJ6vhC9GDbcwlZG/wuLeGbm+XZsnxbyp lROVgwVvFEd49DXvW0EyOaU1v03l2a6/pJ5f4GkE/R6+GZJ2NGBGqN93Ve6mrM65kY78 h9krQ9VO6lqkvqD751jxuhFROixZcdZK/JM1Vu6PQl8M8MtpW5WEsihBe3zTrsbg4EjJ We7uPwRugO29EWBBY9z3vp7233tkWR9oa99rymwChfyJThdzFcN95PckxoZFVBUYBoHe wTvIUVjsAU/LfRhZ6qbt9gan0uJNyPlvmINomL3U5Lh1jI2xtjnm/SFt/jXVWL6Ttt/u j82w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=dH8iW1LT449fW2zgxcUiI54QiyhQj6QxIuvZ1Z0VTMQ=; b=rvo9QqlWoU39k5PnuRhZEe2jjYda7xnnGRQ9armfT0H6fbgGUfrilaeMxEeQySTN3r jIJ0T2MV4Es8699WYTwIvGSbuj1b7r53zwIL+RqRkxsrlPgCecXSIwb1MugFM1FiCDDj DBsUqpVaPFipFBcKP0GtEnHieM2ILOYREcQwZQgl6JPPrQGYnOnvVmrPADEDA8gABWE5 13dEJOf1Dx+UWndWssM55HahyoAq2wnZJX0MkhS0SpvcitrqSW9PL3/oM10W+LbRl1at ROw46mbf7gZbhZWZVKvtbcNYV65tSVmvtKgwRYMtBMsJMqMFP73CQlYfeDivcA9ljF+c I5FQ== X-Gm-Message-State: AODbwcDRfMNl00hCVlEafCzFUQqVGXlgZWw/D/g5B47JVS96BGyEqtyA Ws2osB7anLNdB0Ij X-Received: by 10.98.245.24 with SMTP id n24mr54544264pfh.80.1497330740134; Mon, 12 Jun 2017 22:12:20 -0700 (PDT) Received: from ?IPv6:2406:e007:7b4b:1:28cc:dc4c:9703:6781? ([2406:e007:7b4b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d185sm19593348pgc.39.2017.06.12.22.12.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 22:12:19 -0700 (PDT) To: Michael Richardson , Anima WG References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 13 Jun 2017 17:12:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <2540.1497281932@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 05:12:23 -0000 On 13/06/2017 03:38, Michael Richardson wrote: > > {note subject line change} > > Brian E Carpenter wrote: > >> 3.1.1. Proxy Discovery Protocol Details > >> > >> The proxy uses the GRASP M_FLOOD mechanism to announce itself. This > >> announcement is done with the same message as the ACP announcement > >> detailed in [I-D.ietf-anima-autonomic-control-plane]. > > bc> Can we make it: > > bc> This announcement SHOULD be done with the same message... > bc> That's only an optimisation, really. > > Agreed. I think we all agree that the announcement of the proxy > (and the search for ACP peers) is something that M_FLOOD is good for. > > bc> (After the discussion back in Berlin, we added a feature to > bc> M_FLOOD to allow arbitrary locators to be attached to a given > bc> flood message. I thought that was what the BRSKI team wanted > bc> at that time. Seems not.) > > yes, we asked for two locators to be attached to a flood message so that we > could announce ACP and Proxy in the same message. Given the experience > with rate limiting that you experienced, this seems doubly prudent since > this M_FLOOD will occur outside any ACP, and will have to traverse any > number of layer-2 devices. > > (This will be worse at the beginning of ANIMA deployment, as the layer-2 > devices will not be ACP aware, but will get better as more devices get with > the program...) > > So, let's leave this part, which is > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1 > > As there is no dispute about it, I think. > If it should be named AN_PROXY, that's fine. I think it does need some work on the way it's described, but I agree, we are fine in principle on this point. Brian From nobody Thu Jun 15 02:19:26 2017 Return-Path: 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 513DB12DDD2 for ; Thu, 15 Jun 2017 02:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2BY0M_1aBBGW for ; Thu, 15 Jun 2017 02:19:22 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F300E12D574 for ; Thu, 15 Jun 2017 02:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27236; q=dns/txt; s=iport; t=1497518362; x=1498727962; h=subject:from:to:references:message-id:date:mime-version: in-reply-to; bh=AikWAaRlNtC3RqLSU9c1EqIEceJpO47fP4m433d24mw=; b=ieUKhfxRmqS8dDS1QK8DR859iz5kOqca/IvmRaJPNPycPtPnnQ+geQBh y5C5NvXz2RGRaDcSJT4xumvygV0kT9R0eVAd8BJtuGh/eVegwY6kslgFq KvsJ4ZwQ2OvSTPuWe3RUSFRE6cpzJzonStUR2VugP7zZIGSw9lbPVTjtD Y=; X-Files: dnpkbcdfgmegcgmj.png : 13119 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAACjUEJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDqBDYN2ihhzoVGFOoIRBwEZAQqFeAKDGhgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAgEDAQEDHksbCQIODwEBASICAgIVAQ4BMAYBDAUBAgEBAoomEIxknD6BI4ImK?= =?us-ascii?q?4siAQEBAQEBAQEBAQEBAQEBAQEBARAPhmKBYCuCd4MmgQmDTYJhAQSJWJNWgRu?= =?us-ascii?q?GMAF8jCeCB1WEcYNLhnOMPIhDHziBCjAhCBsVHyqHET42AYcUDRcHghIBAQE?= X-IronPort-AV: E=Sophos;i="5.39,342,1493683200"; d="png'150?scan'150,208,217,150";a="655434501" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2017 09:19:17 +0000 Received: from [10.55.221.38] (ams-bclaise-nitro5.cisco.com [10.55.221.38]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5F9JHwI030499; Thu, 15 Jun 2017 09:19:17 GMT From: Benoit Claise To: Kent Watsen , "anima@ietf.org" , Henrik Levkowetz References: <149687914861.25640.11433787093634115213@ietfa.amsl.com> <0B3BBFCC-FAB6-4BC4-A2ED-7AE178647067@juniper.net> <0b487182-b19c-7542-b40e-5452be27869f@cisco.com> Message-ID: Date: Thu, 15 Jun 2017 11:19:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <0b487182-b19c-7542-b40e-5452be27869f@cisco.com> Content-Type: multipart/alternative; boundary="------------E737A63CC558EEB1C41F0D80" Content-Language: en-US Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 09:19:25 -0000 This is a multi-part message in MIME format. --------------E737A63CC558EEB1C41F0D80 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Kent, xym issue solved (thanks to Carl Moberg) and integrated in the "development mode" tracker (thanks to Henrik). http://tracker.tools.ietf.org/doc/draft-ietf-anima-voucher/ => click on the YANG button. Regards, Benoit > Hi Kent, >> [+benoit, for yang-validation error issue] > https://github.com/xym-tool/xym/issues/9 > > Regards, Benoit >> >> Per Michael's nod, I just posted -03 that should address Sheng's >> review from a couple weeks back (sorry it took so long). >> >> Sheng, there is still a yang-validation error during the submission >> process, but it is due to a bug in the yang validation tools saying >> that it can't find the "ietf-restconf" module when it's right there >> in RFC 8040. CC-ing Benoit to see if he can help fix this. >> >> Thanks, >> Kent >> >> -- >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Autonomic Networking Integrated >> Model and Approach of the IETF. >> >> Title : Voucher Profile for Bootstrapping Protocols >> Authors : Kent Watsen >> Michael C. Richardson >> Max Pritikin >> Toerless Eckert >> Filename : draft-ietf-anima-voucher-03.txt >> Pages : 18 >> Date : 2017-06-07 >> >> Abstract: >> This document defines a strategy to securely assign a pledge to an >> owner, using an artifact signed, directly or indirectly, by the >> pledge's manufacturer. This artifact is known as a "voucher". >> >> The voucher artifact is a YANG-defined JSON document that has been >> signed using a PKCS#7 structure. The voucher artifact is generated >> by the pledge's manufacture or delegate (i.e. the MASA). >> >> This document only defines the voucher artifact, leaving it to other >> documents to describe specialized protocols for accessing it. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-anima-voucher-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-03 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >> > --------------E737A63CC558EEB1C41F0D80 Content-Type: multipart/related; boundary="------------C2B26408A63E0D6A1786F388" --------------C2B26408A63E0D6A1786F388 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Kent,

xym issue solved (thanks to Carl Moberg) and integrated in the "development mode" tracker (thanks to Henrik).
http://tracker.tools.ietf.org/doc/draft-ietf-anima-voucher/ => click on the YANG button.

Regards, Benoit
Hi Kent,
[+benoit, for yang-validation error issue]
https://github.com/xym-tool/xym/issues/9

Regards, Benoit

Per Michael's nod, I just posted -03 that should address Sheng's review from a couple weeks back (sorry it took so long).

Sheng, there is still a yang-validation error during the submission process, but it is due to a bug in the yang validation tools saying that it can't find the "ietf-restconf" module when it's right there in RFC 8040.  CC-ing Benoit to see if he can help fix this.

Thanks,
Kent

--

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF.

         Title           : Voucher Profile for Bootstrapping Protocols
         Authors         : Kent Watsen
                           Michael C. Richardson
                           Max Pritikin
                           Toerless Eckert
    Filename        : draft-ietf-anima-voucher-03.txt
    Pages           : 18
    Date            : 2017-06-07

Abstract:
    This document defines a strategy to securely assign a pledge to an
    owner, using an artifact signed, directly or indirectly, by the
    pledge's manufacturer.  This artifact is known as a "voucher".

    The voucher artifact is a YANG-defined JSON document that has been
    signed using a PKCS#7 structure.  The voucher artifact is generated
    by the pledge's manufacture or delegate (i.e. the MASA).

    This document only defines the voucher artifact, leaving it to other
    documents to describe specialized protocols for accessing it.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-voucher-03
https://datatracker.ietf.org/doc/html/draft-ietf-anima-voucher-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima




--------------C2B26408A63E0D6A1786F388 Content-Type: image/png; name="dnpkbcdfgmegcgmj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dnpkbcdfgmegcgmj.png" iVBORw0KGgoAAAANSUhEUgAABFYAAAFmCAIAAADI4Ik7AAAgAElEQVR4nO3d748c9YHn8f5b +tFII3vQ9BMnOiVCQuGBJQSBIM1pRiKRFq0Eu+sE7+rQWncnYQX7ktxsgk4i4kl8IsdOzpuZ cOxJkXU5EaP8gIk9ngxhYZID5xLjWzwG2xjaeOy6B1XVXT+7q+aHuz31euv9wO6u/tbP6f5+ 6vujWgEAAAAANIbWqDcAAAAAAO4cIhAAAACABiECAQAAAGgQIhAAAACABiECAQAAAGgQIhAA AACABiECAQAAAGgQIhAAAACABiECAQAAAGgQIhAAAACABiECAQAAAGgQIhAAAACABiECAQAA AGgQIhAAAACABlElAl148bGJdrvdnn76VLdwgXPz9w98fwRsvPS1iXa73f7Cs78uXSba7Iee X69a6uKT7Xa7/eRi+tXua8e+NNmeOHBo8cKWy9gm6y89fmCiPfngc2dGdQauvX7iiQemJ9sh k9P3/cWJtTu9DeEJvX/+3M4Wu1O7tpsnaQwO/+ivwbuPXfky2CrX1haOPHpfdBFNTt/36JET r2e+0aKvzELGZC+CIAiC7vlfnfjmYw8c2D/R35mFtWuFS/7s+SfiBSf2H3jgifl/fqv8Ar62 duLxAxOF+xqey1ImDr1SYcMrnIPcJ16ef+rR+6YnH3txo8IKsnTP/+zZBycrf2l2z8wfnBiv cw0AW6VaK1D8y1f4RRmljYnHXqySAO4U3Z/+7T2DM9Cvn/1Cu91u1/nlKK6x9H77vvbSla2W UYVzL/39Yw9MHy74ZK9mMijx7SYbi0/ek/nFf3LxjteEdyUClexa+ckYvHVbPkkbp777l49+ 8ZHninZuHA7/yK/Bu5HxiUAXFg8dmMhX3KdnXkgm2lwEmtg/vX+i3W5PHJwfm+T7px//VdGu FGxj98xzD04WLHjv0z/N/5Z1z79y5EvR0jUi0OT09GS72v3BaucgsUVvvfh4/wP3PH2q6hGK uPb683PR56t9aV5YfHK6dP8B4A7w2ZU//sv6v35yO/Xi7e7G7998J/vqcCp2hOueenq63S7K Od3XnvlC9e/QO0kUccp+GcK3J772Uo17Z8U1lo1T//GOtAIN+OS5H8yN9A78K4cm2u32F/7u 5d8X3Wm9U+xKBCrZtS2cxu2dpEE7NxaHf9TX4N3IuESgXkP/1068cfFaEATXfn9qfib8yj9Y mLpDumdemJkerwAUBEH31JGDDx85cXrt4rUgCIJrF3/+fLgv7a+88F5iseina+LgM6fe3ugG QXdjZeHQveGBOPRK8nchDgsTBx48+LlaZyxqNqnQ1aDmObjw06fvjdq4vvTE/Mtv/HGjzhno 5bnJBx+s+qV54eTj8Y2W0V+xABpJ91//5TfLy8vLv/nd+9dvRa/d/uTiv5xZXl5eXn7zzx9v 1iqu8ligkt5w6y98ZaLiPa47TpyB/vanBdv22jOfK32vlJ2osexKBBo147FpuxKBSnbtju/x oJ0bj8OP2ozJiYu+Ke//dirIxBGhtHkhujE28ZUXKnclHhVxx+jEoY5euufxk6k7V/EPXS8t XfnfR7802W63Jw7Mzb96oeYZq36jrdY5iIJVuz098/zrtW97vPlfv3pgot1uT37p8Mm3zlT7 0ozWOP2Vr9w3DlcsgKby2YfvnQtT0Nofr3wWfHbtT7/7zfLy8vLyyu83urvUChQEvbST/LaM OuD024au/f70iW/+5aP3fT4xLOGBJ57/2flU0Dg3f3/UAS3siR0tPLH/wAOHTxZ1xM507W63 J/Yf+PwDj/39/D+dGfTTsv78Q+2SH6BTT9/T7vfZ6W6svDz/94898PneGib2f7Gg93jJ7195 7TTs2h2XOrH/wH2PPvCFbBnD117SxyJRSOkv87W1l+efSHeKP/Gr85ljvPhku/25Z16LN/iL /aW/Ov/qwKatksEBiWNRawO6b508fDDsWbP/bxYHdisML53ehTY5/fkHHj54T+Y8lJc7/KCX 7dr9xcMhKtQKBpykhdTIhc+n/mYGHOPhh7/s6FW64uv9oRbs3rn5+6NBEN23TvYurMnp3se7 5382/9Vo7ENRsVX/Mot2cVBX2Lj+m7gFUvlCLTyFZd8B2cEdX51Pfhn2i8sNAvnmK9l1R8UN uFJ6Zdb7WyrtEhx9gRZnoI1XDk238xFiMN3zvzrR389w7M3L2ZNZ+/ehAtFfSr+vcnQFhF97 qU2MrpteBuqemX/kYLziWhEoKqrKDcJa5+Dccwcn2u329JOV+h3kubB46OBc9M1e6b5R1ANu 4rEXXzw0UX3/AWAX+OzKH9fCFHTut1EcOvfe5Rt1809Qb0a4XseBOPFEPyv9r88wWBSQ/rI+ N39/u/25Z/6515SfJNfX7kLhYpXqevEwpWwGin6a4srRey98pbj4bAePWhGopKN5SKKMCmvf agQq6Vye6620+GS73X7sxKsvRP1FUnzhmdfKf8CH1MHrbcD3XzrUX3+qz0qWsnKT6x5YboWD fociUNSXKE/vb2YXIlDFK77eH2pJBGrfP/9qQQHTh165EN/LTr2erC9W/sssJDo6BU29Ubn9 7km1LtSqEajk1E78m6On08WdKFx7tuY8/Erpl1njbyk+GEUXTXQEDz73ZvadKADVqoWXfSNm +xDXu+yqEf40JYJE9FtVPqqneP6COhEoumlYZb6dOucg+lXLtBdtlQoRKApA008uXhiXdksA zabf+BM3B22JepNix8Ou73lycSPuMZD8oe7+9MjBR498/9Qb74a9sIPuxtunnjk4kfkV7lfc Jr90eOGNqMf276Ml07dt434JiSWD4NrFd//n339u2Dd3UHBHL/lq/6dp/YW5g0/M/+j0Wtyh +trFN058bbqdvQFaIwJFVYT2xIHHv3/67X6xL//d/dkytrn20veie4Xt6Zn5sK97cO3iGyei AbSp+lUvYk0cmIuX7W6shBtRpRtH8abV34DpmflTw8ezxOVOPvjvX36jf6Wd/i+PFbUCFZdb 9aDvZEe4wpMUzaY482y8K92Nt089++Bk/GeWXnCnOsJV2/06f6jlEajdbrcn7j0Uff7axZ9/ O7ospqfbkw8+G18acbGpy63yaSqk7BZIeGe9/3LdC7VSBIrvGCVK7W68ffrE4YNP9Danf2+j f4D7f3jpNoGqV0q9v6Ug7hNcfPmEheWOdVgpnvzSkYJpA8rofSP2LoX+9qc709W77CoRdUjr TxKy8eJj7bK/p2j9hcGxxp9andGmNc5BePHW7MJdzrAIFPWAi+85iEAAxoBeQ9Dy8vLyyrtb agIK6j8XKO4N95UXTs3f3650Ty78sUneU4t+YvJ3cqNG/8RvT9Q/IN8SUXXcR3SzL3knrrv4 5ESFn6bwVyl1A7R6BIq7L+R7iVT8Dam+9pL3opyX76gfh8rEIYlqTblbulEZw2ubRZtWfwNS Vf5S4libvwuaPw91yg0KD/ruRqDwUiy4vC+c+LeFfzS7OhYot/s1/lCLtyJuh8n8GcR13Gw7 R7gB+b5Jw7azlPhaSd+ID79UepXI+hdqlQgUndrBN+ujP7zcAY43qX/+q18pNa/53kYUXj6F bSVxt6jJyYmwL1u2L14R0SWT6xTWG+3Sr9PXu+wqEH+PJWJDrgdDggFNMtX/1Gp0ggvqnINw 4z73zM8SXZYrn4QCBv+QRsO9+r8MIhCAEXP7xuV3V6L2nzfXtj4QKNjCo1HjX6yHHnqoUgQJ Cr41w2/dovtYZ759X6rU6OZYwW9e5aHv8TDT3pLhreHhN+cK1lA5AkU/okWVuYq/IdXXXvJe 9MNZNOd3dFT7b4WfLuiw0T35eKWtLdq0+hvw+Mkqv+Hl5ZZFoGrlFhawyxEo3JeiyyS3KXcg ApWss8ofaslWhAXc9+0zhRuc3+9qO1Jn2ov4Hkqi5SA9DnArF2qVCDSg1D5hcUXNGtkVVb9S al7zg6vfUVJIv1fQL3foRIADvhGjBpn+W/Uuu+GE9+3SEXdQBIp2cFsRqEYnuH6xVc5BOPvj 9HRRD8t7j5yq/WygQX9MYdZNRVERCMAoud3d+H2Uf373/vVbiengzvzLxd2aFDtJ/yEkBXe4 0sNd2+325HQ0djcXgcr7Pfd+DKMaeL4KVacaFN06jOsZYQLK/r6mx0K32xP7D4T7sLUINKBf Q1EZ21p78XuDOnpEh7Vf5ygvOXxn6LOTCgrYoQ3IMaDcsghUXG61g14vAuUrhwO3JtqXcrYT gQrGCSWXqLL7lf9Qy7airICyqmxBERW2c+BRz058kOsFuzMXanZPB5U6cH9T7/T+8GpcKWVl lh6l2q1A/cOz8fbpE4ejh+UMru0P6ukVXg39na132Q0jmss50xq3y61AJZ3gtn8O4r/qiXsP nYg7WF+7+EZvMu/eT/Lgr6LsgSh4L+wBl31GkggEYIR8cjEcArSSeAhQPxWd+T8f7tKk2Emi n6xcMhk0AUBy4WE/cb1v2AG/UzXuBKfm/gnrEun7roMG16fuplaOQAN+0XJlbHftxe9VuMvZ X3xYTWzoYS7vA7XdDchR65ooLbfyQd/VCFQym0GfRPPnjkagirtf+Q+1bCvKCih7PVtEte0c fNTjTmVhdTR/B2RnLtTsHg0sddAhS73T+3iNK6V2BIrSSWG7UclYoBRxx4CBPRMrNHNkdrbq ZTeY4gDUy5RFd9e2PxaotBPc9s9BFAL/w6vZBaNem71Ttc0I1D3z7fvb7cQtzGJkIQB3ls8+ fO93f8j2ert94/K75373/p1oBSr9eY/6nCTG6wZBEFz7xdHsHd/KP3FvPnew7Lu7TmeYqB/9 PU+fim7wpT4Wj5lO3FYLgqC78cO/yH3HV45AQ6cb6r2z/bUXvzfoJz7XD2k3ItAObUCOoXMn VYhANQ76rnaEi/al0tiGHewIV3n3RxyB6pymQURfTF954b2iOyA7c6Fm9yg6tcWlluxv/p1e eTWulNpX5oA+atEX8LDVhqssnkItYlAdP7qYKrcCVd65zFD+FAM6KoZ9zYpzX5WjW7MTXBDU OAdDj02VIXL5j+UKHJq5Q0QgAHcxOxiBst0Z0ktvKQLFv639iXwya6vYKzy6K3fft8+8cij7 qO5cX5eYgh+7yhEo2o+CClBU4YrL2IG1l7w34Cc+OlPDbxxvJwLt0AaUrauoMhVWs4ZHoDoH /U6MBaoyudkORqDquz/aCFTrNA0kukP+2IsXFp/M/v1v5ULNR4LoGyaxR2E9ekg9uPofXvUr pf6VmRsuGZMbpVPMgP7KPQbU8aOP9/dthyJQci7nPHG+zv+25AaAJalwdOvMBJf50PBzEM+G UDYmrM4gsMTHKg+v0hEOwN5hByNQ9Juf/QqOqh9bi0DxjFLZ6Y2iiWqqf3OHvzCP/d3ffS77 2xTdZMv+fse9O7YWgeJqVW4Cp3hGvUw7V6W1hwe4aiW492TI7CbEx67KPFfbiUA7swF5ospU bi7ComuiuNw6B71s0wadjDIKTlLUPlnh8ZLRRhceo3r1kuq7P9oIVOs0DSa8Fie+dujJe0qf ElbpQg03PFvEtZ/+bTg6PTkGKRq9M3BKsOp/eNWvlC1UUuP2+0OvJHcr7gs1bBLquAvW4Gma 4+dU56YQjb4SczPCbS8CDWoACokz0MHnUuuJes6VJZihR7dg9rlKVD0H0XSG2esgXrDuVBEi EIDmsoMRKK6a3vv0T3rP1nj52bkDk5OTE1uNQPEPZ+L5IYmHSdT5wl9//qF2e2JiIv/bFKWV 6Znnfx4/reL0icNfmpycnCyu5E0/eTI9/WjR/kS/aOlHjSwcundiYnJyIlFsjbXHh/3ZX2zk fl2Lfpn6j8/pH7uVl/99eOyqPe1kOxFoZzaggKjuknnAyPzMdHtycrJSR7gaB31w7C0+GWUU FNV73PCBuflTa4lnHJ048vDj6UmaoyEBj/8w/7CXmvWSyrs/4o5wdU7TMOK/x8JIUv1C7W3T 106sJP+q2/ccPPiF9B71po3pX6fRV+Ij34rrszX+8CpfKVuppPaevvbgs+GzhHqPX8pUtt/7 wRNzz778xh974/BffjZ8XGs2SeRJPCntRO9ZP6e/Hz59qeC5QNuIQN23XvzadDs3lD+7VO+I Ph6ezP5T7MqnMh92dLfQCS6i6jmIlps48Pj3T/8++e2XO1mVEIEANJadHAvUPXUkP3Z5+snF t158bIvTIQS9u3m5Yu+9N/sYzCFkZ4bqs/6DmdwkDhMH58+8+sznMo1acSCLiN8r3J+NU0cK nm0eH45+j+3qaw/+95HMTKj9H9riX6ZtP/N+exFoJzagkHM/mMnPCRsftOSQhLJyaxz0siIG nIwyCosaMIfIgf94OrHgez+YSR/K/qVct15SdfdHPR1CjdM0lKjmWHKWql6o/biU2qYDhxYv vJa59oLgwk+fLvgKaLen5/7rm6WHLHUkUkeo4pWytUpq8QHIhojoNtewxUoo24GJA4dSfdW2 F4G6508+GWat/QfyQ/mrHNHpmRfOFNzjKiSzKVvqBBdT7RyUXqwVz0IQBEWTJRQeoLIPikAA 9gI7GYGCILjw6vNPPBDOWTux/4uPHllYuxZEP5xbrlkF3bf+OTEt7uT0fV999p/fOlPv5lUQ ZaDiTh3dt072HjM3Od17ytypp+/JdMPpnnnhq+FyE/sPPPDv/sd7A/fn2tpCf4LwyekHnnj+ 1QvR4sliK689uPb681/9N3Fxn3/gsW++tHolfKf0lyk9p/Dk9H2PHjnxq+wz9HYtAm1/A0ro nv/Z871SJ/Z/8dEjJ9/qRt2FEldaebmVD3r5kS09GWUMOEkLRx69Lz5GE/sP3PfokROns609 3fOvHDnYexbifY8+9dz/Oj9sN8uotvujjkB1/jaG7/JP//aeQXXTShdqEERfcslLL/yW6558 PD+AJPvd9cAT8y+v9c9r7T+8ClfKliupua+r1KZG+5P8u2tP7D/wwGPfLD5KxaQfmjCx/0DR WrYXgcpr90VHNP9FUrA7VSPQVjvB9alyDgo2u/aTUUUgANhaBBoHarbfAwAAAEBwF0egsE++ CAQAAACgDndpBIpHstadARQAAABAs7kLItB7P/jqwcPfPxU/bTU5C9HWRp0CAAAAaCzjH4Hi 52vkKHnkHQAAAACUMv4RKOie/9nzT/VmySmdRggAAAAAhnIXRCAAAAAA2ClEIAAAAAANQgQC AAAA0CBEIAAAAAANQgQCAAAA0CBEIAAAAAANQgQCAAAA0CBEIAAAAAANQgQCAAAA0CBEIAAA AAANQgQCAAAA0CBEIAAAAAANQgQCAAAA0CBEIAAAAAANQgQCAAAA0CBEIAAAAAANQgQCAAAA 0CBEIAAAAAANQgQCAAAA0CBEIAAAAAANQgQCAAAA0CBafwYAAACAxqAVCAAAAECDEIEAAAAA NAgRCAAAAECDEIEAAAAANAgRCAAAAECDEIEAAAAANAgRCAAAAECDEIEAAAAANAgRCAAAAECD EIEAAAAANAgRCAAAAECDEIEAAAAANAgRCAAAAECDEIEAAAAANAgRCAAAAECDEIEAAAAANAgR CAAAAECDEIEAAAAANIgaEejatavr62+vrJxdBgAAAIBRs7Jydn397atXr+xKBPp/Fy+srp7b uPT+zRtXg1vXSZIkSXK03uhe2fjgwurquQsX/rTDEeja1Surq+eEH5IkSZLj5uZnV1dXz129 +tFORqD19bc3Lr0/8n0jSZIkybwbl95fX397JyPQyspZTUAkSZIkx9Mb3SsrK2d3MgItLy+P fK9IkiRJsszl5WURiCRJkmRTFIFIkiRJNkgRiCRJkmSDFIFIkiRJNkgRiCRJkmSDFIFIkiRJ NkgRiCRJkmSDFIFIkiRJNkgRiCRJkmSDFIFIkiRJNkgRiCRJkmSDHIcItDDXarVaM0u7tJOr R6daPXZtLTu+tbMLI9yMtWP7WgmmjuVO6+JMa+hRXZxptVpzi4NK7lNrf6usvbfY1NG1eru/ fDxxxST3fWc2niRJkiN1DCJQVOnfd3x1F/Zw9ehUYQ1+vF2aHWmtevXoVDJXLM4UJYHe+QoD QzaHLM1G6SATgcrO0fDF6qw9ztX7jq9eD1aX60SghblkpMnt+zY3niRJkiN3DCLQ1l2YGxpv Fmd2K1ztpiOOQIXb029LyR32bM7sxY+FuQrxIF34UIeu/Xo2xtRx7di+TKBamh3U0FRz40mS JDl693gEytdo7wrvSARKdfcavLq1Y/v6Ff2CVLl8fKqfBBKpoEoEqhST+g5b+/aO3vLxqdxn i7rzbXHjSZIkOQaOMAKlq+DFt9JLqump4T0pevXRXkesLYzZCId85MJVtqqdHhnSD1rxqge9 kvt4bvnZhfRu5tqyUuNhku+GjTCteBf6/+1X1jMtJ8O6eyXbOgpSZbQlxb3RBieEuhl1+NpX j05tvd0vH6qjK7Dw4NTc+JI+e5mIlTqt+df3HV9NXzm5Szp35ZdcORqvSJJkUx2LVqDi3kRh AOjX8PK9m3avFSibduLt6dcmM/2jwnpnr8KaX2/mlaXZTN10+fhUf19ykamooSPx8fTwmOSL /UISbSP5ZFLU+pE+EalsmTwyizOt1sxScYfDoRGoQlfGwZdKbu1rx/a1ZhcGh4RSswN7wpOy UHJwam984cCh1B5l8lv2qC7MtfbNze4rH6q0MJfJNkVrzFwYJEmSTXN8I1DBi9kb/LvZES7X /Sm1PcO6Yw2JQAV9q/IRKN/WEa+xrCadrqaneq8l/lv1aJe8lTsOM0vFB+T60Ai0hbMzbO35 RpuiNFtm6sD2zkhxPtzSpZXfmNR5z5k5gPm7AKltK7hszNZAkiSZc2wjUGG8KagRbj0CpXsc 5boGZSq+qVUXFpt8cXAEGlp7LhjNkqjLlq49fQzzrxQdwwGnoLeuVLbpLTlsgFDpukqOcPr1 NPk2qJK1F10SmRgw4Lz3l0xueeF2Dmw3G2DmQA3ptpfZnYLjmThxRZskApEkSeYc6whUSKZG uHvTIeTabdLd2PKBIdMdqzwCDZ1GrEIEKiS3xuLuhdFGZgeNFO9RUTeqqaNL+SamumOBtjRZ 37C1F66xeo+18OMVkvbWZxpMlVYcXAde8OURqGgePBGIJEky51hHoGHV1t2eEa5f/tJs/sE4 49UKVLzvxalmZqlwLFNm4bKZ0MJWlPTmlYS6ARFoO60oA9Ze2nhYbV1hA1Q62xSkiK1ufO7s Z050rs2tIIxpBSJJktymYxuBqjxxZXhNdJuTYkfbkO+tVBQPioepJDc1NWvZoIrp4AhUsV47 MAJlD13maJfMiReajxllWbQ8Au1QK0r+lRpZrtoFUzIH3TYeNlXc3e560fVcKwIV7Ht4HkUg kiTJpOMbgXIzwhUMnMjW8BZnCqYE2M7MV6tHpzJzcCW3OTsnW+ms00uzranZmancDHKpqvzi TKouO/B2fm5CueHTIWSOYaoVKD1L8sD801sgPTlecVgtjUDbeaLokLVnLpv8VTTEdJPR0Dnc io2GM5Vlj+hkZXNypmku6gtauSNcyb7nN8Ok2CRJstmOzXOBikekZEYE7Tu+urxWPPVzPBhm dbmfIvLU7rw0qC5b9lygyMSw+6ljywX10cy4/Kmja6sLS71ROsN6NGUHjcwuBNG+Fw+jij/b q0Ynjn9UHQ+PcMmhyxyE5MZnK9OFZ7Y8Lm7BQWvPbkC9eatzHy+cUbrK814Hrbq3/YWzLETE jXX9xYZFoFv92BOVYFJskiTJnGPRCsQ76XZaYLhz1n+s0BY0FogkSTKnCNQ8y6rFq0ePqyvf 0bOwjQFFFd3msCWSJMm9qAjUSHPzqkWdo7QO3SkL+jruULEDH6VKkiRJEai5ZkbsGBlyJ+yP s9qNtLl6dG4qNUJs1zvakSRJ3oWKQCRJkiQbpAhEkiRJskGKQCRJkiQbpAhEkiRJskGKQCRJ kiQbpAhEkiRJskGKQCRJkiQbpAhEkiRJskGOKAItzrRarVZr3/HV62vHEg9z7D3JfnGm6MGO y8enks+UTD/cM//67EJwa2Guv8S+46vpzVg9mno6aHID0kXNLY7+VJEkSZLcviNsBYrDSS91 hIEk/u/SbDLV9BfopZGl2WRiWT4+lQowa8f2tWZn5vqxJwwzM0vJBdLZpmCN8UbmwhhJkiTJ u9JRR6B0q8vasX39tprFmWzzy+JMMsNkXDu2LxlgUkX1Px6/snp0KhdsiiIQSZIkyT3liCNQ tnUl1c6TbdhJN/tkXTu2L9vIM6ARKRmHkuWLQCRJkuSedpwjUCbVLMxlx+Qkx/mEVI1ABW1E IhBJkiTZAMcsAmUbZxLLrB6dyr2VHfyT6QinFYgkSZJk2vGKQPkQ0nslG2lyGaZeBEo3N/W2 RwQiSZIk97ZjFIHyU7QFt3qNP8vHp9J5KT2fQTyzduWxQGG4SoSopdnMzNqhJsUmSZIk95Sj nhGuZCRPwt7Df3JP9YkeLhRPWp141lBQIQIFvdgTl2BSbJIkSXLPO0atQAPMzPa2SxoLRJIk Se55744INHg67B0yOwc3SZIkyb3n3RCBsnPB7ZCrR6cGP0qVJEmS5J5zjCPQ6tGpeKDObsxG sHRs31Qrya53tCNJkiQ5ckcYgUiSJEnyTisCkSRJkmyQIhBJkiTJBikCkSRJkmyQIhBJkiTJ BjmyCLR2bF/+OaSFL47IhblKM8WFi1VZZjcmnauydpIkSZJ9RxqBcpNij1ME6m3kwIARzdw9 /IFCw4vagpXXTpIkSTJ0tK1A+zLPPL37ItCuFbUrkYkkSZJsvCPuCHd8ttWaXci8KALt7KpJ kiRJ9hxtR7iZpdWjU63W3GLixVQE6o2iaeV7zQ0rPL/88vGpVqL85eNTydILold5Dhn+2czG 58YClZawNJv9WG6Z2mvvH4rFmVbcdy48ShGJIFrJqJxWr7T8eqeOLSf/G57lxEpnlpL/rXbe t/BxHQVJkiSZdNQRKB0zUhFo9ehUsvobjoeHjYUAABL6SURBVHup2kaUSTu9Evq14aVUA9Ty 8amCGFClKWZptmirMhufK2ro2iu2AlVae/bQLcy19s3N7uuvcXGmVSdhLs2mcsXasX35mBGH k2gX0vt7vZdSopUmT02l817+8VsLc/kjP05NiyRJkhyto49AyQCQqK0WZZLFmVaiyWiIuYWL 00JyewpnqNtKBKodafJr30YEGnroFuayzT7FCbDYdMNdfzPy+5vYsML2vUQhvf9WPO9lHw8X 1uxDkiTJUschAvXruImKcvZeflD6YpmZynSm0jxwewa+mLEghBSFhOERKP3uNiLQ0ENXcCgG 58NKByof4QYVWHY6Kp73AWcz7gVXt2sfSZIkm+F4RKC4Cr7UqzcXpYh6jRUFKStTcR88Vqdg IwvdagQasvatR6Dhh277EaiQ3PZvIQJVPe9VAm3paSVJkmSTHZcIFNV9Z2d2rhUotfzSbEEz wtDJ6HYtAg1f+93VClS82GhagQoKlIJIkiTZc2wiUO/OfXIsUKX2jUFGNfv0RAjBrYIRIzs6 Fig/2CacQiDZJDVs7dXGtJSOBRp06LYVgSqeha1GoIrnvXoEyk6DQZIkyYY7RhEoSg7pGeEy g3lqT+21enQqM/tZovBew0Jm+rLMYv3kUNQHrzA8hAX26+iLM6nnwFZae2Z/l49PFdTjB8wI V37otheBcjPCBRWmQ8hZnmEqnffyj9ecBoMkSZJNc6wiUBgVduC5QAmjR+gUVJcTT7aZOrac fGBObjvjxaZm4nfTT+bpL5GeA63H7EJ2HudKa8/s/sJa5bUPPHTbjUDZvQt3cHV5LbfeHqlH Pw3Z8kEbP/TjS4sLBds26j8zkiRJjo8ji0AkSZIkeecVgUiSJEk2SBGIJEmSZIMUgUiSJEk2 SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMU gUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGI JEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZIMUgUiS JEk2SBGIJEmSZIMUgUiSJEk2SBGIJEmSZINsbgRaO7av1Wq1Wq2pY4O2OVxs8DIkSZIk7xab G4GCW9eDWwtzw+LN0myr1Wq1ZhdGvakkSZIkd0ARaLdaeNaO7Wu1ZpZGv48kSZIk+4pAIhBJ kiTZIEcVgZaPT7UKEsLiTKvVmltM/bdH7vV9x1f7Q3oKu6tF3dj67Du+mlygPAKVrbrC2nMr jZk6ula4lvzrJEmSJHfH0bUCrR6dykSLMDz08sDq0alkYlmcSQeYhbnWvrnZff3YsziTnrdg YS6TLgrWWKEVqGg7K6y9UitQnKA0FpEkSZJ3yBF2hFs+PpVpAFk+PjUgkCzMpaLIwly22Wf5 +FSmKSYdLXY4Ag1ae6AjHEmSJDmWjnQsUKZhJ9PskzUTVzKJ6HqQakTKBpK4/J2MQIOasEQg kiRJciwd7XQIqQSydmxfZlRMaqRN9hk+g0NIvpVGBCJJkiQ56hnhkjlhaTbfkSwz+CfbEU4r EEmSJMlajnpS7H7AyISKfIapFYGygSSI25TuWATKzd9AkiRJcvSOOgL1Gn8WZzJtJun5DBbm 6nWEi6JLP0SF/x34kbVjMwWJZcsRKDsl3fLxqVwiMik2SZIkeWcdfQTqP4En+1Sf8NlBrXja 6Pi/0WIVQkgce6ISBsztFj81aOrYQnar0sQfrxKBMoW3po4trKUjkEmxSZIkyTvsGESgW9cr dUjbvsURiCRJkmSDHI8INGQ67B3S4BySJEmy8Y5FBMrMBbdTLs0OfpQqSZIkycY5ygi0NNsb JbML8wGsHp2bSj1WaNc72pEkSZIce8eiFYgkSZIk74wiEEmSJMkGKQKRJEmSbJAiEEmSJMkG ObIItHZsX34WhMIXR2TvqaaDn1saLlZlmd14BGqVtZMkSZLsO9IIlJulbZwiUG8jBwaM1aNT rVaVxw0NL2oLVl47SZIkydDRtgLtyzwR9e6LQLtW1K5EJpIkSbLxjrgj3PH0Q1FFoN1YNUmS JMmeo+0IN7O0enSq1ZpbTLyYikC9UTT1nm1a2MsuuLV8fCr5GNbl41PJ0guiV3kOGf7ZzMbn xgKVltB/YmyGOlteeugWZ1px37nwKEUkgmglo3JavdLy6506tpz8b3iWEyudWUr+t9p538LH dRQkSZJk0lFHoHTMSEWg1aNTyepvOO6lahtRJu30SujXhpdSDVDLx6cKYkCVppil2aKtymx8 rqiha6/YClRp7dlDtzDX2jc3u6+/xsWZVp2EuTSbyhVrx/blY0YcTqJdSO/v9V5KiVaaPDWV znv5x28tzOWP/Dg1LZIkSXK0jj4CJQNAorZalEkWZ1qJJqMh5hYuTgvJ7SmcoW4rEah2pMmv fRsRaOihW5jLNvsUJ8Bi0w13/c3I729iwwrb9xKF9P5b8byXfTxcWLMPSZIkSx2HCNSv4yYq ytl7+UHpi2VmKtOZSvPA7Rn4YsaCEFIUEoZHoPS724hAQw9dwaEYnA8rHah8hBtUYNnpqHje B5zNuBdc3a59JEmSbIbjEYHiKvhSr95clCLqNVYUpKxMxX3wWJ2CjSx0qxFoyNq3HoGGH7rt R6BCctu/hQhU9bxXCbSlp5UkSZJNdlwiUFT3nZ3ZuVag1PJLswXNCEMno9u1CDR87XdXK1Dx YqNpBSooUAoiSZJkz7GJQL0798mxQJXaNwYZ1ezTEyEEtwpGjOzoWKD8YJtwCoFkk9SwtVcb 01I6FmjQodtWBKp4FrYagSqe9+oRKDsNBkmSJBvuGEWgKDmkZ4TLDOapPbXX6tGpzOxnicJ7 DQuZ6csyi/WTQ1EfvMLwEBbYr6MvzqSeA1tp7Zn9XT4+VVCPHzAjXPmh214Eys0IF1SYDiFn eYapdN7LP15zGgySJEk2zbGKQGFU2IHnAiWMHqFTUF1OPNlm6thy8oE5ue2MF5uaid9NP5mn v0R6DrQeswvZeZwrrT2z+wtrldc+8NBtNwJl9y7cwdXltdx6e6Qe/TRkywdt/NCPLy0uFGzb qP/MSJIkOT6OLAKRJEmS5J1XBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZ IEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1S BCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUg kiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJ kiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJkg1SBCJJkiTZIEUgkiRJ kg1yhyPQysrZmzeujnyvSJIkSTLvje6VlZWzOxmB1tffvrxxceQ7RpIkSZJ5Ny69v77+9k5G oKtXP/rtb1dv3bw28n0jSZIkyaS3bl777W9Xr179cCcjUBAEFy78aXX13OWNi3rEkSRJkhwH b3SvbFx6/7e/Xf3zn/9vxVxTIwIFQXD16pX19bdXVs4uAwAAAMCoWVk5u77+9tWrV6qHmnoR CAAAAADudkQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQg AAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIA AADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAA AA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQIEQgAAAAAA1CBAIAAADQ IEQgAAAAAA1CBAIAAADQIEQgAAAAAA2i9WcAAAAAaAxagQAAAAA0CBEIAAAAQIMQgQAAAAA0 CBEIAAAAQIMQgQAAAAA0CBEIAAAAQIMQgQAAAAA0CBEIAAAAQIMQgQAAAAA0CBEIAAAAQIMQ gQAAAAA0CBEIAAAAQIMQgQAAAAA0CBEIAAAAQIMQgQAAAAA0CBEIAAAAQIMQgQAAAAA0CBEI AAAAQIMQgQAAAAA0CBEIAAAAaARXr15dX19fWVlZ3iusrKysr69fvXq11nEQgQAAAIC9z8WL F1dXVzc2Nm7evDnqbdkxbty4sbGxsbq6euHCheqfEoEAAACAPc7Vq1dXV1c/++yz23uRmzdv rq6uXrlypeLREIEAAACAvczt27fX19cvXbp0a+9y6dKl9fX127dvVzkgIhAAAACwl9nc3FxZ Wel2u5t7l08//XRlZWVzc7PKARGBAAAAgL3M5ubm8vLyqEPKrhPuY5UDIgIBAAAAe5mbN28u Ly/f3OuE+1jlgIhAAAAAwF4mjAef7XVEIAAAAABBIALlEIEAAACAvUwYgW7sdUQgAAAAAEEQ R6DuXkcEAgAAABAEcQT6dK8jAgEAAAAIAhEohwgEAAAA7GXCCPTJXkcEAgAAABAEcQS6vtP8 +j9/udPpdDqdL//nX+944VtABAIAAAAQBHEE+nir/OhQJ8OhH3388ce/Orm4EvzkcKfTeeR7 r2+58B1EBAIAAAAQBNuJQFH6eeS5c73CfnK40+l840cff/zpZ599+vGPnxKBAAAAAIwXYQS6 VpdffufLnU6nc/gnwe2bn/ZevbF4uPPI9+LS/umpTqfzyHdfr134LiACAQAAAAiCOAJdrcnC 18MAdOtG+vUbi4cf+e7r0X/iCFS38N1ABAIAAAAQBHEEulKPf/xGp9PpHF7s5t7pbt6+eT36 98kwAv069cm/SY4b+pt/TL73i29/uezN1MfSn6qGCAQAAAAgCLYWgX7xDw93Op1HvvfG4MWy ESiMOId/Eq35J4c7nU7ny9/+RfjuP/5Nf2DRTw4nik9/7Nxzj2wlBYlAAAAAAIIgjkAf1eJH 3+h0Op2nfnx98GJxBIr++9LXO53O4Z9sdqP/dzfDOPP1lz766KOPXvpGp9N55LnfXP/oo48+ 6p557pG4+MzHrn+2dLjT6XzjpXqbLAIBAAAACII4An1Yi5NPdTqdzlMnqyz28Hd/Ff4vjDKL nyYW+Pg33wsz0IcffvjpYtgo9K3XPvzwww8//uzW5qf9jz3yvdezxc6/VmuTRSAAAAAAQbC1 CPT69x6pkkJSEei1+YfzsSmcNzt88dPNsGdcp9N56FuvpQvJ00tWFRGBAAAAAARBHIEu1+La j5/qdDqdbywMXiyKQL+8fPny5cu//G4YgYoWmT99+fLly5c/3QziEUKdTuev/9vly5cvn55/ ODl+qMetz67V2mQRCAAAAEAQxBFoox5Rr7Wv/7fcO6e/9dBfx6+G+eYffrmxsbGxET4l6OH5 06mlw6ahf7qWKHoznvLg4W+dLvnYFhCBAAAAAATBFiPQxqdnnnskbKpJv376Ow/380oqAm1E vee+czq9dKdzePHTjY2N09966KFvRe9du7F4uNPpfGNho5e2DuXTVi1EIAAAAABBEEegS3W5 euNW3GXtr3/Ye/Xn33m403n4H34Z/u+/RxEo/sTZKDZFy//8P4WTXd/85NKlS5cWvtHpPPyd nyff+fEnly5duvTJzXBFD/2nn/fX88Mf9v9TCREIAAAAQBDEEeiDLfDJzSAxdKfH4cUbVz74 4MW/Srz0Vy9+8MEHH3xw5cat9PIPP3cuuPnJBx988MEHr84/3Cl+54MPPrkZdY3r8eWv//df 1NtYEQgAAABAEMQR6F+3yvVcrLh5Pfd6+FJ++Vs3rsSvX7lxKyh+p/Dtm9fT7w9FBAIAAAAQ BNuOQHcLIhAAAACAIIgj0P/b64hAAAAAAIIgjkAX9zoiEAAAAIAgiCPQ+3sdEQgAAABAEMQR 6MJeRwQCAAAAEAQiUA4RCAAAANjLhBHoz3sdEQgAAABAEMQR6E97HREIAAAAQBCIQDlEIAAA AGAvc/PmzTNnzpw/f/7/7l3ee++9M2fOiEAAAAAAgs3NzTfffHN9ff2Pe5d33nnnzTff3Nzc rHJARCAAAABgL7O5uXnx4sWzZ8+eP39+1FFlVzh//vzZs2fff/99EQgAAABAcPv27W63+4c/ /OHs2bPvvPPOu+++e36v8O67777zzjtnz579wx/+0O12b9++XeWAiEAAAADAHmdzc/OTTz65 dOnS+vr6ysrK8l5hZWVlfX390qVLn3zyScUmoEAEAgAAAJrArVu3ut3uxx9/fOXKlY/2Cleu XPn444+73e6tW7eqHwoRCAAAAGgEt2/f3tzcvLm32NzcrNj/rYcIBAAAAKBBiEAAAAAAGoQI BAAAAKBBiEAAAAAAGoQIBAAAAKBBiEAAAAAAGsT/B3LMhVHADumfAAAAAElFTkSuQmCC --------------C2B26408A63E0D6A1786F388-- --------------E737A63CC558EEB1C41F0D80-- From nobody Fri Jun 16 17:01:11 2017 Return-Path: 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 5A0FD129536 for ; Fri, 16 Jun 2017 17:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 24Y6xCtNlL5F for ; Fri, 16 Jun 2017 17:01:07 -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 5465E128B51 for ; Fri, 16 Jun 2017 17:01:07 -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 79A8658C4B2; Sat, 17 Jun 2017 02:01:02 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 60E6DB0C2E0; Sat, 17 Jun 2017 02:01:02 +0200 (CEST) Date: Sat, 17 Jun 2017 02:01:02 +0200 From: Toerless Eckert To: Michael Richardson Cc: Anima WG Message-ID: <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2540.1497281932@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 00:01:10 -0000 On Mon, Jun 12, 2017 at 11:38:52AM -0400, Michael Richardson wrote: [reordering] > So, let's leave this part, which is > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1 1. I think those sections are incorrect wrt to the GRASP format. Here is whats in BRSKI -06: proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number ] ] ipv6-address - the v6 LL of the proxy transport-proto - 6, for TCP 17 for UDP port-number - the TCP or UDP port number to find the proxy The definition of M_FLOOD from grasp-13 is: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = [objective-name, objective-flags, loop-count, ?objective-value] objective-name = text ;see section "Format of Objective Options" objective-value = any This means that we do not need to have a locator in the proxy objective because the flood message already has the locator element outside the objective. The second problem with -06 is that we need to be able to indicate different protocol stacks, eg: TLS or (later) CoAP. In draft-carpenter-anima-ani-objectives, the proposal for the proxy-objective was therefore: assistant-objective = ["AN_join_assistant", F_SYNCH, 1, method] eg: ["AN_join_assistant", F_SYNCH, 1, "BRSKI-TLS"] Aka: The objective needs F_SYNCH, that standard objective parameter, the second parameter is also mandatory loop-count (must be 1 for DULL) and then "BRSKI-TLS" would be the value of the proposed "method" parameter. This is what i did put into the proposed -07 diffs that we are reviewing. > {note subject line change} > > Brian E Carpenter wrote: > >> 3.1.1. Proxy Discovery Protocol Details > >> > >> The proxy uses the GRASP M_FLOOD mechanism to announce itself. This > >> announcement is done with the same message as the ACP announcement > >> detailed in [I-D.ietf-anima-autonomic-control-plane]. > > bc> Can we make it: > > bc> This announcement SHOULD be done with the same message... > bc> That's only an optimisation, really. > > Agreed. I think we all agree that the announcement of the proxy > (and the search for ACP peers) is something that M_FLOOD is good for. > > > bc> (After the discussion back in Berlin, we added a feature to > bc> M_FLOOD to allow arbitrary locators to be attached to a given > bc> flood message. I thought that was what the BRSKI team wanted > bc> at that time. Seems not.) > > yes, we asked for two locators to be attached to a flood message so that we > could announce ACP and Proxy in the same message. Given the experience > with rate limiting that you experienced, this seems doubly prudent since > this M_FLOOD will occur outside any ACP, and will have to traverse any > number of layer-2 devices. > > (This will be worse at the beginning of ANIMA deployment, as the layer-2 > devices will not be ACP aware, but will get better as more devices get with > the program...) 2. If we send the M_FLOOD for BRSKI and ACP periodicially once every 30 seconds, i don't think that we should be worried about sending one instead of two packets. >From grasp-13 it seems that i can only put a single grasp-message into a single UDP packets. And i can only put a single objective into a single grasp-message. I don't think i want a single objective to announce both ACP and BRSKI. Those are features of two different ASA. How would i implement this. > As there is no dispute about it, I think. > If it should be named AN_PROXY, that's fine. i have no strong opinion about the term, you pick ;-). Cheers Toerless > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Jun 16 18:01:36 2017 Return-Path: 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 BFB08129432 for ; Fri, 16 Jun 2017 18:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fFh-xLz7zdyr for ; Fri, 16 Jun 2017 18:01:33 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 6557C120454 for ; Fri, 16 Jun 2017 18:01:33 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id l89so29313395pfi.2 for ; Fri, 16 Jun 2017 18:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AnMzESSZre29jAh3hnquumaeknO8yoz6TxbbTPrYzAw=; b=sy34dmUNlGE0ayEyiWvFjV/H7VUVXNXVVlalt9jstgJLHVh6wRJGmChD/Hmp+xqPkN dUh2Iy3Jd5VuiCU2jOmIQYmujvSznsJSWMaJAkGdVqW3lglA9sLJ2e9RWDY71v3iF256 f49eVmW3uncgTf0vSAeGcTIrNYOOJEw98ZzENTbMjDJS/wWvMm+Z/Y8DJIiNPY3acENL di27NAbzv7W6y/+kAJMLsyPRh3QSKvlA8g0fbxlngsG/p+R7FaQdanIzhyXRaq9l6BsW 2DxaWWIU6CxNnKPWnK0d7TL0aJyrUWrLqNUu/JbMvngowTMobynFr1u+gCeKaihVL3Ed qrOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=AnMzESSZre29jAh3hnquumaeknO8yoz6TxbbTPrYzAw=; b=ZC7N2sJRo6oNL8+pLT8em/iwoO3KxKESCOaCujs5TN4MN1E6WRnY2OIwqS9G781wNY 0mh/ZA0kheOhuuTtmY//siF+edPq3q5qW1/jC6fXXrWHGRIpBvt11FIocH9ilv9xaobK NZ6V40lm/Tc7MN3XKss5whCvAJhweFzjKhBXw+o7U8pU9lDpuNu+O7UcMQkdy7uYWZgT QitQS68ZCfW9QjTyflCr6e5OwTKFUD1wEMxWxxxxFcnHSxd5i4s939dC7O8v1r/7uYzg RLSqds+wKifuaXTb/vHfRsc/4MjZWmihLVKnEPzipiggqWk2M1AMMeNOa9MKKUtOS2BN 2IlQ== X-Gm-Message-State: AKS2vOyBXtOyO8Oxcne0jxpvkLjYJS2iT9yiM+ljKK/ngMcMk/HT/Q7r q5jRpXLWid74HS/O X-Received: by 10.98.166.196 with SMTP id r65mr13933978pfl.120.1497661292411; Fri, 16 Jun 2017 18:01:32 -0700 (PDT) Received: from ?IPv6:2406:e007:53e7:1:28cc:dc4c:9703:6781? ([2406:e007:53e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r5sm6726466pgu.5.2017.06.16.18.01.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 18:01:31 -0700 (PDT) To: anima@ietf.org References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 17 Jun 2017 13:01:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 01:01:36 -0000 If the BRSKI team agree that you want a flood (i.e. unsolicited announcement) for pledge<->proxy and discovery+synchronization request (i.e. solicited announcement) for proxy<->registrar, I will suggest complete text for these, and implement a Python demo version. So, BRSKIsts please confirm what you want. Regards Brian On 17/06/2017 12:01, Toerless Eckert wrote: > On Mon, Jun 12, 2017 at 11:38:52AM -0400, Michael Richardson wrote: > [reordering] >> So, let's leave this part, which is >> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-06#section-3.1.1 > > 1. I think those sections are incorrect wrt to the GRASP format. Here is whats in BRSKI -06: > > proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, > transport-proto, port-number ] ] > > ipv6-address - the v6 LL of the proxy > transport-proto - 6, for TCP 17 for UDP > port-number - the TCP or UDP port number to find the proxy > > The definition of M_FLOOD from grasp-13 is: > > flood-message = [M_FLOOD, session-id, initiator, ttl, > +[objective, (locator-option / [])]] > > objective = [objective-name, objective-flags, loop-count, ?objective-value] > objective-name = text ;see section "Format of Objective Options" > objective-value = any > > This means that we do not need to have a locator in the proxy objective because > the flood message already has the locator element outside the objective. > > The second problem with -06 is that we need to be able to indicate different protocol > stacks, eg: TLS or (later) CoAP. > > In draft-carpenter-anima-ani-objectives, the proposal for the proxy-objective was therefore: > > assistant-objective = ["AN_join_assistant", F_SYNCH, 1, method] > > eg: > ["AN_join_assistant", F_SYNCH, 1, "BRSKI-TLS"] > > Aka: The objective needs F_SYNCH, that standard objective parameter, the second parameter > is also mandatory loop-count (must be 1 for DULL) and then "BRSKI-TLS" would be the value of > the proposed "method" parameter. > > This is what i did put into the proposed -07 diffs that we are reviewing. > >> {note subject line change} >> >> Brian E Carpenter wrote: >> >> 3.1.1. Proxy Discovery Protocol Details >> >> >> >> The proxy uses the GRASP M_FLOOD mechanism to announce itself. This >> >> announcement is done with the same message as the ACP announcement >> >> detailed in [I-D.ietf-anima-autonomic-control-plane]. >> >> bc> Can we make it: >> >> bc> This announcement SHOULD be done with the same message... >> bc> That's only an optimisation, really. >> >> Agreed. I think we all agree that the announcement of the proxy >> (and the search for ACP peers) is something that M_FLOOD is good for. >> >> >> bc> (After the discussion back in Berlin, we added a feature to >> bc> M_FLOOD to allow arbitrary locators to be attached to a given >> bc> flood message. I thought that was what the BRSKI team wanted >> bc> at that time. Seems not.) >> >> yes, we asked for two locators to be attached to a flood message so that we >> could announce ACP and Proxy in the same message. Given the experience >> with rate limiting that you experienced, this seems doubly prudent since >> this M_FLOOD will occur outside any ACP, and will have to traverse any >> number of layer-2 devices. >> >> (This will be worse at the beginning of ANIMA deployment, as the layer-2 >> devices will not be ACP aware, but will get better as more devices get with >> the program...) > > 2. If we send the M_FLOOD for BRSKI and ACP periodicially once every 30 seconds, > i don't think that we should be worried about sending one instead of two packets. > >>From grasp-13 it seems that i can only put a single grasp-message into a single > UDP packets. And i can only put a single objective into a single grasp-message. > > I don't think i want a single objective to announce both ACP and BRSKI. Those > are features of two different ASA. How would i implement this. > > >> As there is no dispute about it, I think. >> If it should be named AN_PROXY, that's fine. > > i have no strong opinion about the term, you pick ;-). > > Cheers > Toerless >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > > >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > From nobody Sat Jun 17 11:05:50 2017 Return-Path: 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 C264112957F for ; Sat, 17 Jun 2017 11:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Uv7dkyZ14PV6 for ; Sat, 17 Jun 2017 11:05:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A1212957C for ; Sat, 17 Jun 2017 11:05:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 185E9203B0; Sat, 17 Jun 2017 14:07:09 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4CA596380F; Sat, 17 Jun 2017 14:05:46 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 18:05:50 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > If the BRSKI team agree that you want a flood (i.e. unsolicited announcement) > for pledge<->proxy and discovery+synchronization request (i.e. solicited > announcement) for proxy<->registrar, I will suggest complete text for these, > and implement a Python demo version. We want (LL) M_FLOOD for pledge<->proxy, and M_DISCOVERY for proxy<->registrar. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllFb3kACgkQgItw+93Q 3WWWYwf9H9zLHT7kjDuB4bZbGMqojKThnxy0u8VM6pE7kF4d2oMgcNNLo0Xk97Cn JgzjRYgJ98a5H3+UQ8GFgopYYXSZjQqAbiyJK1Fd7uiOaOpUkOl04uw75XDXDitK Nzvx52DQlbWbP2JL2KCa8blFLVXMWQOhwtIctuaccpvsGcmu8HBJBReqnNmDyLuU svJeoG7S1pyCnY/tbyQZKj3LKPb2yfrLrQa4Uobc+k0CcnsNTe+oHqR6lSZEdWuu MzGK90JpG1geaLSmlaylt+hUQkcINRBRDZidI4pJTuMTsJEmeK0X422KXRklUFm5 fTlxgr6fqEVWYtreipfkQTzH4xGRcA== =rnIS -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 18 09:58:58 2017 Return-Path: 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 CF2FF12949E for ; Sun, 18 Jun 2017 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 6vE4emTF_nKF for ; Sun, 18 Jun 2017 09:58:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42A2129482 for ; Sun, 18 Jun 2017 09:58:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 72B5A4A002; Sun, 18 Jun 2017 13:00:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 83A096380F; Sun, 18 Jun 2017 12:58:53 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: Anima WG In-Reply-To: <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 16:58:57 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > 2. If we send the M_FLOOD for BRSKI and ACP periodicially once every 30 seconds, > i don't think that we should be worried about sending one instead of two packets. > From grasp-13 it seems that i can only put a single grasp-message into a single > UDP packets. And i can only put a single objective into a single grasp-message. Because we can announce multiple objectives. > I don't think i want a single objective to announce both ACP and BRSKI. Those > are features of two different ASA. How would i implement this. It would be a feature of the single, unpriviledged DULL instance. That instance would be configured by some larger intent. If a node doesn't want to announce itself as a proxy, it would omit that objective. As for implementation, I've done it. It's a question of about a page of C code (given a cbor library), or about ten lines of ruby. Probably a similar number of lines of python. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllGsUwACgkQgItw+93Q 3WWUkAgAtlri8NChax8S6LrKeAwwfCH9OKKn9i5aII87PMFGfn+OuPOBJXXHitUk XIPDuQeBYSs7wH3ND1RF8vVTfv+9mlJfptj+P51yH6DWBdzH/GuM99Egb76U3B7L CT0d4TL9nmIpyHWbKUEskqZAl/Lsw/Q8hpPdy8wbD0Myxq5lwvFlGGm4rA0CqJ+w SuLjGYWwuPMVYAtHjgt3ZmBm81teladJKTXxlZW2yxZUa6WG09lwtH+hqEFy6742 LJWAovSV98zAUXSH8o6Zv/56uQEdZP9qMy94wAM6v16dOLNvpvdLZLm0OyfuXXkh JA7j7tR4NLMDinGvCH59FCUMtU8YVQ== =NUNw -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 18 12:53:27 2017 Return-Path: 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 07024127137 for ; Sun, 18 Jun 2017 12:53:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 AJFoCwt2HB4n for ; Sun, 18 Jun 2017 12:53:24 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 7E612126BFD for ; Sun, 18 Jun 2017 12:53:24 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id f185so39641595pgc.0 for ; Sun, 18 Jun 2017 12:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NmDeouUqfaRzI9i3irTYglPTCLuhaW1XvFT+lhS9g3Y=; b=ZimwpDa+d01RUNmzjO1Nr2sRRmDW+qCXmmuOkRW0zXGlJG7TFPsmvTDd+ZlbdKZDgF uiK3Tk+YnGIvZPN8aSzL4PBTWtPAJH893fnxXw75WMR9ugZqoPTN72R1baOHXPjRT+9D RXtBLGix+o5yuujuLUSvhk5PWAoLff+JNvHvHsIg1aOVb6TTFYnf42ckMKGseM1JuOdn 0py8pm8negX61y1Yvk3V3lw8CO9QExbBYREzBOHd8ddf2R1QFVODRxe0v4uE+TNxfU++ pSYjifBKOlE0tNN1jGLztWyHpJ64eze0AqUgnRSwxw6UmBjOnbkDG9i/fXRDTogexeO6 sUng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=NmDeouUqfaRzI9i3irTYglPTCLuhaW1XvFT+lhS9g3Y=; b=P1N7rP0/9bIJiAdrgTeGzB4UsffYgfn8I92x5lhTwjnETHk0N8Mdi6VyiEru39ip22 w5/usBucll+/RUaA8Z/Ow8DKPrXf3wCGIikhFF89ZHbjmjl5rnEyM21E5MxX47T+Onam qEiiPYG3cJ5RFZ9bIDqIOHoWLYkT+vNMwFZzqLFEdV18mVnv71Hnoj7QqS5TCQknmKid VYvHFu2NCw6LC5fFPVNgWlwE1AW572Uw4bJHC+eDWCuxVY4aZ69wxqIskLbZ5FUFquJ9 otnZ5GZHTNNRxiLrU5aKNB9+IRB2cwW5X9sxWXa92+aMt+U/Gf+9sKmuFVuXieTdr5ad JbKA== X-Gm-Message-State: AKS2vOz6K/X7EUC1CXvXE9D9uyXk+SlNmD0LaUpEpC20fyHq2xGgSPqp 2V4CLEKPP8FPtGVd X-Received: by 10.84.224.200 with SMTP id k8mr18288560pln.215.1497815603924; Sun, 18 Jun 2017 12:53:23 -0700 (PDT) Received: from [10.100.109.213] (125-236-219-163.adsl.xtra.co.nz. [125.236.219.163]) by smtp.gmail.com with ESMTPSA id g86sm16421326pfk.101.2017.06.18.12.53.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jun 2017 12:53:22 -0700 (PDT) To: anima@ietf.org References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> <28650.1497805133@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1dc4daff-5e31-c918-0db4-071f43f3ef9d@gmail.com> Date: Mon, 19 Jun 2017 07:53:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <28650.1497805133@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 19:53:26 -0000 On 19/06/2017 04:58, Michael Richardson wrote: > > Toerless Eckert wrote: > > 2. If we send the M_FLOOD for BRSKI and ACP periodicially once every 30 seconds, > > i don't think that we should be worried about sending one instead of two packets. > > > From grasp-13 it seems that i can only put a single grasp-message into a single > > UDP packets. And i can only put a single objective into a single grasp-message. > > Because we can announce multiple objectives. > > > I don't think i want a single objective to announce both ACP and BRSKI. Those > > are features of two different ASA. How would i implement this. > > It would be a feature of the single, unpriviledged DULL instance. > That instance would be configured by some larger intent. > > If a node doesn't want to announce itself as a proxy, it would omit that > objective. > > As for implementation, I've done it. It's a question of about a page of C > code (given a cbor library), or about ten lines of ruby. Probably a similar > number of lines of python. I'm thinking that if we want to make a tiny extension to GRASP syntax for this special purpose, we can do so in the BRSKI document. That's yet another benefit of using CBOR. Brian From nobody Mon Jun 19 06:36:10 2017 Return-Path: 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 C275B1300EF for ; Mon, 19 Jun 2017 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Fm7vTgxV1S0i for ; Mon, 19 Jun 2017 06:36:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F8C129534 for ; Mon, 19 Jun 2017 06:36:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C5AA4A016; Mon, 19 Jun 2017 09:37:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A91FB6380F; Mon, 19 Jun 2017 09:36:04 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: <1dc4daff-5e31-c918-0db4-071f43f3ef9d@gmail.com> References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> <28650.1497805133@obiwan.sandelman.ca> <1dc4daff-5e31-c918-0db4-071f43f3ef9d@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 13:36:09 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> If a node doesn't want to announce itself as a proxy, it would omit that >> objective. >> >> As for implementation, I've done it. It's a question of about a page >> of C >> code (given a cbor library), or about ten lines of ruby. Probably a >> similar >> number of lines of python. > I'm thinking that if we want to make a tiny extension to GRASP syntax for > this special purpose, we can do so in the BRSKI document. That's yet > another benefit of using CBOR. flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] You added the +[] there so that we can announce multiple objectives. I don't think that there is anything more to do in GRASP. All we need to do is define the AN_Proxy objective, and ACP has to define the AN_ACP objective. I just don't see any problem here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllH00QACgkQgItw+93Q 3WVgSggAoAjCG3STMbVKb0ZKrtQGkIkTgzaE5ueEv/B9X9ZjwN+mhAEWhXo/iYSo 7COPBBaKdhjzL+3oyvxx4TrhOpoh/ILTgHUxT+TVcDraOnnLi1DxtcjLG1bGqftz ZbFlhnnlc+WWoRWaImSycnBCsNkR74Vr/jF79V/p5V4bAt48si6tcAT8FcliHP+N XdKAD4k+Qv8i5Hr17BhvELgo9JkDDKu3tty65tGKLpBUygDGpI+BBO0uc5/E+gC2 I0+7yiFq4CqB4Y1fKv308UxKp9SGyW4KwAjS3JAuRrYZ2TggNm+IjwrwJC+9oa/z c2uy0f6kNhzQlXiSBpOjsqDWDU/Vyw== =AaVU -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 19 23:19:24 2017 Return-Path: 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 603DD128AB0; Mon, 19 Jun 2017 23:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 PvlK_XFS9etB; Mon, 19 Jun 2017 23:19:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B8E126DFB; Mon, 19 Jun 2017 23:19:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPL62917; Tue, 20 Jun 2017 06:19:15 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Jun 2017 07:19:13 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 20 Jun 2017 14:19:10 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 99, Prague, Czech Thread-Index: AdLpjR8SHNpbW+orSv69eQY2Izt4Vw== Date: Tue, 20 Jun 2017 06:19:09 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDE5B2B@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5B2BNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5948BE63.012D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 61f649b3d0f14551050725b6328d66ad Archived-At: Subject: [Anima] Call for agenda ANIMA @ IETF 99, Prague, Czech X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 06:19:21 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5B2BNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have requested two sessions of 2.5-hour for the ANIMA WG meeting for IET= F-99 (Prague, Czech) and are starting to collect agenda items for the sessi= on. Please send your request for agenda by June 29th, Thursday. Giving that most of our chartered work items have been matured or closed to= be matured, we expect shorter present time slots for them. So different wi= th previous IETF meetings, we only have one session. However, as usual, the= chartered work item would still have priority. We will only discuss non-ch= arter work items till we finish charter work items. As normal, the priority= among these non-charter work items would be: these that have active discus= sion in mail list, then these have submitted drafts, and topics without dra= fts. Since we have been discussed potential future work items for many past= IETF meetings, the ANIMA chairs would give an abstract presentation for po= tential work items. Please send us (anima-chairs at ietf.org) requests for ti= me slot by June 29th, Thursday and include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): Brief description of what issues need discussing and what you hope to accomplish by presenting (please focus on open issues, rather than a status update): More details about the IETF 99, Prague, Czech can be found at: http://www.ietf.org/meeting/99/index.html Again, presenters and draft authors please invoke active discussions in the= ANIMA list. We have very limited time for each topic in the face-to-face m= eeting. Mail list is a very good place to discuss and reach consensus on te= chnical issues. Best regards, Toerless & Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5B2BNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all anima,
 
We have requested two sessions of 2.5-hour for the ANIMA WG me=
eting for IETF-99 (Prague, Czech) and are starting to collect agenda items =
for the session. Please send your request for agenda by June 29th, Thursday=
.
 
Giving that most of our chartered work items have been matured=
 or closed to be matured, we expect shorter present time slots for them. So=
 different with previous IETF meetings, we only have one session. However, =
as usual, the chartered work item would still have priority. We will only d=
iscuss non-charter work items till we finish charter work items. As normal,=
 the priority among these non-charter work items would be: these that have =
active discussion in mail list, then these have submitted drafts, and topic=
s without drafts. Since we have been discussed potential future work items =
for many past IETF meetings, the ANIMA chairs would give an abstract presen=
tation for potential work items.
 
Please send us (anima-chairs at <=
span style=3D"color:#337AB7">ietf.org) requests for time slot by=
 June 29th, Thursday and include:
Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
Brief description of what issues need discussing and what you =
hope to
accomplish by presenting (please focus on open issues, rather =
than a
status update):
 
More details about the IETF 99, Prague, Czech can be found at:=

<=
a href=3D"http://www.ietf.org/meeting/99/index.html">http://www.ietf.org/me=
eting/99/index.html
 
Again, presenters and draft authors please invoke active discu=
ssions in the ANIMA list. We have very limited time for each topic in the f=
ace-to-face meeting. Mail list is a very good place to discuss and reach co=
nsensus on technical issues.
 
Best regards,
 
Toerless & Sheng

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5B2BNKGEML515MBXchi_-- From nobody Tue Jun 20 01:00:58 2017 Return-Path: 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 631F91287A3; Tue, 20 Jun 2017 01:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 85wNP7rq7dJU; Tue, 20 Jun 2017 01:00:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F4D13163E; Tue, 20 Jun 2017 01:00:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIV59657; Tue, 20 Jun 2017 08:00:40 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 20 Jun 2017 09:00:38 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 20 Jun 2017 16:00:34 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Review of draft-ietf-anima-stable-connectivity-02 Thread-Index: AdLpmz27hzNx1om7RNeFQD3MAwJWUA== Date: Tue, 20 Jun 2017 08:00:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5CCFNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5948D628.0160, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c78e1aacbb263a3c9f5a440d36e45b4a Archived-At: Subject: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 08:00:56 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5CCFNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors of draft-ietf-anima-stable-connectivity, I am doing a thorough review as the document shepherd with my ANIMA chair h= at on. Please address the below comments so that we could process this docu= ment further. First, I have issues for section 2.1.4, "IPv4 only NOC application devices"= . It would be an unlike scenario to manage an IPv6 network (all managed dev= ices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore,= the NAT64 setup in this scenario is complex, and connectivity between IPv4= only NOC application devices and NAT is unsecure. I would suggest to reduc= e the whole section or add a clear statement that it is a not-recommended s= cenario at the end of this section. Secondly, the description and category in section 2.1.2, "Limitations and e= nhancement overview". For me, only the point 1 & 3 are really limitation of= ACP itself. Point 2 is a precondition (it is actually conflicted with sect= ion 2.1.4.) I don't understand point 4. What does "exposing the ACP nativel= y" mean? Thirdly, I have issues to use names to distinguish the path selection polic= ies. This is a chicken&egg issue in the autonomic scenario. Who and how the= DNS names are setup, by human administrator? If there is a mechanism to di= stinguish the IP addresses of ACP and data-plane without human intelligence= , why does it bore to use DNS? DNS registration & lookup by itself is a ver= y complex and time-consumption procedure. If we don't want to show the sema= ntic of these addresses to any human, names are meaningless. In section 2.2, "The ACP can provide common direct-neighbor discovery and c= apability negotiation". This is a wrong statement. ANI does provide this, b= ut it is done by GRASP, not ACP. At the end of section 2.1.3, "A simple short-term workaround could be a phy= sical external loopback cable into two ports of ANrtr1 to connect the data-= plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL= external loopback CABLE"? It sounds like a very strong requirement. Person= ally, I believe this could be done by a virtual loopback interface. Section 3, "Security considerations" is more like a deployment consideratio= ns. Both ULA-C and reverse DNS are additional deployment Minor comments, Section 2.1.6, "Autonomic NOC device/applications" should be moved to early= part of this document. For me, it is the default scenario/requirement. It = should be section 2.1.1, I guess. It is worth of mentioning even the ACP provides only IPv6 connectivity, thr= ough it, IPv4 configuration or even non-IP configuration could be managed. The document does not properly quota references in the text. The references= defined are mostly not used. The document separate sections for Informative/Normative References The empty section 5 "Further considerations", should be removed. Most of references are out of date. behringer-anima-reference-model > ietf-= anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-auto= nomic-network-definitions > RFC 7575. In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the in= frastructure design." What is the mean for "other mayor"? In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may = be better to presented as "the Autonomic Control plane (ACP) in Autonomic N= etworks" There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT"= in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in = section 2.1.5, "KARP" in section 2.2, even the first appearances. Last sentence of section 2.2 should be removed. In section 3, first sentence, add "In this section," There are typos, needed to be fixed too: Two "the the" in the end of section 2.1.2 and end of section 4; A couple of "randomn" -> "random"; "networ" in section 2.1.5; "jut" -> "just" at the end of section 2.1.6, I guess. "The most simple" -> "the simplest" in section 2.17. --_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5CCFNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors of draft-ietf-anima-stable-conn= ectivity,

 

I am doing a thorough review as the documen= t shepherd with my ANIMA chair hat on. Please address the below comments so= that we could process this document further.

 

First, I have= issues for section 2.1.4, “IPv4 only NOC application devices”.= It would be an unlike scenario to manage an IPv6 network (all managed devi= ces are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the= NAT64 setup in this scenario is complex, and connectivity between IPv4 onl= y NOC application devices and NAT is unsecure. I would suggest to reduce th= e whole section or add a clear statement that it is a not-recommended scenario at the end of this section.

 

Secondly, the= description and category in section 2.1.2, “Limitations and enhancem= ent overview”. For me, only the point 1 & 3 are really limitation of ACP itself. Point 2 is a precondition (it is actually conflicted with s= ection 2.1.4.) I don’t understand point 4. What does “exposing = the ACP natively” mean?

 

Thirdly, I hav= e issues to use names to distinguish the path selection policies. This is a= chicken&egg issue in the autonomic scenario. Who and how the DNS names are setup, by human administrator? If there is a mechanism to di= stinguish the IP addresses of ACP and data-plane without human intelligence= , why does it bore to use DNS? DNS registration & lookup by itself is a= very complex and time-consumption procedure. If we don’t want to show the semantic of these addresses to any huma= n, names are meaningless.

 

In section 2.2= , “The ACP can provide common direct-neighbor discovery and capabilit= y negotiation”. This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP.

 

At the end of= section 2.1.3, “A simple short-term workaround could be a physical e= xternal loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture.” Does this has to be “a P= HYSICAL external loopback CABLE”? It sounds like a very strong requir= ement. Personally, I believe this could be done by a virtual loopback inter= face.

 

Section 3, &#= 8220;Security considerations” is more like a deployment consideration= s. Both ULA-C and reverse DNS are additional deployment

 

Minor comments,

 

Section 2.1.6= , “Autonomic NOC device/applications” should be moved to early = part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess.

 

It is worth o= f mentioning even the ACP provides only IPv6 connectivity, through it, IPv4= configuration or even non-IP configuration could be managed.

 

The document = does not properly quota references in the text. The references defined are = mostly not used.

 

The document = separate sections for Informative/Normative References

 

The empty sec= tion 5 “Further considerations”, should be removed.<= /span>

 

Most of refer= ences are out of date. behringer-anima-reference-model > ietf-anima-refe= rence-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-n= etwork-definitions > RFC 7575.

 

In section 1.= 1, “the introduction of IPv6 or other mayor re-hauls in the infrastru= cture design.” What is the mean for “other mayor”?

 

In section 1.= 3, “the Autonomic Networks Autonomic Control plane (ACP)” may be better to presented as “the Autonomic C= ontrol plane (ACP) in Autonomic Networks”

 

There is no f= ull names for “NOC” in section 1.1, “PSTN” in secti= on 1.3, AT” in section 2.1, “DNS” in section 2.1.1, ̶= 0;RoI” in section 2.1.4, MP-TCP in section 2.1.5, “KARP” in section 2.2, even the first appearanc= es.

 

Last sentence= of section 2.2 should be removed.

 

In section 3,= first sentence, add “In this section,”

 

There are typos, needed to be fixed too:

 

Two “th= e the” in the end of section 2.1.2 and end of section 4;

 

A couple of &= #8220;randomn” -> “random”;

 

“networ= ” in section 2.1.5;

 

“jut= 221; -> “just” at the end of section 2.1.6, I guess.

 

“The mo= st simple” -> “the simplest” in section 2.17.

--_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5CCFNKGEML515MBXchi_-- From nobody Tue Jun 20 07:15:34 2017 Return-Path: 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 E4B4512ECA7 for ; Tue, 20 Jun 2017 07:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 2H3e2g5klX_F for ; Tue, 20 Jun 2017 07:15:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D42512ECB2 for ; Tue, 20 Jun 2017 07:14:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40375200A5 for ; Tue, 20 Jun 2017 10:16:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EDADF6380F for ; Tue, 20 Jun 2017 10:14:58 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] minor clarifications to voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:15:23 -0000 --=-=-= Content-Type: text/plain Based upon discussion last week about synchronizing the voucher document with the BRSKI MASA protocol the following clarification was made to the voucher document as part of the WGLC: - signed using a PKCS#7 structure. The voucher artifact is generated by - the pledge's manufacture or delegate (i.e. the MASA). + signed using a PKCS#7 structure. The voucher artifact is normally generated by + the pledge's manufacture or delegate (i.e. the Manufacturer Authorized Signing + Authority). A voucher artifact could be signed by a non-MASA and be compliant + to the specified artifact format described in this document. The appropriate + use and trust of such vouchers is out-of-scope of this document. + This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. @@ -75,7 +79,8 @@ This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer - or delegate (i.e. the MASA). This artifact is known as the voucher. + or delegate, i.e. the Manufacturer Authorized Signing + Authority (MASA). This artifact is known as the voucher. The voucher artifact is a JSON document, conforming to a data model described by YANG , that has been signed using @@ -265,7 +270,7 @@ NOTE: All voucher types include a 'Pledge ID serial number'
- The voucher's purpose is to securely assign a pledge to an owner. + The voucher's primary purpose is to securely assign a pledge to an owner. The voucher informs the pledge which entity it should consider to be its owner. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllJLeIACgkQgItw+93Q 3WW2xAf9FVOKuGiPykYv3blQe308Vw53Ohp3gj38qHbyyB8CEXjF+o5d3lY/waHM OXLdpwavYbmxpzJOqQ44v6y+q/JpehQfazuVA9GWpGWIjwqGNYNKGwyZYvyu7atc IGX2tGQlKklifm2MZ0HWEPhPiOhc8GB6bP1MBm1j5/KjGx36I6iDZ2vowI5BlW8T 8ZhdLEqHjUaL8779GRooQoGz8YzCQouJMuH2WwGyj3OoiEYU4g+wO5XKIisDknoG Cc2VXWAYJygRazKgzuc/KNbmoUYH4qb8v2lZLL7az4A6I65UZD1riVmaiiETTTdI uUPsCvxcMs3mAnHcLbYfN9Pnea/6xw== =iu3e -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 20 07:31:43 2017 Return-Path: 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 5D71D12ECC1 for ; Tue, 20 Jun 2017 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] 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 yyrRH2UGEozP for ; Tue, 20 Jun 2017 07:31:39 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id B3CDD12ECAF for ; Tue, 20 Jun 2017 07:31:39 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id v5KEVbjo019596 for ; Tue, 20 Jun 2017 10:31:38 -0400 To: anima@ietf.org References: <32669.1497968098@obiwan.sandelman.ca> From: William Atwood Organization: Concordia University, Montreal Message-ID: <6dbe94ef-ee07-5faf-d761-771c19c4b87e@concordia.ca> Date: Tue, 20 Jun 2017 10:31:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <32669.1497968098@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2017-06-20 10:31:38 EDT Archived-At: Subject: Re: [Anima] minor clarifications to voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 14:31:42 -0000 Nit: s/manufacture/manufacturer/ See below for position. Bill On 20/06/2017 10:14 AM, Michael Richardson wrote: > > Based upon discussion last week about synchronizing the voucher document with > the BRSKI MASA protocol the following clarification was made to the voucher > document as part of the WGLC: > > > - signed using a PKCS#7 structure. The voucher artifact is generated by > - the pledge's manufacture or delegate (i.e. the MASA). > + signed using a PKCS#7 structure. The voucher artifact is normally generated by > + the pledge's manufacture or delegate (i.e. the Manufacturer Authorized Signing manufacturer > + Authority). A voucher artifact could be signed by a non-MASA and be compliant > + to the specified artifact format described in this document. The appropriate > + use and trust of such vouchers is out-of-scope of this document. > + > > This document only defines the voucher artifact, leaving it to other > documents to describe specialized protocols for accessing it. > @@ -75,7 +79,8 @@ > > This document defines a strategy to securely assign a pledge to an owner, > using an artifact signed, directly or indirectly, by the pledge's manufacturer > - or delegate (i.e. the MASA). This artifact is known as the voucher. > + or delegate, i.e. the Manufacturer Authorized Signing > + Authority (MASA). This artifact is known as the voucher. > > The voucher artifact is a JSON document, conforming to a data model > described by YANG , that has been signed using > @@ -265,7 +270,7 @@ NOTE: All voucher types include a 'Pledge ID serial number' > >
> > - The voucher's purpose is to securely assign a pledge to an owner. > + The voucher's primary purpose is to securely assign a pledge to an owner. > The voucher informs the pledge which entity it should consider to be > its owner. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Tue Jun 20 08:28:14 2017 Return-Path: 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 72D8D1314B6 for ; Tue, 20 Jun 2017 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 5aiKs6VK_iUP for ; Tue, 20 Jun 2017 08:28:10 -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 3BE0C1314D3 for ; Tue, 20 Jun 2017 08:25:53 -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 ECFCB58C4AF for ; Tue, 20 Jun 2017 17:25:48 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D6A5CB0C352; Tue, 20 Jun 2017 17:25:48 +0200 (CEST) Date: Tue, 20 Jun 2017 17:25:48 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20170620152548.GJ20021@faui40p.informatik.uni-erlangen.de> References: <32669.1497968098@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32669.1497968098@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] voucher draft last-call fixes (Re: minor clarifications to voucher) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:28:13 -0000 Here is the rfcdiff between the -03 (last call) version of the voucher document and the version where the authors have integrated their last call fixes. This includes what Michaels last mail was referring to: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/voucher/master/draft-ietf-anima-voucher.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-voucher-03.txt - Textual fixes without semantic changes (eg: writing out abbreviations on first use) - The tree diagram notation used in the doc is now explained in the document itself. In -03 we referred to an external document but that doc is still evolving and would therefore be an unstable reference. - Explained that vouchers can be sent by someone else than MASA and received by someone else than pledge. This clarifies the intended additional use of voucher in BRSKI beside that "normal" case. - Inlined grouping in the yang model for the voucher to simplify the definition/format. - Updated requirements langauge to include (RFC8174) (only capital MUST/SHOULD are standards language..). Latest version: https://raw.githubusercontent.com/anima-wg/voucher/master/draft-ietf-anima-voucher.txt Cheers Toerless (as one of the authors). On Tue, Jun 20, 2017 at 10:14:58AM -0400, Michael Richardson wrote: > > Based upon discussion last week about synchronizing the voucher document with > the BRSKI MASA protocol the following clarification was made to the voucher > document as part of the WGLC: > > > - signed using a PKCS#7 structure. The voucher artifact is generated by > - the pledge's manufacture or delegate (i.e. the MASA). > + signed using a PKCS#7 structure. The voucher artifact is normally generated by > + the pledge's manufacture or delegate (i.e. the Manufacturer Authorized Signing > + Authority). A voucher artifact could be signed by a non-MASA and be compliant > + to the specified artifact format described in this document. The appropriate > + use and trust of such vouchers is out-of-scope of this document. > + > > This document only defines the voucher artifact, leaving it to other > documents to describe specialized protocols for accessing it. > @@ -75,7 +79,8 @@ > > This document defines a strategy to securely assign a pledge to an owner, > using an artifact signed, directly or indirectly, by the pledge's manufacturer > - or delegate (i.e. the MASA). This artifact is known as the voucher. > + or delegate, i.e. the Manufacturer Authorized Signing > + Authority (MASA). This artifact is known as the voucher. > > The voucher artifact is a JSON document, conforming to a data model > described by YANG , that has been signed using > @@ -265,7 +270,7 @@ NOTE: All voucher types include a 'Pledge ID serial number' > >
> > - The voucher's purpose is to securely assign a pledge to an owner. > + The voucher's primary purpose is to securely assign a pledge to an owner. > The voucher informs the pledge which entity it should consider to be > its owner. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Tue Jun 20 08:33:15 2017 Return-Path: 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 8DFC7131AEB for ; Tue, 20 Jun 2017 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 ckyjyByvAvQL for ; Tue, 20 Jun 2017 08:33:07 -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 75922131A06 for ; Tue, 20 Jun 2017 08:31:05 -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 B46AE58C4AF; Tue, 20 Jun 2017 17:31:01 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9B682B0C352; Tue, 20 Jun 2017 17:31:01 +0200 (CEST) Date: Tue, 20 Jun 2017 17:31:01 +0200 From: Toerless Eckert To: William Atwood Cc: anima@ietf.org Message-ID: <20170620153101.GK20021@faui40p.informatik.uni-erlangen.de> References: <32669.1497968098@obiwan.sandelman.ca> <6dbe94ef-ee07-5faf-d761-771c19c4b87e@concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6dbe94ef-ee07-5faf-d761-771c19c4b87e@concordia.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] minor clarifications to voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:33:13 -0000 Thanks, Bill I have opened an issue against this on github, just for tracking purposes so that we can fix these things more easily in batches. Anyone who has an issue with the draft is also welcome to submit the issue directly to github: https://github.com/anima-wg/voucher/issues The same is true for other drafts in the github, eg: BRSKI: https://github.com/anima-wg/anima-bootstrap/issues Cheers Toerless On Tue, Jun 20, 2017 at 10:31:39AM -0400, William Atwood wrote: > Nit: > s/manufacture/manufacturer/ > > See below for position. > > Bill > > On 20/06/2017 10:14 AM, Michael Richardson wrote: > > > > Based upon discussion last week about synchronizing the voucher document with > > the BRSKI MASA protocol the following clarification was made to the voucher > > document as part of the WGLC: > > > > > > - signed using a PKCS#7 structure. The voucher artifact is generated by > > - the pledge's manufacture or delegate (i.e. the MASA). > > + signed using a PKCS#7 structure. The voucher artifact is normally generated by > > + the pledge's manufacture or delegate (i.e. the Manufacturer Authorized Signing > manufacturer > > + Authority). A voucher artifact could be signed by a non-MASA and be compliant > > + to the specified artifact format described in this document. The appropriate > > + use and trust of such vouchers is out-of-scope of this document. > > + > > > > This document only defines the voucher artifact, leaving it to other > > documents to describe specialized protocols for accessing it. > > @@ -75,7 +79,8 @@ > > > > This document defines a strategy to securely assign a pledge to an owner, > > using an artifact signed, directly or indirectly, by the pledge's manufacturer > > - or delegate (i.e. the MASA). This artifact is known as the voucher. > > + or delegate, i.e. the Manufacturer Authorized Signing > > + Authority (MASA). This artifact is known as the voucher. > > > > The voucher artifact is a JSON document, conforming to a data model > > described by YANG , that has been signed using > > @@ -265,7 +270,7 @@ NOTE: All voucher types include a 'Pledge ID serial number' > > > >
> > > > - The voucher's purpose is to securely assign a pledge to an owner. > > + The voucher's primary purpose is to securely assign a pledge to an owner. > > The voucher informs the pledge which entity it should consider to be > > its owner. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > -- > > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email:william.atwood@concordia.ca > 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 20 14:32:48 2017 Return-Path: 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 B932F12EC58 for ; Tue, 20 Jun 2017 14:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 1KQ7keqT7Kgo for ; Tue, 20 Jun 2017 14:32:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0611C1294EC for ; Tue, 20 Jun 2017 14:32:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AAB27205B2; Tue, 20 Jun 2017 17:34:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 620696380F; Tue, 20 Jun 2017 17:32:44 -0400 (EDT) From: Michael Richardson To: William Atwood cc: anima@ietf.org In-Reply-To: <6dbe94ef-ee07-5faf-d761-771c19c4b87e@concordia.ca> References: <32669.1497968098@obiwan.sandelman.ca> <6dbe94ef-ee07-5faf-d761-771c19c4b87e@concordia.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] minor clarifications to voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:32:48 -0000 --=-=-= Content-Type: text/plain William Atwood wrote: > Nit: > s/manufacture/manufacturer/ > See below for position. Thanks, edited. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAllJlHwACgkQgItw+93Q 3WUP4wgAkEXy4hG7qQcpBJG6vcpwLBBwSlcAAJGkscaJLKE+0DvvuJu1hmzecVQ8 g7wKYVbKJoE+uV3YDmEOL/Qug2+USni8JVDCF4B1bbz2lcOxYHVZhCabBfeXzWnh FEoNAsJp5EmGNiQ/bXZeXx+8C2uWHZycTsI0V3kdE5lzvS/7Iskphmd3sCZCIv38 smMk7DB5Em/L6T/nRDHsdNrUzeqoMvWmc+xddajkmpD/O29t+htd7e5Y5SEewEId wyFgMyL7EpOcBxk8lWlqj4zWgbg3TOSiIkKCY9gnCAsMhDJP2aXnMftpr6wjZvv6 vy/iE9GMc8Np0JqZqr+hTloEMZ2v3g== =0Z8c -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 21 11:24:01 2017 Return-Path: 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 52504129458 for ; Wed, 21 Jun 2017 11:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Ly4-wI30cOX8 for ; Wed, 21 Jun 2017 11:23:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671B712943D for ; Wed, 21 Jun 2017 11:23:58 -0700 (PDT) Received: from dooku.sandelman.ca (199-7-157-41.eng.wind.ca [199.7.157.41]) by relay.sandelman.ca (Postfix) with ESMTPS id 1F50F1F906 for ; Wed, 21 Jun 2017 18:23:56 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 22D4CA04; Wed, 21 Jun 2017 14:07:42 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 21 Jun 2017 14:07:42 -0400 Message-ID: <3999.1498068462@dooku.sandelman.ca> Archived-At: Subject: [Anima] voucher question re: pinned-domain-cert X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:24:00 -0000 --=-=-= Content-Type: text/plain In voucher-03 (the latest I have on my laptop, while offline), we have: +--ro pinned-domain-cert* binary But then in 5.2 we show as an example: { "ietf-voucher:voucher": { "created-on": "2016-10-07T19:31:42Z", "assertion": "logged", "serial-number": "JADA123456789", "serial-number-issuer": "some binary identifier", "domain-cert-trusted-ca": "base64-encoded X.509 DER", I am currently implementing the pinned-domain-cert, which we did not include in the example. I am guessing that we would write "base4-encoded X509 DER" The question is, would this be in any way different than writing "X509 PEM"? One would want to omit the "BEGIN FOO", lines, and all newlines, but I think it would be essentially the same in a JSON (or JWT) format where we have to base64. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZSrXtAAoJEJVM4Vb9/EKQgo8H/jIGAgxpzqi1H9rRo6TeexF4 0U73h2N9HVEdaNeb3q1qG3sOExHfC89E3TbbwT9dPK+a0g6yOlEK+YkliGzNmlCW WzxMnvUjtPt6M+W0/H6wRpwVWQrHZslTzUpQ3dDFpMo6ObZDfDrj9lJt4qWCjuep RI3e78X1fcuG734qvyoYF8v8uaUqya23Xx3iFDUITZE/eToRS6awvod62E9PpUrJ d/+0eQBIe6wHxwxw6qoeSA9ONgFMrrNkTLC0nAWjfZP+IJqE2RAYQB5tN1CS273U 1be/N6IBOYWrCJBkk1clTQ1sWDIicupyF8DQxdwwIUYbxPxYwQQIPR5gm2mbo8I= =00wq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 21 13:55:47 2017 Return-Path: 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 ECA2912949D for ; Wed, 21 Jun 2017 13:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 nEudrNUsIV_s for ; Wed, 21 Jun 2017 13:55:44 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0108.outbound.protection.outlook.com [104.47.34.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE231274D2 for ; Wed, 21 Jun 2017 13:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CByIeVwN+PlC8cWbNFCmtffh/apKWYbWCcn+iWFFyZg=; b=NQCisPstYouhCCnuaI/+zZLgYxfJfbgTML6NAvPl3a3kcLUB0NKyrwz5PDtv768qjEMPWEItMul57H0daaTXQTNRMi1f+1scEWvCTVtHAxgVPZQnX8KHixZQ36aM7p2swB8U6HsITHI8HoQ3x7jotJF5Mn4PKVPMoq1rcL347Ok= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1460.namprd05.prod.outlook.com (10.160.117.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Wed, 21 Jun 2017 20:55:43 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1199.015; Wed, 21 Jun 2017 20:55:43 +0000 From: Kent Watsen To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] voucher question re: pinned-domain-cert Thread-Index: AQHS6ruPoBi73lU+lUGI4HNn9mYtcaIviPaA Date: Wed, 21 Jun 2017 20:55:43 +0000 Message-ID: References: <3999.1498068462@dooku.sandelman.ca> In-Reply-To: <3999.1498068462@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1460; 7:AKTVPDhjW0ZC0GGgOgRKqHHJNQxIHdaqW9hnxw3P0mRQaF5XUasCL1e++FIk7wmx1as+tnf6ldKO0Vz8nnX4C5GT8QB8NeSANrfhHzXEnx9Qrm5YGN0feAYHw0dyYyoyjjln6lco8mq+fBGcM1SOH05UYQNcDjqAxO7q03qbOBJ1YsNmXRh+aZQ1P9J+Wo7wpayIelViuX44uk485a4UcGEoHrMkwcxOLs1xezpBAdeHWbKZlbcPKN6oOOtdUUOIX9SRYSy0ucRhg3rWCn3XkvpcLb9khPyWD3lrDO/fWqFNLGRspKEdSMvNGXKZoNrSwDbVaeRz8zKLIilOYyUTKTJ3xFf7YTzdrLy10uXKbMEh/feCgpmk28vym5nN0MDIN+3dStPD+tRrzwd5P458a9QZaL45qP8icdYN6hMxJPbVWTRXvPFhQoO5POAgFeUN1c3bbq4+QLCdt7OC3C0xfweKq13+8nI61SwoeUvehCRgXco9LJSfhMFagfz+Tnwy3qwQ+E0AXLFZwIbzL03ShkxQt2r9jlE6JG60uPGDWt+UQgqIk356pyjXn8MLWSDZ1jvCoXluNFPvx0onnJqQnXUBoZtRDPPVlzaU1uougl+/qQICBKjeK+kN3rh3xnd6Ox9NYC0xGCOSp6BbLZCSCVyuKdI6bVJn7qV9wyflEbsOF9Qv97hZCRE9USSWX4A4Sb2pzcWWwKZoHvcd1EbfjRq9pycvtBk58d/dUS/ibooYcH9yMzx2IAJU7WaebHV7MLT0C84klRgtyaa9f05lyVOuo1TncfdWMzB1gH5cTf0= x-ms-office365-filtering-correlation-id: bdb15d1b-b006-4c0f-d333-08d4b8e7e1fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1460; x-ms-traffictypediagnostic: BN3PR0501MB1460: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1460; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1460; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39850400002)(39400400002)(39410400002)(122556002)(77096006)(478600001)(8936002)(7736002)(83506001)(305945005)(81166006)(83716003)(3846002)(2501003)(2900100001)(86362001)(102836003)(6116002)(82746002)(25786009)(8676002)(5660300001)(230783001)(66066001)(2950100002)(14454004)(6246003)(38730400002)(3660700001)(189998001)(2906002)(3280700002)(33656002)(6436002)(76176999)(6512007)(53936002)(50986999)(54356999)(6506006)(6486002)(4001350100001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1460; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4FB2321CC802484D94DE1905DFAEBDEA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 20:55:43.3839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1460 Archived-At: Subject: Re: [Anima] voucher question re: pinned-domain-cert X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 20:55:46 -0000 DQpZZXMsIGEgYmFzZTY0LWVuY29kZWQgREVSIGFuZCBhIFBFTSBhcmUgZGlmZmVyZW50LCBpbiB0 aGF0IHRoZQ0KbGF0dGVyIGhhcyBoZWFkZXIvZm9vdGVycyBtaXNzaW5nIGluIHRoZSBmb3JtZXIu DQoNCktlbnQNCg0KDQotLS0tLU9SSUdJTkFMIE1FU1NBR0UtLS0tLQ0KDQpJbiB2b3VjaGVyLTAz ICh0aGUgbGF0ZXN0IEkgaGF2ZSBvbiBteSBsYXB0b3AsIHdoaWxlIG9mZmxpbmUpLCB3ZSBoYXZl Og0KDQogICAgICAgICstLXJvIHBpbm5lZC1kb21haW4tY2VydCogICAgICAgICAgICAgIGJpbmFy eQ0KDQpCdXQgdGhlbiBpbiA1LjIgd2Ugc2hvdyBhcyBhbiBleGFtcGxlOg0KDQogICB7DQogICAg ICJpZXRmLXZvdWNoZXI6dm91Y2hlciI6IHsNCiAgICAgICAiY3JlYXRlZC1vbiI6ICIyMDE2LTEw LTA3VDE5OjMxOjQyWiIsDQogICAgICAgImFzc2VydGlvbiI6ICJsb2dnZWQiLA0KICAgICAgICJz ZXJpYWwtbnVtYmVyIjogIkpBREExMjM0NTY3ODkiLA0KICAgICAgICJzZXJpYWwtbnVtYmVyLWlz c3VlciI6ICJzb21lIGJpbmFyeSBpZGVudGlmaWVyIiwNCiAgICAgICAiZG9tYWluLWNlcnQtdHJ1 c3RlZC1jYSI6ICJiYXNlNjQtZW5jb2RlZCBYLjUwOSBERVIiLA0KDQpJIGFtIGN1cnJlbnRseSBp bXBsZW1lbnRpbmcgdGhlIHBpbm5lZC1kb21haW4tY2VydCwgd2hpY2ggd2UgZGlkIG5vdCBpbmNs dWRlDQppbiB0aGUgZXhhbXBsZS4gIEkgYW0gZ3Vlc3NpbmcgdGhhdCB3ZSB3b3VsZCB3cml0ZSAi YmFzZTQtZW5jb2RlZCBYNTA5IERFUiINCg0KVGhlIHF1ZXN0aW9uIGlzLCB3b3VsZCB0aGlzIGJl IGluIGFueSB3YXkgZGlmZmVyZW50IHRoYW4gd3JpdGluZyAiWDUwOSBQRU0iPw0KT25lIHdvdWxk IHdhbnQgdG8gb21pdCB0aGUgIkJFR0lOIEZPTyIsIGxpbmVzLCBhbmQgYWxsIG5ld2xpbmVzLCBi dXQgSSB0aGluaw0KaXQgd291bGQgYmUgZXNzZW50aWFsbHkgdGhlIHNhbWUgaW4gYSBKU09OIChv ciBKV1QpIGZvcm1hdCB3aGVyZSB3ZSBoYXZlDQp0byBiYXNlNjQuDQoNCi0tDQpNaWNoYWVsIFJp Y2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jr cw0KIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCg0KDQo= From nobody Thu Jun 22 20:31:02 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF091241FC; Thu, 22 Jun 2017 20:31:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149818866020.17242.14281130620243106388@ietfa.amsl.com> Date: Thu, 22 Jun 2017 20:31:00 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 03:31:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks Authors : Sheng Jiang Zongpeng Du Brian Carpenter Qiong Sun Filename : draft-ietf-anima-prefix-management-04.txt Pages : 21 Date : 2017-06-22 Abstract: This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04 https://datatracker.ietf.org/doc/html/draft-ietf-anima-prefix-management-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 22 20:52:31 2017 Return-Path: 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 B76DB1241FC for ; Thu, 22 Jun 2017 20:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bpzvCY5bg4VR for ; Thu, 22 Jun 2017 20:52:27 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 6BD1A129B10 for ; Thu, 22 Jun 2017 20:52:27 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id c73so18019751pfk.2 for ; Thu, 22 Jun 2017 20:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cwmwLEVEqVSQ2QIEHE5GWJESZsyFHe6SecKwrdnWWcA=; b=hmjEd1n35ZQGW7O4rmlwuCxV/qIYxZ9sqe0Xe/O9xH+FH9UkyJ16Tx4FbhPXUVaZRl lIiaZY9FyhOPuTbWeIWg6IgZAT8ZGBKquTi3yOPAeuxs+jKlutfpczYEUPpwmk/tSJg/ gFTBI77+yHUMb8xChvb+4AJePQ7dRbucOt97FCAO98CEVdBCXci24m7S9UZyCHbvwzDd lAdBz5LT3KVx2Vidu4zhha9TtrvIPP6b9+1unlpaBBL3//0iDYIbujNT4ywm974gViw1 QATmvk2QL6bI+vpkm0hKaBJ3iV+1PgKgEI+/w3WPJYhUF7AN4M2QguMoMe0S60q6cZnY /sCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cwmwLEVEqVSQ2QIEHE5GWJESZsyFHe6SecKwrdnWWcA=; b=BrVAShoP1vsHiFsKWhfzqBeMorKjhk0thA35F8ND9n8sjuy9M1nzBR4k0bcQJB2Afh ZxvDVVR8T6OfI0gGgoJcak2cKlJx7wfqo6/z7FcyCUiMCjz6KT6ToR8juU8D4SZj1rIP Y8b9ZfmiwFGT9pqp/iJDNUVJxvm/SAGxKiqAMuImyFatE5wZNA2au7MRny3Bqz0TxPY0 Qvd2zrxUjyUpIUqvBC6RtBZRzh28yf8s0yWN0iQt6W+ssUHr9jKrs7K4K+GWTyU+e3vw 6V9HsNKi1IAGc1yjKzDAvW7VAyoKdDRHyT9q4pfk2aPWSuVvo3YB4MMguqxCuaaq6+xM LjpA== X-Gm-Message-State: AKS2vOzMkU5BLvCgwb2GWZiu1AxINjjaSNLliTVlHrFuSzyY3zm9cI2M UxoFPXGfnDFgms6J X-Received: by 10.99.120.199 with SMTP id t190mr6065352pgc.176.1498189946867; Thu, 22 Jun 2017 20:52:26 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id m73sm7110344pfi.12.2017.06.22.20.52.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jun 2017 20:52:26 -0700 (PDT) To: anima@ietf.org References: <149818866020.17242.14281130620243106388@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3b43df92-568b-f7a5-e8c4-57189075eaba@gmail.com> Date: Fri, 23 Jun 2017 15:52:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <149818866020.17242.14281130620243106388@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 03:52:30 -0000 Hi, This version follows a careful review by Toerless. There are three significant changes: 1. There is some explanation, mainly in an Appendix, about how this solution can co-exist with existing mechanisms for prefix delegation, especially DHCPv6/PD. In a few words, we'd use the autonomic solution to provide prefixes to edge devices, and conventional methods to delegate prefixes at the edge. Thus the client routers don't need to be in the trusted autonomic domain. 2. There is not complete agreement among the authors, but for now we have removed the "PD" flag from the GRASP objective, because the use case for it was very unclear (why bother to negotiate with GRASP and then add an extra step with DHCPv6?). 3. We have included two possible ways to add IPv4 prefix management. Comments are needed. Especially, should we include one of the IPv4 mechanisms in the final version? For people who like running code, there's a demo version at https://www.cs.auckland.ac.nz/~brian/graspy/pfxm3.py A screen shot of four instances working together is at https://www.cs.auckland.ac.nz/~brian/graspy/prefixen.png Regards Brian + co-authors On 23/06/2017 15:31, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks > Authors : Sheng Jiang > Zongpeng Du > Brian Carpenter > Qiong Sun > Filename : draft-ietf-anima-prefix-management-04.txt > Pages : 21 > Date : 2017-06-22 > > Abstract: > This document describes an autonomic solution for IPv6 prefix > management at the edge of large-scale ISP networks, with an extension > to support IPv4 prefixes. An important purpose of the document is to > use it for validation of the design of various components of the > autonomic networking infrastructure. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-prefix-management-04 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-prefix-management-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-04 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Jun 23 17:15:22 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 192B912EB5B; Fri, 23 Jun 2017 17:07:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: anima@ietf.org, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283509.7840.15223799348327911945.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:15 -0700 Archived-At: Subject: [Anima] anima - Requested session has been scheduled for IETF 99 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:30:00) Wednesday, Morning Session I 0930-1200 Room Name: Congress Hall III size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: homenet netconf dhc 6tisch nmrg 6lo Second Priority: 6man softwire roll supa v6ops Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Sheng Jiang Terry Manderson Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Mon Jun 26 19:33:42 2017 Return-Path: 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 F0C14126BFD; Mon, 26 Jun 2017 19:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 629GHa3AnoND; Mon, 26 Jun 2017 19:33:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774331200FC; Mon, 26 Jun 2017 19:33:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJG11362; Tue, 27 Jun 2017 02:33:35 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 03:33:34 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 27 Jun 2017 10:33:26 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: Result of WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 Thread-Index: AdLu7bv/vy5lQpTDS6WwX44V7aAs8A== Date: Tue, 27 Jun 2017 02:33:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDF0D16@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CDF0D16NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5951C3FF.00F3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 35fefd45c4967932d65e03cd668df4bb Archived-At: Subject: [Anima] Result of WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 02:33:40 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CDF0D16NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all Given there is no negative response to the WGLC on draft-ietf-anima-voucher= -03 and we did receive good reviews through the WG document stage and consi= dering the past history of this work, the ANIMA chairs feel it is has passe= d the WGLC and should advance. This conclusion is made with the condition t= hat the authors would solve the comments received during the WGLC and these= modifications were not substantial changes from 03 version. If there are b= ig changes, a shorter second WGLC may be needed. Once the update is published and it meets the above condition, for which th= e second WGLC is not needed, as shepherd, Sheng Jiang will finalize the she= pherd document and send the document on. Best regards, Toerless & Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CDF0D16NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all

 

Given there is no negative response to the WGLC on draft-ietf-anima-v= oucher-03 and we did receive good reviews through the WG document stage and= considering the past history of this work, the ANIMA chairs feel it is has passed the WGLC and should advance. = This conclusion is made with the condition that the authors would solve the= comments received during the WGLC and these modifications were not substan= tial changes from 03 version. If there are big changes, a shorter second WGLC may be needed.

 

Once the update is published and it meets the above condition, for wh= ich the second WGLC is not needed, as shepherd, Sheng Jiang will finalize t= he shepherd document and send the document on.

 

Best regards,

 

Toerless & Sheng

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CDF0D16NKGEML515MBXchi_-- From nobody Mon Jun 26 21:21:33 2017 Return-Path: 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 9BD23128B8E; Mon, 26 Jun 2017 21:21:32 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 SS5LHslaoQ_T; Mon, 26 Jun 2017 21:21:29 -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 4DECA127136; Mon, 26 Jun 2017 21:21:29 -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 4656558C4D5; Tue, 27 Jun 2017 06:21:24 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2D50BB0C3EC; Tue, 27 Jun 2017 06:21:24 +0200 (CEST) Date: Tue, 27 Jun 2017 06:21:24 +0200 From: Toerless Eckert To: Sheng Jiang Cc: Anima WG , "anima-chairs@ietf.org" Message-ID: <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 04:21:33 -0000 Thanks a lot, Sheng! Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up having to do a fix for the ACP draft as a result of your comments. Diff between -02 and fixed up stable connectivity draft here: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt If you are fine with the fixes let me know, and i'll push it to datatracker as -03. If not ok. feel free to use email or now also add issue to the git. Raw txt/git files of fixed stable connectivity text: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml Diff for change done in ACP (explaining ACP connect better): http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Cheers Toerless On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: > Hi, authors of draft-ietf-anima-stable-connectivity, > > I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. > > First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section. Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing challenges with IPv6 only management planes. I have added paragraphs to justify the need for this section and that its all undesirable workarounds Please check. To me, this messy section is the price we have to pay so that the ACP can simply be IPv6 only. Its a price i am happy to pay. > Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology. > Point 2 is a precondition (it is actually conflicted with section 2.1.4.) Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4. > I don't understand point 4. What does "exposing the ACP natively" mean? That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity. Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft. > Thirdly, I have issues to use names to distinguish the path selection policies. > This is a chicken&egg issue in the autonomic scenario. > Who and how the DNS names are setup, by human administrator? IMHO, considerations for names are one of the most crucial part of operationalizing the ACP. The little text we have about the ACP is IMHO a good compromise between overlooking the problem and writing a lot more text. The concept of using different addresses for a device for different actions is not novel to ACP. Think of using a loopback to "reliably" talk to a router vs. ping'ing specific interface addresses of a router to discover whether an peer (reachable via that interface) is up/down. If you look at service providers name setups (often in DNS), then they will have different names for those different addresses and use those different names in the different tools. The text in this draft simply explains the same concept for ACP vs. other addresses. DNS names can be setup by various locally built automation scripting or templates. Same think for DNS names for ACP. Operators will likely point out that automating the DNS name creation is more difficult because we do not use topology/semantic ACP addresses, but in principle it's the same automation task. > If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? ALl the existing "actions" that you want to do for a device are just too stupid: They do not include the logic of knowing which address is best for them to use. That's why you use names for subsets of the possible addresses to allow you to specify exatly those address(es) that will reach the device via the network connection matching the intent of the action you're taking. > DNS registration & lookup by itself is a very complex and time-consumption procedure. Depends on your automation. Its certainly an interesting aspect especially moving from IPv4 to IPv6 where embedding logic into adresses becomes a whole different ballgame. > If we don't want to show the semantic of these addresses to any human, names are meaningless. But you need new NOC tools where each action would need to know what type of connection is best for it. I have added one paragraph to 2.1.5 to outline this logic and justification for why to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device" > In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP. Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure connectivity for functions running distributed in network devices (GRASP via ACP). > At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface. Ack. Changed text to: A workaround without additional software functionality could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture. A (virtual) software loopback between the ACP and data plane VRF would of course be the better solution. The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested. > Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components). Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter. > Minor comments, > > Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess. The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph: This section describes stable connectibity for centralized OAM operations via ACP/ANI starting by what we expect to be the most likely easiest short-term deployment option. It then describes limitation/challenges of that approach and their solutions/workarounds to finish with the preferred target option of autonomic NOC devices in . This order was choosen because it helps to explain how simple one can start using the ACP, how difficult workarounds can become (and therefore what to avoid), and finally because one very promising long-term solution alternative is exactly like the most easy short-term solution only virtualized and automated. The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow... > It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed. Good point. Added the following sentence: Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only. > The document does not properly quota references in the text. The references defined are mostly not used. Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-) > The document separate sections for Informative/Normative References Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational. > The empty section 5 "Further considerations", should be removed. Done. > Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575. Fixed. > In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"? added: Examples include change of IGP protocols or areas, PD (Provider Dependent) to PI (Provider Independent) addressing, systematic topology changes. > In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks" Done > There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances. Done, added RFC references for those TLAs that have them as well. > Last sentence of section 2.2 should be removed. Done. > In section 3, first sentence, add "In this section," Done. > There are typos, needed to be fixed too: > > Two "the the" in the end of section 2.1.2 and end of section 4; Done > > A couple of "randomn" -> "random"; Done > > "networ" in section 2.1.5; Done > > "jut" -> "just" at the end of section 2.1.6, I guess. > > "The most simple" -> "the simplest" in section 2.17. Done. From nobody Mon Jun 26 21:44:20 2017 Return-Path: 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 AFE1C128DE5; Mon, 26 Jun 2017 21:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 ON69TN2RRHoA; Mon, 26 Jun 2017 21:44:17 -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 4CFEA128D64; Mon, 26 Jun 2017 21:44:17 -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 C008958C4C7; Tue, 27 Jun 2017 06:44:13 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A237CB0C3D6; Tue, 27 Jun 2017 06:44:13 +0200 (CEST) Date: Tue, 27 Jun 2017 06:44:13 +0200 From: Toerless Eckert To: anima@ietf.org Cc: draft-ietf-anima-prefix-management@ietf.org Message-ID: <20170627044413.GL15901@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] [anima] WG Last Call on draft-ietf-anima-prefix-management-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 04:44:19 -0000 Dear ANIMA WG, After thorough review and discussions on the mailing list leading to the -04 version posted last week i think the draft is now mature enough for working group last call. This e-mail starts a two-weeks period for evaluation of this document by the WG. Please provide your feedback on the ANIMA mailing list by end of July 10th, 2017. Thanks, best regards Toerless (as ANIMA WG co-chair). P.S.: +1 -> i support the publishing of this document. From nobody Mon Jun 26 22:33:39 2017 Return-Path: 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 C736F12EB77; Mon, 26 Jun 2017 22:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 MRzbQPJEzfN8; Mon, 26 Jun 2017 22:33:36 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEE812EB69; Mon, 26 Jun 2017 22:33:36 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id C1A8C100436; Tue, 27 Jun 2017 07:33:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id A78D86006E; Tue, 27 Jun 2017 07:33:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0352.000; Tue, 27 Jun 2017 07:33:34 +0200 From: To: Toerless Eckert , "anima@ietf.org" CC: "draft-ietf-anima-prefix-management@ietf.org" Thread-Topic: [Anima] [anima] WG Last Call on draft-ietf-anima-prefix-management-04 Thread-Index: AQHS7wANJu25Up3B5k6rjgEp++cvB6I4LhfQ Date: Tue, 27 Jun 2017 05:33:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009FFB9D2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20170627044413.GL15901@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170627044413.GL15901@faui40p.informatik.uni-erlangen.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] [anima] WG Last Call on draft-ietf-anima-prefix-management-04 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 05:33:38 -0000 Dear Toerless, all,=20 I didn't had the opportunity to read this document earlier, hence this shor= t notice.=20 When reading it, I found that an IPR I'm aware of may apply to this documen= t. I will ask my colleagues to submit a disclosure.=20 Cheers, Med > -----Message d'origine----- > De=A0: Anima [mailto:anima-bounces@ietf.org] De la part de Toerless Ecker= t > Envoy=E9=A0: mardi 27 juin 2017 06:44 > =C0=A0: anima@ietf.org > Cc=A0: draft-ietf-anima-prefix-management@ietf.org > Objet=A0: [Anima] [anima] WG Last Call on draft-ietf-anima-prefix- > management-04 >=20 > Dear ANIMA WG, >=20 > After thorough review and discussions on the mailing list leading to the = - > 04 > version posted last week i think the draft is now mature enough for > working > group last call. >=20 > This e-mail starts a two-weeks period for evaluation of this document by > the WG. >=20 > Please provide your feedback on the ANIMA mailing list by end of July > 10th, 2017. >=20 > Thanks, best regards >=20 > Toerless (as ANIMA WG co-chair). >=20 > P.S.: >=20 > +1 -> i support the publishing of this document. >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jun 27 08:08:09 2017 Return-Path: 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 AAE1E127F0E; Tue, 27 Jun 2017 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 SdPzoBwDqOFX; Tue, 27 Jun 2017 08:07:57 -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 85CB0127601; Tue, 27 Jun 2017 08:07:54 -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 1E22558C4AF; Tue, 27 Jun 2017 17:07:50 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0528CB0C3F1; Tue, 27 Jun 2017 17:07:49 +0200 (CEST) Date: Tue, 27 Jun 2017 17:07:49 +0200 From: Toerless Eckert To: yang-doctors@ietf.org Cc: draft-ietf-anima-voucher@ietf.org, anima@ietf.org Message-ID: <20170627150748.GB18207@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] anima/yang-doctors: cross stds boddy extension mechanism ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:08:02 -0000 Dear Yang doctors In our draft-ietf-anima-voucher we are looking for an optional extension mechanism wheeby a yang data structure we define in the draft shuold optionally be able to have a substructure that we would like to possibly be defined by a different standards body than the IETF. Do we have such an extension mechanism ? If not in Yang natively, maybe via a mechanism of specific encodings ? We are planning to mandate JSON as the encoding for our protocols using the data model. Thanks Toerless From nobody Tue Jun 27 08:17:51 2017 Return-Path: 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 0F850129B64; Tue, 27 Jun 2017 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 tlSH_g1l0Xo2; Tue, 27 Jun 2017 08:17:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A485129B5D; Tue, 27 Jun 2017 08:17:36 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C31C1AE0385; Tue, 27 Jun 2017 17:17:34 +0200 (CEST) Date: Tue, 27 Jun 2017 17:17:33 +0200 (CEST) Message-Id: <20170627.171733.178939834158903180.mbj@tail-f.com> To: tte@cs.fau.de Cc: yang-doctors@ietf.org, draft-ietf-anima-voucher@ietf.org, anima@ietf.org From: Martin Bjorklund In-Reply-To: <20170627150748.GB18207@faui40p.informatik.uni-erlangen.de> References: <20170627150748.GB18207@faui40p.informatik.uni-erlangen.de> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [yang-doctors] anima/yang-doctors: cross stds boddy extension mechanism ? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:17:38 -0000 Hi, Toerless Eckert wrote: > Dear Yang doctors > > In our draft-ietf-anima-voucher we are looking for an optional > extension mechanism > wheeby a yang data structure we define in the draft shuold optionally > be able > to have a substructure that we would like to possibly be defined by a > different > standards body than the IETF. Do we have such an extension mechanism ? Unfortunately not :( YANG has the "augment" statement, but it can not augment a structure that has been defined with the extension "rc:yang-data". (For this reason, I have proposed that YANG should have a core statement to define structures, instead of having to rely on rc:yang-data, but this requires a new YANG version...) Of course, one *could* define another extension statement "augment-yang-data" for this purpose, but it's probably not a good idea; we should be careful with defining extensions... /martin > If not > in Yang natively, maybe via a mechanism of specific encodings ? We are > planning > to mandate JSON as the encoding for our protocols using the data > model. > > Thanks > Toerless > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > From nobody Tue Jun 27 13:47:07 2017 Return-Path: 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 E7D7F12EB25 for ; Tue, 27 Jun 2017 13:47:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 nN7jZ-WOpbM5 for ; Tue, 27 Jun 2017 13:47:04 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 46F9A1294C8 for ; Tue, 27 Jun 2017 13:47:04 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id s66so22128569pfs.1 for ; Tue, 27 Jun 2017 13:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=aCnKAVNjFnqpsdVPoooQQ2eVklmWkScHfQ8nhZvQptg=; b=Q4eJQVdLL8ezbjzJdXoOSItJjoQuBwmt9VTyFfgzuqd6y+BoqKJH4dgGFNZU494Hfn SoINVuFrTAUw9BBn31fXR0cgPdV0EYdrrjNDEot0mTrjmipR4xwknTBQsc0FWw32wMtT DIEup0eP7sgRcT8UVg3tgAH3L72tLRwk8/YGNjFpmtydJtB/VWV8yNfkDYSzOM3VUUxX Zz0XM/yfSzF5HeVT5pemyAs/WbX2XwTujHCipKsCr8lhKI+kIeX/pMT0Tdy3Z4uO/emt 9AgFH7yH9e99eN60E+yLMslwFZjJVF3nSJLDACFrK0zx1aFf+vdYpx4N6iUPdOaJO9QA FLUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=aCnKAVNjFnqpsdVPoooQQ2eVklmWkScHfQ8nhZvQptg=; b=H8AB5QIUnrnz7f5dzx97/Oe3pD2lRU/G7xu6yTVmNn8Tgt/pqibbxrjWQmILbbc2mQ aieUbCoSH2E80G9IhO5tAQ2pra48UfSJEM1FvIue6al/Kls39duJ57ocjKQ44u8OiUBg VpU7Ygkrpg1Q6KfKcEwkI2b+23C1t3AO3ZrfNi0+flBAnaTWkVTStAJOSQJ11iPuRPvQ mz2A7lFm9+kym/cC6FFiU14wxHQENbrT5+VlCOK7mEtBM//ZaAN7oo+bwYAgSKDL7HpC 2gCUelVmhSlRlVE6V9xtJOGafPEdm7CIJBTMA3QJYlAvqPsYt7WdxsN7ubFuJvzt04hA 5X4Q== X-Gm-Message-State: AKS2vOwnGP2acSlxlIrdwtuRjZjyYHkoVtDw4OVu8MGJWPi1SKhdJ82M VAJFOEgbVSnlKw5A X-Received: by 10.99.113.74 with SMTP id b10mr6997169pgn.139.1498596423660; Tue, 27 Jun 2017 13:47:03 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id e189sm254618pfe.100.2017.06.27.13.47.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 13:47:03 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <606a3776-87cb-6c88-ef93-7472a04212b4@gmail.com> Date: Wed, 28 Jun 2017 08:47:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Appendix D of draft-ietf-anima-bootstrapping-keyinfra-06 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:47:06 -0000 Hi, I am concerned by the amount of material in Appendix D of the latest BRSKI draft, which is intended to be deleted. In particular, there is this text: > None of these approaches require the network to have permanent > Internet connectivity. Even when the Internet based MASA service is > used, it is possible to pre-fetch the required information from the > MASA a priori, for example at time of purchase such that devices can > enrol later. This supports use cases where the domain network may be > entirely isolated during device deployment. I cannot find this point anywhere in the main text. But as we discussed a year or two ago, there are important use cases where an autonomic network will *never* be connected to the Internet. Two typical cases: 1) a military network, especially a "tactical" network deployed in the battlefield, which is actually a great use case for autonomics, 2) a control network requiring extra high security, for example the control system for a nuclear power plant. In such cases - if I was in charge** - I would consider an Internet connection to a MASA service to be dangerous and unacceptable, with pre-fetching being the only option. So, the quoted paragraph needs to be restored to wherever it fits in the main text of BRSKI. I suspect that there may be other essential items in Appendix D, so I urge everybody to have a careful look. ** I was in charge of systems software for a particle accelerator control network at one point in my life. The idea of connecting directly to an off-site network would have seemed extraordinarily stupid at the time. Regards Brian From nobody Tue Jun 27 14:03:23 2017 Return-Path: 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 8EE0912EB20; Tue, 27 Jun 2017 14:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Q3oikmtKETY4; Tue, 27 Jun 2017 14:03:19 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D862F12706D; Tue, 27 Jun 2017 14:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19844; q=dns/txt; s=iport; t=1498597398; x=1499806998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JKLWwO6BzwNixfiIC6xdrddWT432FLZtAuCqssrOMLg=; b=QU2pBd0V1sqc69PwnCv5SYAYaNQhGBPSC4GCx9FQWK+fK7xOXqH6yxes P7pReNC5ifmMCJiBQWXi6wIPSHgpbReHYeUuaq8pv57ChXzXQwaujncue xYs6+gABlo+TjkuH22fKxLJjrBztim58smdxWXBbViX5hQjdqHSnrxTaj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQDhxlJZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm88LWOBDgeDZYoZkUaQcYUrghEhAQyFH08CGoJpPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUZAgEDAQEhSwYFEAIBBgI/AwICAiULFBEBAQQOBYlMZBCScZ1igiaLX?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyeFLSsLgm6BPIZBMIIxBZ5vAoc0jDW?= =?us-ascii?q?CCoVJikGJK4t4AR84gQp0FUkSAYR+DBAZgU12BYgKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,272,1496102400"; d="scan'208,217";a="446746038" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2017 21:03:18 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v5RL3HDm021667 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 21:03:18 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 16:03:17 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 27 Jun 2017 16:03:17 -0500 From: "Max Pritikin (pritikin)" To: Sheng Jiang CC: Anima WG , "anima-chairs@ietf.org" Thread-Topic: [Anima] Result of WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 Thread-Index: AdLu7bv/vy5lQpTDS6WwX44V7aAs8AAxPkuA Date: Tue, 27 Jun 2017 21:03:17 +0000 Message-ID: <818D85B2-F5DB-4253-A4D1-2B344CD273CA@cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CDF0D16@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDF0D16@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.7] Content-Type: multipart/alternative; boundary="_000_818D85B2F5DB4253A4D12B344CD273CAciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Result of WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 21:03:22 -0000 --_000_818D85B2F5DB4253A4D12B344CD273CAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9lcmxlc3MgKHRoZSBvdGhlciB3b3JraW5nIGdyb3VwIGNoYWlyKSBoYXMgYmVlbiBpbnZvbHZl ZCBpbiBjb252ZXJzYXRpb25zIGNvbmNlcm5pbmcgdGhlIG9wZW4gaXNzdWVzIGxpc3RlZCBvbiB0 aGUgZ2l0aHViIHJlcG9zaXRvcnkgZm9yIHRoZSB2b3VjaGVyIGRvY3VtZW50Lg0KVGhlIGlzc3Vl cyBzaG91bGQgYmUgcmVzb2x2ZWQgbm93IGFzIHBlciB0aGUgY3VycmVudCBzdGF0dXMgaW4gZ2l0 aHViLiBTZWUgaGVyZSBmb3IgZGV0YWlscyBvZiB0aHJlZSBvcGVuIGlzc3VlcyByZW1haW5pbmc6 DQpodHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvdm91Y2hlci9pc3N1ZXMNClRoZSBvdGhlciBp c3N1ZXMgaGF2ZSBiZWVuIHJlc29sdmVkIGFuZCB0aGUg4oCYdG9wIG9mIHRoZSB0cmVl4oCZIGlz IGhlcmU6DQpodHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvdm91Y2hlci9ibG9iL21hc3Rlci9k cmFmdC1pZXRmLWFuaW1hLXZvdWNoZXIudHh0DQoNCklmIHlvdSBhcmUgY3VyaW91cyBhYm91dCB3 aGF0IHRoaXMgcmVzb2x2ZXMgc28gZmFyIHBsZWFzZSBsb29rIGF0IHRoZXNlIGRpZmZzIChoZXJl IHN1bW1hcml6ZWQgdmlhIHRoZSBjb21taXQgY29tbWVudHMpOg0KDQpbc29tZSBtaW5vciBlZGl0 b3JpYWwgd29ya10NCnR5cG8gaW4gImhhbmdUZXgiIGluc3RlYWQgb2YgImhhbmdUZXh0IiAyZjBk NjRjDQp1cGRhdGVkIGhhbmd0ZXh0IGZvciBhcnRpZmFjdCBkZWZpbml0aW9uIDRmNmM3MTANClVw ZGF0ZWQgdGhlIHByb3hpbWl0eSBkZXNjcmlwdGlvbiB3aXRoIG1pbm9yIGVkaXRvcmlhbCBlZGl0 cy4g4oCmIGI3NDJjNWENCk1lcmdlIGJyYW5jaCAnbWFzdGVyJyBpbnRvIHZvdWNoZXJfc3luY18w NjE0MTcgNmNjOWQ3Mg0KbWFudWFsIG1lcmdlIG9mIGEgZ2VuZXJhdGVkIHR4dCBmaWxlIHN1Y2tz LiBjb21taXR0aW5nIGJ1aWx0IHZlcnNpb24g4oCmIOKApg0KW3N1YnN0YW50aXZlIGlzc3Vlc10N CmFkZGl0aW9uYWwgZW51bSBmb3Ig4oCYcHJveGltaXR54oCZIGFzc2VydGlvbnM6DQpodHRwczov L2dpdGh1Yi5jb20vYW5pbWEtd2cvdm91Y2hlci9jb21taXQvYjhlYzQ5MTkyNDJiYzI2YzkwODJm NjMzMDk5NjU2ZTQ4NTEwOTdlYQ0KDQphZGRpdGlvbiBvZiBwcmlvci1zaWduZWQtdm91Y2hlciB0 byBwcm92aWRlIGhpc3RvcnkgaW4gbm9ydGhib3VuZCBCUlNLSSBleGNoYW5nZXM6DQpodHRwczov L2dpdGh1Yi5jb20vYW5pbWEtd2cvdm91Y2hlci9jb21taXQvYjc0MmM1YTYzZTA1ZjEzNDFiMzdm OTYwMDlkNmJmY2Q1ZjViZTBlMQ0KDQpXZSBiZWxpZXZlIHRoaXMgcHJvdmlkZXMgZW5vdWdoIHRv IHByb2NlZWQgd2l0aCBMQyBhbmQgdG8gYWxsb3cgQlJTS0kgdG8gYmUgZmluYWxpemVkIHRvd2Fy ZCBMQyBhcyB3ZWxsIGFzYXAuDQoNCi0gbWF4DQoNCk9uIEp1biAyNiwgMjAxNywgYXQgODozMyBQ TSwgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbTxtYWlsdG86amlhbmdzaGVuZ0Bo dWF3ZWkuY29tPj4gd3JvdGU6DQoNCkhpLCBhbGwNCg0KR2l2ZW4gdGhlcmUgaXMgbm8gbmVnYXRp dmUgcmVzcG9uc2UgdG8gdGhlIFdHTEMgb24gZHJhZnQtaWV0Zi1hbmltYS12b3VjaGVyLTAzIGFu ZCB3ZSBkaWQgcmVjZWl2ZSBnb29kIHJldmlld3MgdGhyb3VnaCB0aGUgV0cgZG9jdW1lbnQgc3Rh Z2UgYW5kIGNvbnNpZGVyaW5nIHRoZSBwYXN0IGhpc3Rvcnkgb2YgdGhpcyB3b3JrLCB0aGUgQU5J TUEgY2hhaXJzIGZlZWwgaXQgaXMgaGFzIHBhc3NlZCB0aGUgV0dMQyBhbmQgc2hvdWxkIGFkdmFu Y2UuIFRoaXMgY29uY2x1c2lvbiBpcyBtYWRlIHdpdGggdGhlIGNvbmRpdGlvbiB0aGF0IHRoZSBh dXRob3JzIHdvdWxkIHNvbHZlIHRoZSBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIFdHTEMg YW5kIHRoZXNlIG1vZGlmaWNhdGlvbnMgd2VyZSBub3Qgc3Vic3RhbnRpYWwgY2hhbmdlcyBmcm9t IDAzIHZlcnNpb24uIElmIHRoZXJlIGFyZSBiaWcgY2hhbmdlcywgYSBzaG9ydGVyIHNlY29uZCBX R0xDIG1heSBiZSBuZWVkZWQuDQoNCk9uY2UgdGhlIHVwZGF0ZSBpcyBwdWJsaXNoZWQgYW5kIGl0 IG1lZXRzIHRoZSBhYm92ZSBjb25kaXRpb24sIGZvciB3aGljaCB0aGUgc2Vjb25kIFdHTEMgaXMg bm90IG5lZWRlZCwgYXMgc2hlcGhlcmQsIFNoZW5nIEppYW5nIHdpbGwgZmluYWxpemUgdGhlIHNo ZXBoZXJkIGRvY3VtZW50IGFuZCBzZW5kIHRoZSBkb2N1bWVudCBvbi4NCg0KQmVzdCByZWdhcmRz LA0KDQpUb2VybGVzcyAmIFNoZW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QNCkFuaW1hQGlldGYub3JnPG1haWx0 bzpBbmltYUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YW5pbWENCg0K --_000_818D85B2F5DB4253A4D12B344CD273CAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6B1CBBCE3803014BB7111389144F8B9F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVG9lcmxlc3MgKHRoZSBvdGhlciB3 b3JraW5nIGdyb3VwIGNoYWlyKSBoYXMgYmVlbiBpbnZvbHZlZCBpbiBjb252ZXJzYXRpb25zIGNv bmNlcm5pbmcgdGhlIG9wZW4gaXNzdWVzIGxpc3RlZCBvbiB0aGUgZ2l0aHViIHJlcG9zaXRvcnkg Zm9yIHRoZSB2b3VjaGVyIGRvY3VtZW50LiZuYnNwOw0KPGRpdiBjbGFzcz0iIj5UaGUgaXNzdWVz IHNob3VsZCBiZSByZXNvbHZlZCBub3cgYXMgcGVyIHRoZSBjdXJyZW50IHN0YXR1cyBpbiBnaXRo dWIuIFNlZSBoZXJlIGZvciBkZXRhaWxzIG9mIHRocmVlIG9wZW4gaXNzdWVzIHJlbWFpbmluZzom bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L2FuaW1hLXdnL3ZvdWNoZXIvaXNzdWVzIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vYW5p bWEtd2cvdm91Y2hlci9pc3N1ZXM8L2E+DQo8ZGl2IGNsYXNzPSIiPlRoZSBvdGhlciBpc3N1ZXMg aGF2ZSBiZWVuIHJlc29sdmVkIGFuZCB0aGUg4oCYdG9wIG9mIHRoZSB0cmVl4oCZIGlzIGhlcmU6 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9hbmlt YS13Zy92b3VjaGVyL2Jsb2IvbWFzdGVyL2RyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci50eHQiIGNs YXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9hbmltYS13Zy92b3VjaGVyL2Jsb2IvbWFzdGVyL2Ry YWZ0LWlldGYtYW5pbWEtdm91Y2hlci50eHQ8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JZiB5b3UgYXJlIGN1cmlvdXMgYWJvdXQg d2hhdCB0aGlzIHJlc29sdmVzIHNvIGZhciBwbGVhc2UgbG9vayBhdCB0aGVzZSBkaWZmcyAoaGVy ZSBzdW1tYXJpemVkIHZpYSB0aGUgY29tbWl0IGNvbW1lbnRzKTo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5bc29tZSBtaW5vciBlZGl0b3JpYWwgd29ya108 YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1z cGFjZTpwcmUiPjwvc3Bhbj50eXBvIGluICZxdW90O2hhbmdUZXgmcXVvdDsmbmJzcDtpbnN0ZWFk IG9mICZxdW90O2hhbmdUZXh0JnF1b3Q7PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHls ZT0id2hpdGUtc3BhY2U6cHJlIj4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4i IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj4yZjBkNjRjPGJyIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3Nw YW4+dXBkYXRlZCBoYW5ndGV4dCBmb3IgYXJ0aWZhY3QgZGVmaW5pdGlvbjxzcGFuIGNsYXNzPSJB cHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+PHNwYW4g Y2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+NGY2 YzcxMDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwv c3Bhbj5VcGRhdGVkIHRoZSBwcm94aW1pdHkgZGVzY3JpcHRpb24gd2l0aCBtaW5vciZuYnNwO2Vk aXRvcmlhbCBlZGl0cy4mbmJzcDvigKY8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxl PSJ3aGl0ZS1zcGFjZTogcHJlOyI+DQo8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFi LXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPmI3NDJjNWE8L2Rpdj4NCjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu Pk1lcmdlIGJyYW5jaCAnbWFzdGVyJyBpbnRvIHZvdWNoZXJfc3luY18wNjE0MTc8c3BhbiBjbGFz cz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPg0KPC9zcGFuPjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu PjZjYzlkNzI8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxl PSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5tYW51YWwgbWVyZ2Ugb2YgYSBnZW5lcmF0ZWQgdHh0 IGZpbGUgc3Vja3MuJm5ic3A7Y29tbWl0dGluZyBidWlsdCB2ZXJzaW9uIOKApiZuYnNwO+KApjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFi LXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi Pjwvc3Bhbj5bc3Vic3RhbnRpdmUgaXNzdWVzXTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5hZGRp dGlvbmFsIGVudW0gZm9yIOKAmHByb3hpbWl0eeKAmSBhc3NlcnRpb25zOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw cmUiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvdm91Y2hlci9j b21taXQvYjhlYzQ5MTkyNDJiYzI2YzkwODJmNjMzMDk5NjU2ZTQ4NTEwOTdlYSIgY2xhc3M9IiI+ aHR0cHM6Ly9naXRodWIuY29tL2FuaW1hLXdnL3ZvdWNoZXIvY29tbWl0L2I4ZWM0OTE5MjQyYmMy NmM5MDgyZjYzMzA5OTY1NmU0ODUxMDk3ZWE8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5hZGRpdGlvbiBvZiBwcmlvci1zaWdu ZWQtdm91Y2hlciB0byBwcm92aWRlIGhpc3RvcnkgaW4gbm9ydGhib3VuZCBCUlNLSSBleGNoYW5n ZXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5 bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9h bmltYS13Zy92b3VjaGVyL2NvbW1pdC9iNzQyYzVhNjNlMDVmMTM0MWIzN2Y5NjAwOWQ2YmZjZDVm NWJlMGUxIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vYW5pbWEtd2cvdm91Y2hlci9jb21t aXQvYjc0MmM1YTYzZTA1ZjEzNDFiMzdmOTYwMDlkNmJmY2Q1ZjViZTBlMTwvYT48c3BhbiBjbGFz cz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+DQo8L3NwYW4+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+V2UgYmVsaWV2ZSB0aGlzIHByb3ZpZGVzIGVub3VnaCB0byBwcm9jZWVk IHdpdGggTEMgYW5kIHRvIGFsbG93IEJSU0tJIHRvIGJlIGZpbmFsaXplZCB0b3dhcmQgTEMgYXMg d2VsbCBhc2FwLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+LSBtYXg8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5PbiBKdW4gMjYsIDIwMTcsIGF0IDg6MzMgUE0sIFNoZW5nIEppYW5nICZsdDs8YSBocmVmPSJt YWlsdG86amlhbmdzaGVuZ0BodWF3ZWkuY29tIiBjbGFzcz0iIj5qaWFuZ3NoZW5nQGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0i cGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTNw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gNy41cHQ7IHRleHQtYWxpZ246IGxlZnQ7IGZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYmFja2dy b3VuZC1jb2xvcjogd2hpdGU7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsg YmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBNb25hY287IGNvbG9yOiByZ2Io NTEsIDUxLCA1MSk7IiBjbGFzcz0iIj5IaSwgYWxsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46IDBj bSAwY20gNy41cHQ7IHRleHQtYWxpZ246IGxlZnQ7IGZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGJhY2tn cm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRp YWwgaW5pdGlhbDsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBNb25hY287IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IiBjbGFzcz0iIj48 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA3LjVwdDsgdGV4dC1hbGlnbjog bGVmdDsgZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBp bml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IE1vbmFjbzsgY29s b3I6IHJnYig1MSwgNTEsIDUxKTsiIGNsYXNzPSIiPkdpdmVuIHRoZXJlIGlzIG5vIG5lZ2F0aXZl IHJlc3BvbnNlIHRvIHRoZSBXR0xDIG9uIGRyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci0wMyBhbmQg d2UgZGlkIHJlY2VpdmUgZ29vZCByZXZpZXdzIHRocm91Z2ggdGhlIFdHIGRvY3VtZW50IHN0YWdl IGFuZCBjb25zaWRlcmluZyB0aGUNCiBwYXN0IGhpc3Rvcnkgb2YgdGhpcyB3b3JrLCB0aGUgQU5J TUEgY2hhaXJzIGZlZWwgaXQgaXMgaGFzIHBhc3NlZCB0aGUgV0dMQyBhbmQgc2hvdWxkIGFkdmFu Y2UuIFRoaXMgY29uY2x1c2lvbiBpcyBtYWRlIHdpdGggdGhlIGNvbmRpdGlvbiB0aGF0IHRoZSBh dXRob3JzIHdvdWxkIHNvbHZlIHRoZSBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIFdHTEMg YW5kIHRoZXNlIG1vZGlmaWNhdGlvbnMgd2VyZSBub3Qgc3Vic3RhbnRpYWwgY2hhbmdlcw0KIGZy b20gMDMgdmVyc2lvbi4gSWYgdGhlcmUgYXJlIGJpZyBjaGFuZ2VzLCBhIHNob3J0ZXIgc2Vjb25k IFdHTEMgbWF5IGJlIG5lZWRlZC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA3LjVw dDsgdGV4dC1hbGlnbjogbGVmdDsgZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3Np dGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFs OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IE1vbmFjbzsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJs ZWZ0IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDcuNXB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJhY2tncm91 bmQtY29sb3I6IHdoaXRlOyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJh Y2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogTW9uYWNvOyBjb2xvcjogcmdiKDUx LCA1MSwgNTEpOyIgY2xhc3M9IiI+T25jZSB0aGUgdXBkYXRlIGlzIHB1Ymxpc2hlZCBhbmQgaXQg bWVldHMgdGhlIGFib3ZlIGNvbmRpdGlvbiwgZm9yIHdoaWNoIHRoZSBzZWNvbmQgV0dMQyBpcyBu b3QgbmVlZGVkLCBhcyBzaGVwaGVyZCwgU2hlbmcgSmlhbmcgd2lsbCBmaW5hbGl6ZSB0aGUgc2hl cGhlcmQgZG9jdW1lbnQNCiBhbmQgc2VuZCB0aGUgZG9jdW1lbnQgb24uPG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gNy41cHQ7IHRleHQtYWxpZ246IGxlZnQ7IGZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjog d2hpdGU7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1y ZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBNb25hY287IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA3LjVwdDsg dGV4dC1hbGlnbjogbGVmdDsgZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlv bjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IE1vbmFjbzsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsiIGNsYXNzPSIiPkJlc3QgcmVnYXJkcyw8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSA3LjVwdDsgdGV4dC1hbGlnbjogbGVmdDsg Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBiYWNr Z3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFs OyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IE1vbmFjbzsgY29sb3I6IHJn Yig1MSwgNTEsIDUxKTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDcuNXB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBiYWNr Z3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0 aWFsIGluaXRpYWw7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogTW9uYWNvOyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyIgY2xhc3M9IiI+ VG9lcmxlc3MgJmFtcDsgU2hlbmc8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHRleHQtYWxpZ246IGp1c3RpZnk7IGZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNv bGFzOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IENvbnNvbGFzOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTog MTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+QW5pbWENCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOkFuaW1hQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFt aWx5OiBDb25zb2xhczsgZm9udC1zaXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogQ29uc29s YXM7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWls eTogQ29uc29sYXM7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_818D85B2F5DB4253A4D12B344CD273CAciscocom_-- From nobody Tue Jun 27 16:50:25 2017 Return-Path: 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 A90DB12708C for ; Tue, 27 Jun 2017 16:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 pSKePrqT3H46 for ; Tue, 27 Jun 2017 16:50:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3126126B7F for ; Tue, 27 Jun 2017 16:50:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 96A63E222; Tue, 27 Jun 2017 19:52:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A24E636BB; Tue, 27 Jun 2017 19:50:19 -0400 (EDT) From: Michael Richardson To: anima@ietf.org CC: max pritikin In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 27 Jun 2017 19:50:19 -0400 Message-ID: <6464.1498607419@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] [anima-wg/anima-bootstrap] clarify "serial-number" field for pledge signed uses (#6) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 23:50:22 -0000 {responding to the github updates} Max Pritikin wrote: > The pledge puts the 'pinned-domain-cert' as seen in the provisional > TLS. The contents of this is an entire 5280 Certificate, as we say in the yang. It might be worth stating where in the TLS it comes from. I feel that "RFC5280 Section 4" might be augmented with the noun "Certificate" > The registrar puts the 'idev-id-issuer', and 'serial-number' as seen > in the provisional TLS. ("idevid-issuer" is the spelling we have, btw) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Jun 28 08:45:54 2017 Return-Path: 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 56284129B2D for ; Wed, 28 Jun 2017 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 AT4QX_TPIYY8 for ; Wed, 28 Jun 2017 08:45:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7AC129B31 for ; Wed, 28 Jun 2017 08:45:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPZ55235; Wed, 28 Jun 2017 15:45:48 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml708-cah.china.huawei.com ([10.201.108.49]) with mapi id 14.03.0301.000; Wed, 28 Jun 2017 16:45:42 +0100 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: Object store and PubSub model Thread-Index: AdLwIHL21vHVoA6MR0+KzxxjTjov+w== Date: Wed, 28 Jun 2017 15:45:42 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AE9BF3C@lhreml501-mbx> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5953CF2C.021F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 340b8294cf8e7f79a83919e8ca8f6e0d Archived-At: Subject: [Anima] Object store and PubSub model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:45:52 -0000 Dear ANIMA community, Please allow these two questions, which popped up while following recent gr= oup discussions and I-Ds: 1. Would the group consider an ANIMA-integrated data storage to be relevant= in the context of the current charter, or, otherwise, does it look like a = relevant topic for the planned re-chartering? Background: The idea for an integrated distributed storage in ANIMA could b= e motivated e.g. through network-wide configuration, where data objects wou= ld become available to all individual nodes and ASAs without relying on any= means external to ANIMA (like specialized nodes with specialized ASAs, or = similar). As another example, it seems ANIMA nodes might need to store data= in the case of e.g. intent distribution, as intents could be conditional a= nd shifted in time, like in "Do this, once this and that have materialized"= (see e.g. ECA in SUPA). 2. In a similar vein, does a publish/subscribe information distribution mod= el, built upon an underlying storage, look promising and relevant to the gr= oup? Can GRASP support that or will it require extensions? The pub/sub is, = in our opinion, a more general information distribution model than what we = saw in the current work stream. Yet, before submitting a draft that details= such a model, we wanted to kindly ask for your opinion on that.=20 Kind regards artur From nobody Wed Jun 28 13:35:24 2017 Return-Path: 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 79B9E12EB40 for ; Wed, 28 Jun 2017 13:35:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 b2imr5Gd-Yxw for ; Wed, 28 Jun 2017 13:35:06 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 A60E812EB14 for ; Wed, 28 Jun 2017 13:35:05 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id f127so9363163pgc.2 for ; Wed, 28 Jun 2017 13:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=stl5rHLS6uoy8SxtFMcqNyeW6SW079dd50+xVmz77cQ=; b=jAarzK9CFBU5nbc1PUmdjBgLldHD0zZSEbNNxAjvps32NZP8obXmJ61U+0xa62Wi7E 3JoD9G19xqEKfW9f/ViGuhU7y0IZul3zt44P4CpqFJntme0RTYu320cWizmX9m3oMAIO HIGoBxcc+YcphOFQrXD5P5KNwB+PL2yw8GCe7kqm55+cii2glSowp3+7em5vX3A8y49T eoTrWOjwpxw0d23oy/tqY32RkeY6LEz3Jxg9DgiJVgrUThrOPm+fvwTpAbrgTe6/Md1z nmVLP9HKtzhSxC/ykJNGoIzKsHgqmx7wvK8+h6mbLvOdKT9atv4PqXoUg0LQ3radHIqL Sn3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=stl5rHLS6uoy8SxtFMcqNyeW6SW079dd50+xVmz77cQ=; b=guktCQ/07KY21t+KnVdEIYq0kYvs+5JrRkieqTqbnF89NeEs721KugW4+7hxXT35xA FCwmRYy0DY/EoxCYO2cfHWcNcCleczG2HbAkAKOcskNgf2kE21OB4lNehkVsPSRfbx85 5QZSkRVU7FAIK6uhMtBYl9uzTH9M6EmkvcL/oVNvB+qp3YAvvzjApSqnvMdZ2HNE/jOV GkDDfcaNQdaIPVsbR1c75Ua5drOPXvrf0R7Bgujv+tC/01u0TOebcs0gWdED4P41F2Ig AX0oFYvkdcA/BTPDBDkugO8WRe/gvtK2szi6tmMvMEhGKyVv1LyWOfvdW0K8w7zFc/x0 24xA== X-Gm-Message-State: AKS2vOztDUu4bIK0Dl3NT5cp5s+tV21u2N3Lq+VkIp8HP+ikd/oYQgAu LW5fryDsUVoHOyyv X-Received: by 10.84.136.129 with SMTP id 1mr13859036pll.39.1498682104923; Wed, 28 Jun 2017 13:35:04 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id y185sm5550153pgb.9.2017.06.28.13.35.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 13:35:04 -0700 (PDT) To: Artur Hecker , "anima@ietf.org" References: <8DA547FB1280754AAC43A3E56DCB7AD20AE9BF3C@lhreml501-mbx> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5b4d5e34-e904-e2e6-18b1-06978b62bf95@gmail.com> Date: Thu, 29 Jun 2017 08:35:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8DA547FB1280754AAC43A3E56DCB7AD20AE9BF3C@lhreml501-mbx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Object store and PubSub model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 20:35:08 -0000 On 29/06/2017 03:45, Artur Hecker wrote: > Dear ANIMA community, > > > Please allow these two questions, which popped up while following recent group discussions and I-Ds: > > 1. Would the group consider an ANIMA-integrated data storage to be relevant in the context of the current charter, or, otherwise, does it look like a relevant topic for the planned re-chartering? > > Background: The idea for an integrated distributed storage in ANIMA could be motivated e.g. through network-wide configuration, where data objects would become available to all individual nodes and ASAs without relying on any means external to ANIMA (like specialized nodes with specialized ASAs, or similar). As another example, it seems ANIMA nodes might need to store data in the case of e.g. intent distribution, as intents could be conditional and shifted in time, like in "Do this, once this and that have materialized" (see e.g. ECA in SUPA). So far, I don't believe we've discussed distributed storage as such. It would be a natural part of the discussion of intent. We have tended to assume that intent originates centrally, so it needs a replication model rather than distributed storage in the general sense. The simplest replication model is of course flooding, which we already have for relatively small data objects. For example, GRASP as it exists today could flood an objective whose value is the URL of the latest intent for the whole network. I would not advocate developing a distributed storage model specific to Anima. Rather, if we decided it was necessary, IMHO we should adopt an existing solution, since this is not a trivial problem. > > 2. In a similar vein, does a publish/subscribe information distribution model, built upon an underlying storage, look promising and relevant to the group? Can GRASP support that or will it require extensions? The pub/sub is, in our opinion, a more general information distribution model than what we saw in the current work stream. Yet, before submitting a draft that details such a model, we wanted to kindly ask for your opinion on that. Have you studied draft-liu-anima-grasp-distribution? But first, what sort of autonomic use cases would require distributed storage or a pub/sub solution? Regards Brian From nobody Wed Jun 28 19:44:14 2017 Return-Path: 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 E51B5126C22 for ; Wed, 28 Jun 2017 19:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OCluJc6dIdrr for ; Wed, 28 Jun 2017 19:44:09 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 457BE12420B for ; Wed, 28 Jun 2017 19:44:09 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id j186so40571054pge.2 for ; Wed, 28 Jun 2017 19:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+2fVICFkT7spiyhiSRZ4DB1qIiruikhtcpEH1Nv0Qlk=; b=k3CVVHqP4wJekb3/KIt1lCKjKAf3Ed0LVChpEC+jhBfrmQmg0U01IBPlfs6cUpPUJ9 C5Ebwx6xGV0sIE+uYOHrqacjJomaS9ssEjddV1zPPgtZ1ZnsSEgKGg06UVyR7kE/qwVG u2ESjgP+vGI6Uj7PfZiJec33zza5lN8kElorxaUUa8okTooHRdGf1BbF1tDfFQZGtX4n gDTgif8l43JpRSq53arQzQr8S1RLsKPMS9ZZwoXPS25+rZ7YHJLzYTpaoZaOstAI+TUD IGRMm2Dy93Ydk+BENnGZ6X9C9N59/Mursfs62iD8RYyOhn07g3Kkela2FSG6rOmotSul RQAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+2fVICFkT7spiyhiSRZ4DB1qIiruikhtcpEH1Nv0Qlk=; b=teb59EAQ5++d1KdQBpGyCejRjlK4BDhtSyMCS7pCPoWoz/KsFf7mvxLvZ5Aqre507q uUQX6/lns8/CXOOIHVOmJMGTKlRgdjQEef0qRimCFhreNihlm91SfZ4MemPwXDYzqwUi UriTSzN6yaww3mCmx0gH2ZD5LcEkcrdkY6+CgYsysyz+36JI7giLjJl9N09baPPubkyQ 9/xuQMOPgs7QHWs0yGu4fe1IRw1WeoWKC2ed+EuiIwfHKSWXoDRtSdQPOMZbZlt4iKp0 HCdWvJ4EGOZElqzcYr1poamdq9/hZfmkjnoyvjVLM+kOQR9VLyg0bhn07ZTsuP1l++LL T4KQ== X-Gm-Message-State: AKS2vOx8pYVVoBe8om9mOt/EIkJGGtpEcL5cJSz/74c0B6aF05RKpRGT MDwAJjGhJoSbcq3/ X-Received: by 10.98.96.66 with SMTP id u63mr13868791pfb.13.1498704248339; Wed, 28 Jun 2017 19:44:08 -0700 (PDT) Received: from [192.168.178.21] (28.216.69.111.dynamic.snap.net.nz. [111.69.216.28]) by smtp.gmail.com with ESMTPSA id d2sm8199124pfb.49.2017.06.28.19.44.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 19:44:07 -0700 (PDT) To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> Date: Thu, 29 Jun 2017 14:44:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 02:44:13 -0000 I had a look at both sets of changes and they seem good to me. I find myself wondering, after seeing the slightly confused text about GRASP objectives in the latest BRSKI, and noting the absence of such objectives in the ACP and stable-connectivity drafts, whether we should accept that we need a specialised draft for all the GRASP objectives needed by the ANI. Strangely enough, we have such a draft already: https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 My idea was for this to be a temporary draft, with its contents being moved into BSRKI, ACP and stable-connectivity. But would it be more practical to keep it as a separate draft? It makes the other three drafts a bit more self-contained, and allows for a consistent definition of the infrastructure objectives. What to do people think? (Disregard the current details in draft-carpenter-anima-ani-objectives, which has not been updated recently.) Regards Brian On 27/06/2017 16:21, Toerless Eckert wrote: > Thanks a lot, Sheng! > > Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft > into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up > having to do a fix for the ACP draft as a result of your comments. > > Diff between -02 and fixed up stable connectivity draft here: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt > > If you are fine with the fixes let me know, and i'll push it to datatracker as -03. > > If not ok. feel free to use email or now also add issue to the git. > > Raw txt/git files of fixed stable connectivity text: > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml > > Diff for change done in ACP (explaining ACP connect better): > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt > > Cheers > Toerless > > On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: >> Hi, authors of draft-ietf-anima-stable-connectivity, >> >> I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. >> >> First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section. > > Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise > customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There > was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing > challenges with IPv6 only management planes. > > I have added paragraphs to justify the need for this section and that its all undesirable workarounds > Please check. To me, this messy section is the price we have to pay so that the ACP > can simply be IPv6 only. Its a price i am happy to pay. > >> Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. > > I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology. > >> Point 2 is a precondition (it is actually conflicted with section 2.1.4.) > > Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4. > >> I don't understand point 4. What does "exposing the ACP natively" mean? > > That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity. > > Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft. > >> Thirdly, I have issues to use names to distinguish the path selection policies. >> This is a chicken&egg issue in the autonomic scenario. >> Who and how the DNS names are setup, by human administrator? > > IMHO, considerations for names are one of the most crucial part of > operationalizing the ACP. The little text we have about the ACP is IMHO > a good compromise between overlooking the problem and writing a lot more > text. > > The concept of using different addresses for a device for different actions > is not novel to ACP. Think of using a loopback to "reliably" talk to a router > vs. ping'ing specific interface addresses of a router to discover whether > an peer (reachable via that interface) is up/down. If you look at service > providers name setups (often in DNS), then they will have different names > for those different addresses and use those different names in the different > tools. The text in this draft simply explains the same concept for > ACP vs. other addresses. > > DNS names can be setup by various locally built automation scripting or templates. > Same think for DNS names for ACP. Operators will likely point out that automating > the DNS name creation is more difficult because we do not use topology/semantic > ACP addresses, but in principle it's the same automation task. > >> If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? > > ALl the existing "actions" that you want to do for a device are just too stupid: > They do not include the logic of knowing which address is best for them to > use. That's why you use names for subsets of the possible addresses to allow > you to specify exatly those address(es) that will reach the device via the > network connection matching the intent of the action you're taking. > >> DNS registration & lookup by itself is a very complex and time-consumption procedure. > > Depends on your automation. Its certainly an interesting aspect especially moving > from IPv4 to IPv6 where embedding logic into adresses becomes a whole different > ballgame. > >> If we don't want to show the semantic of these addresses to any human, names are meaningless. > > But you need new NOC tools where each action would need to know what type > of connection is best for it. > > I have added one paragraph to 2.1.5 to outline this logic and justification for why > to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device" > > >> In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP. > > Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor > discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure > connectivity for functions running distributed in network devices (GRASP via ACP). > >> At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface. > > Ack. Changed text to: A workaround without additional software functionality could be a physical external loopback > cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture. A (virtual) > software loopback between the ACP and data plane VRF would of course be the better solution. > > The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested. > >> Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment > > Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components). > > Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter. > >> Minor comments, >> >> Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess. > > The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph: > > This section describes stable connectibity for centralized OAM operations via ACP/ANI > starting by what we expect to be the most likely easiest short-term deployment option. It > then describes limitation/challenges of that approach and their solutions/workarounds to finish > with the preferred target option of autonomic NOC devices in . > > This order was choosen because it helps to explain how simple one can start using the ACP, > how difficult workarounds can become (and therefore what to avoid), and finally because one very > promising long-term solution alternative is exactly like the most easy short-term solution only virtualized > and automated. > > The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow... > >> It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed. > > Good point. Added the following sentence: > > Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only. > >> The document does not properly quota references in the text. The references defined are mostly not used. > > Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-) > >> The document separate sections for Informative/Normative References > > Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational. > >> The empty section 5 "Further considerations", should be removed. > > Done. > >> Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575. > > Fixed. > >> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"? > > added: Examples include change of IGP protocols or areas, PD (Provider > Dependent) to PI (Provider Independent) addressing, systematic topology changes. > >> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks" > > Done > >> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances. > > Done, added RFC references for those TLAs that have them as well. > >> Last sentence of section 2.2 should be removed. > > Done. > >> In section 3, first sentence, add "In this section," > > Done. > >> There are typos, needed to be fixed too: >> >> Two "the the" in the end of section 2.1.2 and end of section 4; > > Done >> >> A couple of "randomn" -> "random"; > > Done >> >> "networ" in section 2.1.5; > > Done >> >> "jut" -> "just" at the end of section 2.1.6, I guess. >> >> "The most simple" -> "the simplest" in section 2.17. > > Done. > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Jun 28 23:17:59 2017 Return-Path: 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 64CC4128792; Wed, 28 Jun 2017 23:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 1PgnXXPSD5PT; Wed, 28 Jun 2017 23:17:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8B7126E3A; Wed, 28 Jun 2017 23:17:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJJ65854; Thu, 29 Jun 2017 06:17:51 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 29 Jun 2017 07:17:50 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 29 Jun 2017 14:17:42 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" CC: Terry Manderson , "anima-chairs@ietf.org" Thread-Topic: [Anima] Review of draft-ietf-anima-stable-connectivity-02 Thread-Index: AdLpmz27hzNx1om7RNeFQD3MAwJWUAFHopUAAGEweAAAGA6RMA== Date: Thu, 29 Jun 2017 06:17:41 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDF240C@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> In-Reply-To: <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.59549B90.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 40f6426bdecb6dfa43822f4146fd21f4 Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 06:17:57 -0000 Hi, Brian, With my WG chair hat on, the situation regarding to these ANI objectives is= strange indeed. Could you please resubmit your anima-ani-objectives before= the deadline next Monday? Then, the chairs could discuss the situation wit= h our responsible AD. It looks that the easiest way is to adopt this draft = and quickly send it to IESG along with ACP and BRSKI. Cheers, Sheng > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Thursday, June 29, 2017 10:44 AM > To: anima@ietf.org > Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 >=20 > I had a look at both sets of changes and they seem good to me. >=20 > I find myself wondering, after seeing the slightly confused text about GR= ASP > objectives in the latest BRSKI, and noting the absence of such objectives= in the > ACP and stable-connectivity drafts, whether we should accept that we need= a > specialised draft for all the GRASP objectives needed by the ANI. >=20 > Strangely enough, we have such a draft already: > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 > My idea was for this to be a temporary draft, with its contents being mov= ed > into BSRKI, ACP and stable-connectivity. But would it be more practical t= o keep > it as a separate draft? It makes the other three drafts a bit more self-c= ontained, > and allows for a consistent definition of the infrastructure objectives. >=20 > What to do people think? >=20 > (Disregard the current details in draft-carpenter-anima-ani-objectives, > which has not been updated recently.) >=20 > Regards > Brian >=20 > On 27/06/2017 16:21, Toerless Eckert wrote: > > Thanks a lot, Sheng! > > > > Integrated fixes for all comments (see inline discuss below). Pushed > > stable connectivity draft into > > www.github.com/anima-wg/autonomic-control-plane together with ACP > draft because i ended up having to do a fix for the ACP draft as a result= of your > comments. > > > > Diff between -02 and fixed up stable connectivity draft here: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.git= h > > ubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-a > > nima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&u > > rl2=3Dhttps://raw.githubusercontent.com/anima-wg/autonomic-control-plan= e > > /master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-c > > onnectivity.txt > > > > If you are fine with the fixes let me know, and i'll push it to datatra= cker as -03. > > > > If not ok. feel free to use email or now also add issue to the git. > > > > Raw txt/git files of fixed stable connectivity text: > > > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/mas > > ter/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-conne > > ctivity.txt > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/mas > > ter/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-conne > > ctivity.xml > > > > Diff for change done in ACP (explaining ACP connect better): > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.git= h > > ubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-a > > nima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- > > 06.txt&url2=3Dhttps://raw.githubusercontent.com/anima-wg/autonomic-cont= r > > ol-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-an > > ima-autonomic-control-plane.txt > > > > Cheers > > Toerless > > > > On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: > >> Hi, authors of draft-ietf-anima-stable-connectivity, > >> > >> I am doing a thorough review as the document shepherd with my ANIMA > chair hat on. Please address the below comments so that we could process = this > document further. > >> > >> First, I have issues for section 2.1.4, "IPv4 only NOC application dev= ices". It > would be an unlike scenario to manage an IPv6 network (all managed device= s > are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, th= e > NAT64 setup in this scenario is complex, and connectivity between IPv4 on= ly > NOC application devices and NAT is unsecure. I would suggest to reduce th= e > whole section or add a clear statement that it is a not-recommended scena= rio > at the end of this section. > > > > Yes, it is a mess. But it is documenting an actual deployment > > experience with an enterprise customer. TAnd my understanding is tht > > it would be a quite common scenario for enterprises. There was just > > recently a very nice RTG area WG chair tutorial that to me reconfirmed = the > ongoing challenges with IPv6 only management planes. > > > > I have added paragraphs to justify the need for this section and that > > its all undesirable workarounds Please check. To me, this messy > > section is the price we have to pay so that the ACP can simply be IPv6 = only. Its > a price i am happy to pay. > > > >> Secondly, the description and category in section 2.1.2, "Limitations = and > enhancement overview". For me, only the point 1 & 3 are really limitation= of > ACP itself. > > > > I have improved the text and categorization in this chapter to make it > hopefully clearer to read and to be more precise in terminology. > > > >> Point 2 is a precondition (it is actually conflicted with section > >> 2.1.4.) > > > > Yes, IPv6 is a precondition. If a deployment can not meet this precondi= tion, > that is a challenge for which there is a workaround. Those workarounds ar= e > described in section 2.1.4. I've tried to improve all that text. I do not > understand why point 2 would be a conflict with section 2.1.4 instead of = rather > pointing to 2.1.4. > > > >> I don't understand point 4. What does "exposing the ACP natively" mean= ? > > > > That is the term that was defined in ACP CP draft, section 6.1. Reading > through that section, i improved it in the ACP section, and i updated the= text > about it in stable connectivity. > > > > Oh, and this change had me change the term "NOC application device" to > "NMS host" throughout the document because that is the term used in the A= CP > draft. > > > >> Thirdly, I have issues to use names to distinguish the path selection = policies. > >> This is a chicken&egg issue in the autonomic scenario. > >> Who and how the DNS names are setup, by human administrator? > > > > IMHO, considerations for names are one of the most crucial part of > > operationalizing the ACP. The little text we have about the ACP is > > IMHO a good compromise between overlooking the problem and writing a > > lot more text. > > > > The concept of using different addresses for a device for different > > actions is not novel to ACP. Think of using a loopback to "reliably" > > talk to a router vs. ping'ing specific interface addresses of a router > > to discover whether an peer (reachable via that interface) is up/down. > > If you look at service providers name setups (often in DNS), then they > > will have different names for those different addresses and use those > > different names in the different tools. The text in this draft simply > > explains the same concept for ACP vs. other addresses. > > > > DNS names can be setup by various locally built automation scripting or > templates. > > Same think for DNS names for ACP. Operators will likely point out that > > automating the DNS name creation is more difficult because we do not > > use topology/semantic ACP addresses, but in principle it's the same > automation task. > > > >> If there is a mechanism to distinguish the IP addresses of ACP and > data-plane without human intelligence, why does it bore to use DNS? > > > > ALl the existing "actions" that you want to do for a device are just to= o stupid: > > They do not include the logic of knowing which address is best for > > them to use. That's why you use names for subsets of the possible > > addresses to allow you to specify exatly those address(es) that will > > reach the device via the network connection matching the intent of the = action > you're taking. > > > >> DNS registration & lookup by itself is a very complex and time-consump= tion > procedure. > > > > Depends on your automation. Its certainly an interesting aspect > > especially moving from IPv4 to IPv6 where embedding logic into > > adresses becomes a whole different ballgame. > > > >> If we don't want to show the semantic of these addresses to any human, > names are meaningless. > > > > But you need new NOC tools where each action would need to know what > > type of connection is best for it. > > > > I have added one paragraph to 2.1.5 to outline this logic and > > justification for why to describe DNS. Look for "Ideally, a NOC system = would > learn and keep track of all addresses of a device" > > > > > >> In section 2.2, "The ACP can provide common direct-neighbor discovery = and > capability negotiation". This is a wrong statement. ANI does provide this= , but it > is done by GRASP, not ACP. > > > > Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the > > GRASP protocol common direct-neighbor discovery and capability > > negotiation (GRASP via ACP and/or data-plane) and stable and secure > connectivity for functions running distributed in network devices (GRASP = via > ACP). > > > >> At the end of section 2.1.3, "A simple short-term workaround could be = a > physical external loopback cable into two ports of ANrtr1 to connect the > data-plane and ACP VRF as shown in the picture." Does this has to be "a > PHYSICAL external loopback CABLE"? It sounds like a very strong requireme= nt. > Personally, I believe this could be done by a virtual loopback interface. > > > > Ack. Changed text to: A workaround without additional software > > functionality could be a physical external loopback cable into two > > ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the > picture. A (virtual) software loopback between the ACP and data plane VR= F > would of course be the better solution. > > > > The key notion why the "gross" physcial loopback may be appreciated is > because it doesn't require software work. Or specification of the behavio= r of > such a software loopback in the roting behavior in the ACP draft. I would= love to > have that software loopback, but i think we (ACP doc authors) felt that w= e > wanted to keep the ACP spec lightweight enough to be implementable withou= t > all possible enhancements. But i hope its fine to mention the option here= in this > document as you suggested. > > > >> Section 3, "Security considerations" is more like a deployment > >> considerations. Both ULA-C and reverse DNS are additional deployment > > > > Yes, but i think if you look through various IETF documents you will se= e that it > is quite common for security consideration sections to outline additional= steps > to secure the documents work goal especially when those steps are otherwi= se > orthogonal to the documents spec (eg: leverage existing components). > > > > Whats the process for informational documents. It will get SEC AD revie= w, > right ? Maybe hold that thought for that review ? Or else i can proactive= ly ask, > because right now i am a bit at a loss whats the right limit of what to p= ut into > sec considerations vs. what to extract into a separate chapter. > > > >> Minor comments, > >> > >> Section 2.1.6, "Autonomic NOC device/applications" should be moved to > early part of this document. For me, it is the default scenario/requireme= nt. It > should be section 2.1.1, I guess. > > > > The text unfortunately builds up in the order it is written, so it woul= d be a lot > of rewrite to make sure it would still read after such a reordering. Inst= ead i > have added the following as the first paragraph: > > > > This section describes stable connectibity for centralized OAM > > operations via ACP/ANI starting by what we expect to be the most > > likely easiest short-term deployment option. It then describes > > limitation/challenges of that approach and their solutions/workarounds > > to finish with the preferred target option of autonomic NOC devices in > > . > > > > This order was choosen because it helps to explain how simple one > > can start using the ACP, how difficult workarounds can become (and > > therefore what to avoid), and finally because one very promising > > long-term solution alternative is exactly like the most easy > > short-term solution only virtualized and automated. > > > > The last sentence is that punchline: The likely easiest/best atonomic N= OC > device solution is one where you do everything you do in the short-term > approach, just virtualized and integrated into the NOC device. WHich mean= s > you'd need to explain all that stuff anyhow... > > > >> It is worth of mentioning even the ACP provides only IPv6 connectivity= , > through it, IPv4 configuration or even non-IP configuration could be mana= ged. > > > > Good point. Added the following sentence: > > > > Note that even though the ACP only uses IPv6, it can and should be > > used to providestable connectivity for management of any network: IPv4 > > only, dual-stack or IPv6 only. > > > >> The document does not properly quota references in the text. The > references defined are mostly not used. > > > > Ack. Removed unnecessary references, introduced terms/references in > > the beginning of the document. All references now used at least once > > ;-) > > > >> The document separate sections for Informative/Normative References > > > > Hmm. It DOES NOT distinguish between normative and informational > documents because i thought that an informational document like this coul= d > not have normative references. If it can and should have them let me know= , > then i'll make Bootstrap/Grasp/ACP normative and reference/definitions > informational. > > > >> The empty section 5 "Further considerations", should be removed. > > > > Done. > > > >> Most of references are out of date. behringer-anima-reference-model > > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, > irtf-nmrg-autonomic-network-definitions > RFC 7575. > > > > Fixed. > > > >> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in t= he > infrastructure design." What is the mean for "other mayor"? > > > > added: Examples include change of IGP protocols or areas, PD (Provider > > Dependent) to PI (Provider Independent) addressing, systematic topology > changes. > > > >> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" > may be better to presented as "the Autonomic Control plane (ACP) in > Autonomic Networks" > > > > Done > > > >> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3= , AT" in > section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in se= ction > 2.1.5, "KARP" in section 2.2, even the first appearances. > > > > Done, added RFC references for those TLAs that have them as well. > > > >> Last sentence of section 2.2 should be removed. > > > > Done. > > > >> In section 3, first sentence, add "In this section," > > > > Done. > > > >> There are typos, needed to be fixed too: > >> > >> Two "the the" in the end of section 2.1.2 and end of section 4; > > > > Done > >> > >> A couple of "randomn" -> "random"; > > > > Done > >> > >> "networ" in section 2.1.5; > > > > Done > >> > >> "jut" -> "just" at the end of section 2.1.6, I guess. > >> > >> "The most simple" -> "the simplest" in section 2.17. > > > > Done. > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Jun 29 00:39:17 2017 Return-Path: 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 BD39A12706D; Thu, 29 Jun 2017 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 JvF-xWZ8EnZo; Thu, 29 Jun 2017 00:39:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E57A128B8D; Thu, 29 Jun 2017 00:39:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJJ78308; Thu, 29 Jun 2017 07:39:08 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 29 Jun 2017 08:39:06 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 29 Jun 2017 15:39:01 +0800 From: Sheng Jiang To: Toerless Eckert CC: Anima WG , "anima-chairs@ietf.org" Thread-Topic: [Anima] Review of draft-ietf-anima-stable-connectivity-02 Thread-Index: AdLpmz27hzNx1om7RNeFQD3MAwJWUAFHopUAABiSy9A= Date: Thu, 29 Jun 2017 07:39:00 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDF2525@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5954AE9D.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 40f6426bdecb6dfa43822f4146fd21f4 Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:39:17 -0000 Hi, Toerless, Thanks for addressing my review comments. The new version looks good to be = apart from that I am still have concern regarding to use names to distingui= sh the path selection policies, particularly the necessity of this solution= . However, with the newly added text and the possibility that there may be = solutions for autonomic naming, I can hold my opinion on this as a personal= observation. Please go ahead to submit the latest version. We could have t= he WGLC based on the new version. Thanks and regards, Sheng > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: Tuesday, June 27, 2017 12:21 PM > To: Sheng Jiang > Cc: Anima WG; anima-chairs@ietf.org > Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 >=20 > Thanks a lot, Sheng! >=20 > Integrated fixes for all comments (see inline discuss below). Pushed stab= le > connectivity draft into www.github.com/anima-wg/autonomic-control-plane > together with ACP draft because i ended up having to do a fix for the ACP= draft > as a result of your comments. >=20 > Diff between -02 and fixed up stable connectivity draft here: >=20 > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.githu= buserconte > nt.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-co= n > nectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=3Dhttps://raw.= githubus > ercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-st > able-connectivity/draft-ietf-anima-stable-connectivity.txt >=20 > If you are fine with the fixes let me know, and i'll push it to datatrack= er as -03. >=20 > If not ok. feel free to use email or now also add issue to the git. >=20 > Raw txt/git files of fixed stable connectivity text: >=20 > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/maste > r/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivi= ty.txt > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/maste > r/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivi= ty.xml >=20 > Diff for change done in ACP (explaining ACP connect better): >=20 > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://raw.githu= buserconte > nt.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomi > c-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=3Dht= tps://r > aw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-i > etf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plan= e.t > xt >=20 > Cheers > Toerless >=20 > On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: > > Hi, authors of draft-ietf-anima-stable-connectivity, > > > > I am doing a thorough review as the document shepherd with my ANIMA > chair hat on. Please address the below comments so that we could process = this > document further. > > > > First, I have issues for section 2.1.4, "IPv4 only NOC application devi= ces". It > would be an unlike scenario to manage an IPv6 network (all managed device= s > are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, th= e > NAT64 setup in this scenario is complex, and connectivity between IPv4 on= ly > NOC application devices and NAT is unsecure. I would suggest to reduce th= e > whole section or add a clear statement that it is a not-recommended scena= rio > at the end of this section. >=20 > Yes, it is a mess. But it is documenting an actual deployment experience = with > an enterprise customer. TAnd my understanding is tht it would be a quite > common scenario for enterprises. There was just recently a very nice RTG = area > WG chair tutorial that to me reconfirmed the ongoing challenges with IPv6= only > management planes. >=20 > I have added paragraphs to justify the need for this section and that its= all > undesirable workarounds Please check. To me, this messy section is the pr= ice > we have to pay so that the ACP can simply be IPv6 only. Its a price i am = happy to > pay. >=20 > > Secondly, the description and category in section 2.1.2, "Limitations a= nd > enhancement overview". For me, only the point 1 & 3 are really limitation= of > ACP itself. >=20 > I have improved the text and categorization in this chapter to make it ho= pefully > clearer to read and to be more precise in terminology. >=20 > > Point 2 is a precondition (it is actually conflicted with section > > 2.1.4.) >=20 > Yes, IPv6 is a precondition. If a deployment can not meet this preconditi= on, that > is a challenge for which there is a workaround. Those workarounds are > described in section 2.1.4. I've tried to improve all that text. I do not > understand why point 2 would be a conflict with section 2.1.4 instead of = rather > pointing to 2.1.4. >=20 > > I don't understand point 4. What does "exposing the ACP natively" mean? >=20 > That is the term that was defined in ACP CP draft, section 6.1. Reading t= hrough > that section, i improved it in the ACP section, and i updated the text ab= out it in > stable connectivity. >=20 > Oh, and this change had me change the term "NOC application device" to > "NMS host" throughout the document because that is the term used in the A= CP > draft. >=20 > > Thirdly, I have issues to use names to distinguish the path selection p= olicies. > > This is a chicken&egg issue in the autonomic scenario. > > Who and how the DNS names are setup, by human administrator? >=20 > IMHO, considerations for names are one of the most crucial part of > operationalizing the ACP. The little text we have about the ACP is IMHO a= good > compromise between overlooking the problem and writing a lot more text. >=20 > The concept of using different addresses for a device for different actio= ns is not > novel to ACP. Think of using a loopback to "reliably" talk to a router vs= . ping'ing > specific interface addresses of a router to discover whether an peer (rea= chable > via that interface) is up/down. If you look at service providers name set= ups > (often in DNS), then they will have different names for those different > addresses and use those different names in the different tools. The text = in this > draft simply explains the same concept for ACP vs. other addresses. >=20 > DNS names can be setup by various locally built automation scripting or > templates. > Same think for DNS names for ACP. Operators will likely point out that > automating the DNS name creation is more difficult because we do not use > topology/semantic ACP addresses, but in principle it's the same automatio= n > task. >=20 > > If there is a mechanism to distinguish the IP addresses of ACP and data= -plane > without human intelligence, why does it bore to use DNS? >=20 > ALl the existing "actions" that you want to do for a device are just too = stupid: > They do not include the logic of knowing which address is best for them t= o use. > That's why you use names for subsets of the possible addresses to allow y= ou to > specify exatly those address(es) that will reach the device via the netwo= rk > connection matching the intent of the action you're taking. >=20 > > DNS registration & lookup by itself is a very complex and time-consumpt= ion > procedure. >=20 > Depends on your automation. Its certainly an interesting aspect especiall= y > moving from IPv4 to IPv6 where embedding logic into adresses becomes a > whole different ballgame. >=20 > > If we don't want to show the semantic of these addresses to any human, > names are meaningless. >=20 > But you need new NOC tools where each action would need to know what type > of connection is best for it. >=20 > I have added one paragraph to 2.1.5 to outline this logic and justificati= on for > why to describe DNS. Look for "Ideally, a NOC system would learn and keep > track of all addresses of a device" >=20 >=20 > > In section 2.2, "The ACP can provide common direct-neighbor discovery a= nd > capability negotiation". This is a wrong statement. ANI does provide this= , but it > is done by GRASP, not ACP. >=20 > Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRAS= P > protocol common direct-neighbor discovery and capability negotiation (GRA= SP > via ACP and/or data-plane) and stable and secure connectivity for functio= ns > running distributed in network devices (GRASP via ACP). >=20 > > At the end of section 2.1.3, "A simple short-term workaround could be a > physical external loopback cable into two ports of ANrtr1 to connect the > data-plane and ACP VRF as shown in the picture." Does this has to be "a > PHYSICAL external loopback CABLE"? It sounds like a very strong requireme= nt. > Personally, I believe this could be done by a virtual loopback interface. >=20 > Ack. Changed text to: A workaround without additional software functional= ity > could be a physical external loopback cable into two ports of ANrtr1 to c= onnect > the data-plane and ACP VRF as shown in the picture. A (virtual) software > loopback between the ACP and data plane VRF would of course be the better > solution. >=20 > The key notion why the "gross" physcial loopback may be appreciated is > because it doesn't require software work. Or specification of the behavio= r of > such a software loopback in the roting behavior in the ACP draft. I would= love to > have that software loopback, but i think we (ACP doc authors) felt that w= e > wanted to keep the ACP spec lightweight enough to be implementable withou= t > all possible enhancements. But i hope its fine to mention the option here= in this > document as you suggested. >=20 > > Section 3, "Security considerations" is more like a deployment > > considerations. Both ULA-C and reverse DNS are additional deployment >=20 > Yes, but i think if you look through various IETF documents you will see = that it is > quite common for security consideration sections to outline additional st= eps to > secure the documents work goal especially when those steps are otherwise > orthogonal to the documents spec (eg: leverage existing components). >=20 > Whats the process for informational documents. It will get SEC AD review, > right ? Maybe hold that thought for that review ? Or else i can proactive= ly ask, > because right now i am a bit at a loss whats the right limit of what to p= ut into > sec considerations vs. what to extract into a separate chapter. >=20 > > Minor comments, > > > > Section 2.1.6, "Autonomic NOC device/applications" should be moved to e= arly > part of this document. For me, it is the default scenario/requirement. It= should > be section 2.1.1, I guess. >=20 > The text unfortunately builds up in the order it is written, so it would = be a lot of > rewrite to make sure it would still read after such a reordering. Instead= i have > added the following as the first paragraph: >=20 > This section describes stable connectibity for centralized OAM operati= ons > via ACP/ANI starting by what we expect to be the most likely easiest > short-term deployment option. It then describes limitation/challenges of = that > approach and their solutions/workarounds to finish with the preferred tar= get > option of autonomic NOC devices in .= >=20 > This order was choosen because it helps to explain how simple one can = start > using the ACP, how difficult workarounds can become (and therefore what t= o > avoid), and finally because one very promising long-term solution alterna= tive is > exactly like the most easy short-term solution only virtualized and > automated. >=20 > The last sentence is that punchline: The likely easiest/best atonomic NOC > device solution is one where you do everything you do in the short-term > approach, just virtualized and integrated into the NOC device. WHich mean= s > you'd need to explain all that stuff anyhow... >=20 > > It is worth of mentioning even the ACP provides only IPv6 connectivity, > through it, IPv4 configuration or even non-IP configuration could be mana= ged. >=20 > Good point. Added the following sentence: >=20 > Note that even though the ACP only uses IPv6, it can and should be use= d to > providestable connectivity for management of any network: IPv4 only, > dual-stack or IPv6 only. >=20 > > The document does not properly quota references in the text. The refere= nces > defined are mostly not used. >=20 > Ack. Removed unnecessary references, introduced terms/references in the > beginning of the document. All references now used at least once ;-) >=20 > > The document separate sections for Informative/Normative References >=20 > Hmm. It DOES NOT distinguish between normative and informational > documents because i thought that an informational document like this coul= d > not have normative references. If it can and should have them let me know= , > then i'll make Bootstrap/Grasp/ACP normative and reference/definitions > informational. >=20 > > The empty section 5 "Further considerations", should be removed. >=20 > Done. >=20 > > Most of references are out of date. behringer-anima-reference-model > > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, > irtf-nmrg-autonomic-network-definitions > RFC 7575. >=20 > Fixed. >=20 > > In section 1.1, "the introduction of IPv6 or other mayor re-hauls in th= e > infrastructure design." What is the mean for "other mayor"? >=20 > added: Examples include change of IGP protocols or areas, PD (Provider > Dependent) to PI (Provider Independent) addressing, systematic topology > changes. >=20 > > In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" > may be better to presented as "the Autonomic Control plane (ACP) in > Autonomic Networks" >=20 > Done >=20 > > There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3,= AT" in > section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in se= ction > 2.1.5, "KARP" in section 2.2, even the first appearances. >=20 > Done, added RFC references for those TLAs that have them as well. >=20 > > Last sentence of section 2.2 should be removed. >=20 > Done. >=20 > > In section 3, first sentence, add "In this section," >=20 > Done. >=20 > > There are typos, needed to be fixed too: > > > > Two "the the" in the end of section 2.1.2 and end of section 4; >=20 > Done > > > > A couple of "randomn" -> "random"; >=20 > Done > > > > "networ" in section 2.1.5; >=20 > Done > > > > "jut" -> "just" at the end of section 2.1.6, I guess. > > > > "The most simple" -> "the simplest" in section 2.17. >=20 > Done. >=20 From nobody Thu Jun 29 08:28:19 2017 Return-Path: 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 9D57F13146F for ; Thu, 29 Jun 2017 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 VuDtnZkLdJN9 for ; Thu, 29 Jun 2017 08:28:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681C112EC06 for ; Thu, 29 Jun 2017 08:28:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQB29843; Thu, 29 Jun 2017 15:28:14 +0000 (GMT) Received: from LHREML501-MBX.china.huawei.com ([10.201.109.49]) by lhreml703-cah.china.huawei.com ([10.201.108.44]) with mapi id 14.03.0301.000; Thu, 29 Jun 2017 16:28:08 +0100 From: Artur Hecker To: "anima@ietf.org" Thread-Topic: [Anima] Object store and PubSub model Thread-Index: AdLwIHL21vHVoA6MR0+KzxxjTjov+wAJTPmAAChM9GA= Date: Thu, 29 Jun 2017 15:28:08 +0000 Message-ID: <8DA547FB1280754AAC43A3E56DCB7AD20AE9D029@lhreml501-mbx> References: <8DA547FB1280754AAC43A3E56DCB7AD20AE9BF3C@lhreml501-mbx> <5b4d5e34-e904-e2e6-18b1-06978b62bf95@gmail.com> In-Reply-To: <5b4d5e34-e904-e2e6-18b1-06978b62bf95@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.231] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59551C8E.00CB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c9648508bd5d8dc9179cee2b7d95ac99 Archived-At: Subject: Re: [Anima] Object store and PubSub model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 15:28:19 -0000 RGVhciBCcmlhbiwgYWxsDQoNCg0KVGhhbmtzIGEgbG90IGZvciB0aGUgZXhwbGFuYXRpb25zLiBQ bGVhc2UgZmluZCBteSBhbnN3ZXJzIGJlbG93Og0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFp bC5jb21dIA0KU2VudDogMjggSnVuZSAyMDE3IDIyOjM1DQpUbzogQXJ0dXIgSGVja2VyOyBhbmlt YUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBbmltYV0gT2JqZWN0IHN0b3JlIGFuZCBQdWJTdWIg bW9kZWwNCg0KPiBTbyBmYXIsIEkgZG9uJ3QgYmVsaWV2ZSB3ZSd2ZSBkaXNjdXNzZWQgZGlzdHJp YnV0ZWQgc3RvcmFnZSBhcyBzdWNoLiBJdCB3b3VsZCBiZSBhIG5hdHVyYWwgcGFydCBvZiB0aGUg ZGlzY3Vzc2lvbiBvZiANCj4gaW50ZW50LiBXZSBoYXZlIHRlbmRlZCB0byBhc3N1bWUgdGhhdCBp bnRlbnQgb3JpZ2luYXRlcyBjZW50cmFsbHksIHNvIGl0IG5lZWRzIGEgcmVwbGljYXRpb24gbW9k ZWwgcmF0aGVyIHRoYW4gDQo+IGRpc3RyaWJ1dGVkIHN0b3JhZ2UgaW4gdGhlIGdlbmVyYWwgc2Vu c2UuIFRoZSBzaW1wbGVzdCByZXBsaWNhdGlvbiBtb2RlbCBpcyBvZiBjb3Vyc2UgZmxvb2Rpbmcs IHdoaWNoIHdlIA0KPiBhbHJlYWR5IGhhdmUgZm9yIHJlbGF0aXZlbHkgc21hbGwgZGF0YSBvYmpl Y3RzLiBGb3IgZXhhbXBsZSwgR1JBU1AgYXMgaXQgZXhpc3RzIHRvZGF5IGNvdWxkIGZsb29kIGFu IG9iamVjdGl2ZSB3aG9zZQ0KPiB2YWx1ZSBpcyB0aGUgVVJMIG9mIHRoZSBsYXRlc3QgaW50ZW50 IGZvciB0aGUgd2hvbGUgbmV0d29yay4NCg0KW1tBSF0gXSBPaywgdmVyeSBjbGVhciwgdGhhbmtz LiBXb3VsZCB5b3Ugd2VsY29tZSBzdWNoIGEgZGlzY3Vzc2lvbiBlLmcuIGZvciB0aGUgcmUtY2hh cnRlcmluZyBvZiBBTklNQT8NCg0KV2UgYmVsaWV2ZSB0aGF0IG5ldHdvcmstd2lkZSBzdG9yYWdl IGNvdWxkIGJlIG9mIGhpZ2ggdmFsdWUgZm9yIGF1dG9ub21vdXMgbmV0d29ya2luZywganVzdCBh cyByb3V0aW5nIGlzLiBUaGUgcmVhc29ucyBmb3IgdGhpcyBhcmUsIGFtb25nIG90aGVyczoNCg0K YykgZ2l2ZW4gdGhlIGV4aXN0aW5nIEFOSU1BIGRlc2NyaXB0aW9ucywgSSBiZWxpZXZlIHRoYXQg bGltaXRlZCBzdG9yYWdlIGlzIHByZXN1bWVkIGF2YWlsYWJsZSBvbiBhbGwgbm9kZXMgKGkuZS4g YXQgbGVhc3QgdG8gc3RvcmUgdGhhdCBVUkwgaW4geW91ciBleGFtcGxlKTsNCmIpIHRoZSBBUElz IGZvciBkYXRhIG9iamVjdCBzdG9yYWdlIGFyZSB3ZWxsLWVzdGFibGlzaGVkIGFuZCBjb21wYWN0 IChwdXQoKSwgZ2V0KCkpOw0KYSkgdGhlIGluZm9ybWF0aW9uIGEgbm9kZSBtaWdodCBuZWVkIHRv IHN0b3JlIGlzIG5vdCBuZWNlc3NhcmlseSBsaW1pdGVkIHRvIHRoZSBzY29wZSBvZiB0aGF0IHNp bmdsZSBub2RlLiBUaGVyZWZvcmUsIGFuIGVmZmljaWVudCBjYXBhYmlsaXR5IHRvIGFjY2VzcyBu ZXR3b3JrLXdpZGUgaW5mb3JtYXRpb24gKGUuZy4gY29uZmlndXJhdGlvbiBkYXRhLCBuZXR3b3Jr LXdpZGUgaW50ZW50cywgbmV0d29yay13aWRlIGF2ZXJhZ2VzIG9yIGFnZ3JlZ2F0ZXMgb2YgZGF0 YSkgd291bGQgcmVhbGx5IGJlIG9mIGEgdmFsdWUuIElmIGV2ZXJ5IGFwcGxpY2F0aW9uIGhhcyB0 byByZWRvIGl0LCB3ZSBydW4gdGhlIHJpc2sgb2YgcmVwZXRpdGl2ZSB3aGVlbCByZWludmVudGlv bnMgLSBvciBmbG9vZGluZy4gRXNzZW50aWFsbHksIGFzIHlvdSBqdXN0IGhpbnRlZCwgaWYgd2Ug ZG8gbm90IHByb3ZpZGUgdGhlc2UgbWVhbnMgKGVpdGhlciBieSBhIG1hbmRhdG9yeSBBU0Egb3Ig b3ZlciB0aGUgQU5JTUEgQVBJKSwgdGhlbiBldmVyeSBkZXZlbG9wZXIgd2lsbCBoYXZlIHRvIHJl dmVydCB0byBmbG9vZGluZyBhdCBsZWFzdCBmb3IgdGhlIGZpcnN0IG1lc3NhZ2UuIFdoaWxlIHRo aXMgbWlnaHQgYmUgYXNzdW1lZCByYXJlIGZvciBpbnRlbnRzLCBJIGFtIG5vdCBzdXJlIHdlIGNh biBjbGFpbSB0aGlzIGZvciBldmVyeSBpbmRpdmlkdWFsIGFwcGxpY2F0aW9uIHNjZW5hcmlvLg0K DQoNCj4gSSB3b3VsZCBub3QgYWR2b2NhdGUgZGV2ZWxvcGluZyBhIGRpc3RyaWJ1dGVkIHN0b3Jh Z2UgbW9kZWwgc3BlY2lmaWMgdG8gQW5pbWEuIFJhdGhlciwgaWYgd2UgZGVjaWRlZCBpdCB3YXMN CiA+IG5lY2Vzc2FyeSwgSU1ITyB3ZSBzaG91bGQgYWRvcHQgYW4gZXhpc3Rpbmcgc29sdXRpb24s IHNpbmNlIHRoaXMgaXMgbm90IGEgdHJpdmlhbCBwcm9ibGVtLg0KDQpbW0FIXSBdIEFncmVlZCwg YW5kIGl0IHdhcyBub3QgaW50ZW5kZWQuIElmIHRoZXJlIGlzIGEgcGVyY2VpdmVkIGNvbnNlbnN1 cyBvZiB0aGUgdmFsdWUgb2YgdGhpcywgd2Ugd291bGQgcmF0aGVyIHNlZSBob3cgdG8gaW50ZWdy YXRlL2Fkb3B0IGEgc3VpdGFibGUgc29sdXRpb24uDQoNCiANCj4+IDIuIEluIGEgc2ltaWxhciB2 ZWluLCBkb2VzIGEgcHVibGlzaC9zdWJzY3JpYmUgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uIG1v ZGVsLCBidWlsdCB1cG9uIGFuIHVuZGVybHlpbmcgc3RvcmFnZSwgDQo+PiBsb29rIHByb21pc2lu ZyBhbmQgcmVsZXZhbnQgdG8gdGhlIGdyb3VwPyBDYW4gR1JBU1Agc3VwcG9ydCB0aGF0IG9yIHdp bGwgaXQgcmVxdWlyZSBleHRlbnNpb25zPyBUaGUgcHViL3N1YiBpcywgDQo+PiBpbiBvdXIgb3Bp bmlvbiwgYSBtb3JlIGdlbmVyYWwgaW5mb3JtYXRpb24gZGlzdHJpYnV0aW9uIG1vZGVsIHRoYW4g d2hhdCB3ZSBzYXcgaW4gdGhlIGN1cnJlbnQgd29yayBzdHJlYW0uIFlldCwNCj4+IGJlZm9yZSBz dWJtaXR0aW5nIGEgZHJhZnQgdGhhdCBkZXRhaWxzIHN1Y2ggYSBtb2RlbCwgd2Ugd2FudGVkIHRv IGtpbmRseSBhc2sgZm9yIHlvdXIgb3BpbmlvbiBvbiB0aGF0Lg0KDQo+IEhhdmUgeW91IHN0dWRp ZWQgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbj8NCltbQUhdIF0gWWVzLCB0aGF0 IHdhcyB3aGVyZSBvdXIgbW90aXZhdGlvbiBjYW1lIGZyb20uIEl0IHNlZW1zIHRvIGJlIGJhc2Vk IG9uIHRoZSBmbG9vZGluZy9yZXBsaWNhdGlvbiBtb2RlbC4gV2hpY2ggaXMgZmluZSBmb3Igc29t ZSBzY2VuYXJpb3MsIGJ1dCB3aGljaCBhbHNvIGhhcyBrbm93biBsaW1pdGF0aW9ucy4gVGhlIGlk ZWEgd2FzIHRvIGFsbG93IGZvciBhIG1vcmUgZ2VuZXJhbCBtb2RlbCwgY29uc2lkZXJlZCB0byBi ZSBiZXR0ZXIgZm9yIHNjYWxhYmlsaXR5LCBldGMuDQoNCj4gQnV0IGZpcnN0LCB3aGF0IHNvcnQg b2YgYXV0b25vbWljIHVzZSBjYXNlcyB3b3VsZCByZXF1aXJlIGRpc3RyaWJ1dGVkIHN0b3JhZ2Ug b3IgYSBwdWIvc3ViIHNvbHV0aW9uPw0KDQpbW0FIXSBdIEFueSBleGFtcGxlIHVuZGVyIGEpIGFi b3ZlIG9yIG91ciBvcmlnaW5hbCBleGFtcGxlIG9mIEVDQSB0eXBlIG9mIGludGVudCwgd2hpY2gg d291bGQgcmVxdWlyZSB0byAicmlwZW4iIGJlZm9yZSBiZWluZyBleGVjdXRlZC4gVGhlIGV4YWN0 IGNvbmRpdGlvbiBjb3VsZCBiZSBzb21ldGhpbmcgdGhhdCBhbiBpbmRpdmlkdWFsIG5vZGUgbWln aHQgbm90IGtub3csIGUuZy4gImNsb3NlIHRoZSBibGluZHMgd2hlbiB0aGUgdGVtcGVyYXR1cmUg aW4gdGhlIGJ1aWxkaW5nIGV4Y2VlZHMgMjUgQyAoPTc3RikiLg0KDQoNCg0KUmVnYXJkcw0KYXJ0 dXINCg0K From nobody Thu Jun 29 19:45:13 2017 Return-Path: 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 4CFE5129B74; Thu, 29 Jun 2017 19:45:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jYtPcl8snSsX; Thu, 29 Jun 2017 19:45:04 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 892DB129B0A; Thu, 29 Jun 2017 19:45:04 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id u36so13801609pgn.3; Thu, 29 Jun 2017 19:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V0vxjpsXJUbhqdh4WchNvaZi8a/hOb6ngRLHNMfqlVU=; b=l2m8JvWwJeS6RcKYE4Z1zXAL+uCc9daoLIyEBvkQChMRW751sZI8Uleu2hv3qq/EHn 3CDFAwNnOepef0KQG8fBQECPmD9/jX94avY5+xWy8NXK/+0j37lcYepHR2/ziZKOn6oC TXBtA5U1qhRfKrYxLwzoCwFTbF0Iz+Veohfh+iP7vFGoYIIfivIbciK3oPvQX5+A43v6 yieM5ecoKpYomsBEUdb93wjbJfmDzbwex0r4tYD9TbB5RAq/7Xkvtesx8fXjQshJ7iBy tXF+Zoyu9VlSYcZMgz9iAMFKFzc43YC4pkQuaFmV0WIg56pFIR6S02U5V0pSdlXqCsAz Fu7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=V0vxjpsXJUbhqdh4WchNvaZi8a/hOb6ngRLHNMfqlVU=; b=Jt7VhEnzP9m0H2DfjTydE9z9IRKYlv/xyCnBBJst6igTvzw0LD7baJ7BEf/8eyuWGn cKUQv7QH2+WFiFFaBlcLy0z27UQOYtBUYXsQsth5dliLaF/GZod2V6TMNJTJDHd1+RQt 5YQAOvPiSRml4lHzrAH7ShieHW3R4YGQjgWZyp3i4M1Yna2YQhxW5+++MBoqRUy+RSNl B3yShBNF7NJmb45n1th9SFuIZv5WbrxhfAq+j3/VsGCw4bSGaA01qLHa5BQDH+ePEJNb ehuvirZGXCikz/OlGd+Xuy1f9bljRBxRy92opYT7MpfAIIdKdRfPlq989z2lyoo1wW8t ZT5A== X-Gm-Message-State: AKS2vOxuljU6/DPopjwFi1cnP7a9c/G5Ip1kxQRIXtMF6C0swiNceiEZ hjURLVrDLQ2afRUV X-Received: by 10.98.61.2 with SMTP id k2mr19869155pfa.90.1498790703722; Thu, 29 Jun 2017 19:45:03 -0700 (PDT) Received: from [192.168.178.21] ([118.149.105.228]) by smtp.gmail.com with ESMTPSA id y8sm9636389pge.0.2017.06.29.19.45.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 19:45:03 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: Terry Manderson , "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com> <20170627042123.GA18207@faui40p.informatik.uni-erlangen.de> <80c297de-c104-879b-0afc-1d6c3bbab8da@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B927CDF240C@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 30 Jun 2017 14:45:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDF240C@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 02:45:11 -0000 OK. It may not be final but I will submit that shortly. Regards Brian Carpenter On 29/06/2017 18:17, Sheng Jiang wrote: > Hi, Brian, > > With my WG chair hat on, the situation regarding to these ANI objectives is strange indeed. Could you please resubmit your anima-ani-objectives before the deadline next Monday? Then, the chairs could discuss the situation with our responsible AD. It looks that the easiest way is to adopt this draft and quickly send it to IESG along with ACP and BRSKI. > > Cheers, > > Sheng > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Thursday, June 29, 2017 10:44 AM >> To: anima@ietf.org >> Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 >> >> I had a look at both sets of changes and they seem good to me. >> >> I find myself wondering, after seeing the slightly confused text about GRASP >> objectives in the latest BRSKI, and noting the absence of such objectives in the >> ACP and stable-connectivity drafts, whether we should accept that we need a >> specialised draft for all the GRASP objectives needed by the ANI. >> >> Strangely enough, we have such a draft already: >> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01 >> My idea was for this to be a temporary draft, with its contents being moved >> into BSRKI, ACP and stable-connectivity. But would it be more practical to keep >> it as a separate draft? It makes the other three drafts a bit more self-contained, >> and allows for a consistent definition of the infrastructure objectives. >> >> What to do people think? >> >> (Disregard the current details in draft-carpenter-anima-ani-objectives, >> which has not been updated recently.) >> >> Regards >> Brian >> >> On 27/06/2017 16:21, Toerless Eckert wrote: >>> Thanks a lot, Sheng! >>> >>> Integrated fixes for all comments (see inline discuss below). Pushed >>> stable connectivity draft into >>> www.github.com/anima-wg/autonomic-control-plane together with ACP >> draft because i ended up having to do a fix for the ACP draft as a result of your >> comments. >>> >>> Diff between -02 and fixed up stable connectivity draft here: >>> >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.gith >>> ubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-a >>> nima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&u >>> rl2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane >>> /master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-c >>> onnectivity.txt >>> >>> If you are fine with the fixes let me know, and i'll push it to datatracker as -03. >>> >>> If not ok. feel free to use email or now also add issue to the git. >>> >>> Raw txt/git files of fixed stable connectivity text: >>> >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/mas >>> ter/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-conne >>> ctivity.txt >>> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/mas >>> ter/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-conne >>> ctivity.xml >>> >>> Diff for change done in ACP (explaining ACP connect better): >>> >>> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.gith >>> ubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-a >>> nima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane- >>> 06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-contr >>> ol-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-an >>> ima-autonomic-control-plane.txt >>> >>> Cheers >>> Toerless >>> >>> On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: >>>> Hi, authors of draft-ietf-anima-stable-connectivity, >>>> >>>> I am doing a thorough review as the document shepherd with my ANIMA >> chair hat on. Please address the below comments so that we could process this >> document further. >>>> >>>> First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It >> would be an unlike scenario to manage an IPv6 network (all managed devices >> are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the >> NAT64 setup in this scenario is complex, and connectivity between IPv4 only >> NOC application devices and NAT is unsecure. I would suggest to reduce the >> whole section or add a clear statement that it is a not-recommended scenario >> at the end of this section. >>> >>> Yes, it is a mess. But it is documenting an actual deployment >>> experience with an enterprise customer. TAnd my understanding is tht >>> it would be a quite common scenario for enterprises. There was just >>> recently a very nice RTG area WG chair tutorial that to me reconfirmed the >> ongoing challenges with IPv6 only management planes. >>> >>> I have added paragraphs to justify the need for this section and that >>> its all undesirable workarounds Please check. To me, this messy >>> section is the price we have to pay so that the ACP can simply be IPv6 only. Its >> a price i am happy to pay. >>> >>>> Secondly, the description and category in section 2.1.2, "Limitations and >> enhancement overview". For me, only the point 1 & 3 are really limitation of >> ACP itself. >>> >>> I have improved the text and categorization in this chapter to make it >> hopefully clearer to read and to be more precise in terminology. >>> >>>> Point 2 is a precondition (it is actually conflicted with section >>>> 2.1.4.) >>> >>> Yes, IPv6 is a precondition. If a deployment can not meet this precondition, >> that is a challenge for which there is a workaround. Those workarounds are >> described in section 2.1.4. I've tried to improve all that text. I do not >> understand why point 2 would be a conflict with section 2.1.4 instead of rather >> pointing to 2.1.4. >>> >>>> I don't understand point 4. What does "exposing the ACP natively" mean? >>> >>> That is the term that was defined in ACP CP draft, section 6.1. Reading >> through that section, i improved it in the ACP section, and i updated the text >> about it in stable connectivity. >>> >>> Oh, and this change had me change the term "NOC application device" to >> "NMS host" throughout the document because that is the term used in the ACP >> draft. >>> >>>> Thirdly, I have issues to use names to distinguish the path selection policies. >>>> This is a chicken&egg issue in the autonomic scenario. >>>> Who and how the DNS names are setup, by human administrator? >>> >>> IMHO, considerations for names are one of the most crucial part of >>> operationalizing the ACP. The little text we have about the ACP is >>> IMHO a good compromise between overlooking the problem and writing a >>> lot more text. >>> >>> The concept of using different addresses for a device for different >>> actions is not novel to ACP. Think of using a loopback to "reliably" >>> talk to a router vs. ping'ing specific interface addresses of a router >>> to discover whether an peer (reachable via that interface) is up/down. >>> If you look at service providers name setups (often in DNS), then they >>> will have different names for those different addresses and use those >>> different names in the different tools. The text in this draft simply >>> explains the same concept for ACP vs. other addresses. >>> >>> DNS names can be setup by various locally built automation scripting or >> templates. >>> Same think for DNS names for ACP. Operators will likely point out that >>> automating the DNS name creation is more difficult because we do not >>> use topology/semantic ACP addresses, but in principle it's the same >> automation task. >>> >>>> If there is a mechanism to distinguish the IP addresses of ACP and >> data-plane without human intelligence, why does it bore to use DNS? >>> >>> ALl the existing "actions" that you want to do for a device are just too stupid: >>> They do not include the logic of knowing which address is best for >>> them to use. That's why you use names for subsets of the possible >>> addresses to allow you to specify exatly those address(es) that will >>> reach the device via the network connection matching the intent of the action >> you're taking. >>> >>>> DNS registration & lookup by itself is a very complex and time-consumption >> procedure. >>> >>> Depends on your automation. Its certainly an interesting aspect >>> especially moving from IPv4 to IPv6 where embedding logic into >>> adresses becomes a whole different ballgame. >>> >>>> If we don't want to show the semantic of these addresses to any human, >> names are meaningless. >>> >>> But you need new NOC tools where each action would need to know what >>> type of connection is best for it. >>> >>> I have added one paragraph to 2.1.5 to outline this logic and >>> justification for why to describe DNS. Look for "Ideally, a NOC system would >> learn and keep track of all addresses of a device" >>> >>> >>>> In section 2.2, "The ACP can provide common direct-neighbor discovery and >> capability negotiation". This is a wrong statement. ANI does provide this, but it >> is done by GRASP, not ACP. >>> >>> Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the >>> GRASP protocol common direct-neighbor discovery and capability >>> negotiation (GRASP via ACP and/or data-plane) and stable and secure >> connectivity for functions running distributed in network devices (GRASP via >> ACP). >>> >>>> At the end of section 2.1.3, "A simple short-term workaround could be a >> physical external loopback cable into two ports of ANrtr1 to connect the >> data-plane and ACP VRF as shown in the picture." Does this has to be "a >> PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. >> Personally, I believe this could be done by a virtual loopback interface. >>> >>> Ack. Changed text to: A workaround without additional software >>> functionality could be a physical external loopback cable into two >>> ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the >> picture. A (virtual) software loopback between the ACP and data plane VRF >> would of course be the better solution. >>> >>> The key notion why the "gross" physcial loopback may be appreciated is >> because it doesn't require software work. Or specification of the behavior of >> such a software loopback in the roting behavior in the ACP draft. I would love to >> have that software loopback, but i think we (ACP doc authors) felt that we >> wanted to keep the ACP spec lightweight enough to be implementable without >> all possible enhancements. But i hope its fine to mention the option here in this >> document as you suggested. >>> >>>> Section 3, "Security considerations" is more like a deployment >>>> considerations. Both ULA-C and reverse DNS are additional deployment >>> >>> Yes, but i think if you look through various IETF documents you will see that it >> is quite common for security consideration sections to outline additional steps >> to secure the documents work goal especially when those steps are otherwise >> orthogonal to the documents spec (eg: leverage existing components). >>> >>> Whats the process for informational documents. It will get SEC AD review, >> right ? Maybe hold that thought for that review ? Or else i can proactively ask, >> because right now i am a bit at a loss whats the right limit of what to put into >> sec considerations vs. what to extract into a separate chapter. >>> >>>> Minor comments, >>>> >>>> Section 2.1.6, "Autonomic NOC device/applications" should be moved to >> early part of this document. For me, it is the default scenario/requirement. It >> should be section 2.1.1, I guess. >>> >>> The text unfortunately builds up in the order it is written, so it would be a lot >> of rewrite to make sure it would still read after such a reordering. Instead i >> have added the following as the first paragraph: >>> >>> This section describes stable connectibity for centralized OAM >>> operations via ACP/ANI starting by what we expect to be the most >>> likely easiest short-term deployment option. It then describes >>> limitation/challenges of that approach and their solutions/workarounds >>> to finish with the preferred target option of autonomic NOC devices in >>> . >>> >>> This order was choosen because it helps to explain how simple one >>> can start using the ACP, how difficult workarounds can become (and >>> therefore what to avoid), and finally because one very promising >>> long-term solution alternative is exactly like the most easy >>> short-term solution only virtualized and automated. >>> >>> The last sentence is that punchline: The likely easiest/best atonomic NOC >> device solution is one where you do everything you do in the short-term >> approach, just virtualized and integrated into the NOC device. WHich means >> you'd need to explain all that stuff anyhow... >>> >>>> It is worth of mentioning even the ACP provides only IPv6 connectivity, >> through it, IPv4 configuration or even non-IP configuration could be managed. >>> >>> Good point. Added the following sentence: >>> >>> Note that even though the ACP only uses IPv6, it can and should be >>> used to providestable connectivity for management of any network: IPv4 >>> only, dual-stack or IPv6 only. >>> >>>> The document does not properly quota references in the text. The >> references defined are mostly not used. >>> >>> Ack. Removed unnecessary references, introduced terms/references in >>> the beginning of the document. All references now used at least once >>> ;-) >>> >>>> The document separate sections for Informative/Normative References >>> >>> Hmm. It DOES NOT distinguish between normative and informational >> documents because i thought that an informational document like this could >> not have normative references. If it can and should have them let me know, >> then i'll make Bootstrap/Grasp/ACP normative and reference/definitions >> informational. >>> >>>> The empty section 5 "Further considerations", should be removed. >>> >>> Done. >>> >>>> Most of references are out of date. behringer-anima-reference-model > >> ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, >> irtf-nmrg-autonomic-network-definitions > RFC 7575. >>> >>> Fixed. >>> >>>> In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the >> infrastructure design." What is the mean for "other mayor"? >>> >>> added: Examples include change of IGP protocols or areas, PD (Provider >>> Dependent) to PI (Provider Independent) addressing, systematic topology >> changes. >>> >>>> In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" >> may be better to presented as "the Autonomic Control plane (ACP) in >> Autonomic Networks" >>> >>> Done >>> >>>> There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in >> section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section >> 2.1.5, "KARP" in section 2.2, even the first appearances. >>> >>> Done, added RFC references for those TLAs that have them as well. >>> >>>> Last sentence of section 2.2 should be removed. >>> >>> Done. >>> >>>> In section 3, first sentence, add "In this section," >>> >>> Done. >>> >>>> There are typos, needed to be fixed too: >>>> >>>> Two "the the" in the end of section 2.1.2 and end of section 4; >>> >>> Done >>>> >>>> A couple of "randomn" -> "random"; >>> >>> Done >>>> >>>> "networ" in section 2.1.5; >>> >>> Done >>>> >>>> "jut" -> "just" at the end of section 2.1.6, I guess. >>>> >>>> "The most simple" -> "the simplest" in section 2.17. >>> >>> Done. >>> >>> >>> _______________________________________________ >>> 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 > . > From nobody Thu Jun 29 19:52:44 2017 Return-Path: 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 D650C12EB01 for ; Thu, 29 Jun 2017 19:52:42 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZLiYiZwlknqH for ; Thu, 29 Jun 2017 19:52:41 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 E3C43129B45 for ; Thu, 29 Jun 2017 19:52:40 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e7so59735229pfk.0 for ; Thu, 29 Jun 2017 19:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6UI7ES3XwerQNvHlSOjoyZm4zU6Po6lwsICZWRpiNzk=; b=T4svlZ/EjgTKF2kzZD7to8Akg3UK276t8HocvCF5qUrlAcaPb19w/dUA2jaAM8a3Xa dZyP9b6YJy6yg7dtWjyWFWUOcQJncH/ZGFPDP7awZJ0hOeVtWaK62yhAFqyygY6touaL //ouSDB/oYqIEs4A2WzuuONWbw1aub2R4AMqxG3t7CkXAlrAw6yOgthzjQcshKTOeu6M sfrnK/4vIiAHZqwxsHuN+hSrVqjclvRocyr5MXeOaF6cyO8T9iL3ZQPtX3ufXFQlZR+0 JBQw7ZTfgT/ksNWZ2Z8+2yQBECRzBgnf7uiddyooPyNPoswrjx1jOSI0J0Wgb16Qa1px QnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6UI7ES3XwerQNvHlSOjoyZm4zU6Po6lwsICZWRpiNzk=; b=PT5mhdWCsCPYooEaQrK2HA1WFZBu8zSMwh3EsFp1KyWkraybDwjKPlDp8zKwRVGyy9 7hVtt9SAnu+1jKrM61qy3OTkRK53npl6+BB5am2nfi+aqii1bubMRDbawXV9hP+7nePM IWDAmRT2I7xwOOqdmcdeErmqXYFxyUcuWaKPe1HDoRhdVMXhDezaU6LJ4uNWkjmcVnaH vzBvcG+LN1o8ebpmFXJ2BkzTyh2nC65TLhBzYziSsF0KcsDqbfSFDsfSwmkg9LpfpFG7 r5wE9rXr65xz+DIMMjJqmwBWE7V6j5Z80yEbUxxC7QrBSy02w8/C5ilkJnsdjA6y9BWU dXSg== X-Gm-Message-State: AKS2vOxHQFA1p9IgfuzpXVDWO2JErPFqJyTUEBaJe3ISGjwAnAz50MrG 3eaTtdxflMrsm+nw X-Received: by 10.99.151.1 with SMTP id n1mr19047456pge.166.1498791160363; Thu, 29 Jun 2017 19:52:40 -0700 (PDT) Received: from [192.168.178.21] ([118.149.105.228]) by smtp.gmail.com with ESMTPSA id z82sm16209334pfk.1.2017.06.29.19.52.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 19:52:39 -0700 (PDT) To: Anima WG References: <149879100836.4606.421294549631497053@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 30 Jun 2017 14:52:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149879100836.4606.421294549631497053@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-api-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 02:52:43 -0000 Hi, This is a minor update to the GRASP API. As always, the authors invite comments. Brian + co-authors On 30/06/2017 14:50, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) > Authors : Brian Carpenter > Bing Liu > Wendong Wang > Xiangyang Gong > Filename : draft-liu-anima-grasp-api-04.txt > Pages : 23 > Date : 2017-06-29 > > Abstract: > This document specifies the application programming interface (API) > of the Generic Autonomic Signaling Protocol (GRASP). The API is used > for Autonomic Service Agents (ASA) calling the GRASP protocol module > to exchange autonomic network messages with other ASAs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-liu-anima-grasp-api/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-liu-anima-grasp-api-04 > https://datatracker.ietf.org/doc/html/draft-liu-anima-grasp-api-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-liu-anima-grasp-api-04 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu Jun 29 20:01:08 2017 Return-Path: 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 9008E12EB2B for ; Thu, 29 Jun 2017 20:01:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2Jlxl2X0Wkr5 for ; Thu, 29 Jun 2017 20:01:04 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 8D54212EB24 for ; Thu, 29 Jun 2017 20:01:04 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id e7so59820652pfk.0 for ; Thu, 29 Jun 2017 20:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FUgWLZkXSc1Kc1aYFCXrFhD9Cnil7GsF+6o47zAxya0=; b=exakph+2L+thMFXByvjXRocmedGHdnYNaOInWTrK6bIklD8efKCySYGsWbjOW/srS2 eKGRnwF9xv1NCK1nx5rs0/11AZcsIqUPXGBxfhgMJXhTz6QM0uMUOghIYx095+a+GBaI nnqHqePI4ShFT7vD85/2YoNpGrXlv5SDnsVHG6CdTEohCnxjs5V/FaCtCglUGDo8ILsa RtBxpaI//Fk/yCLsgw+nkl4o4smp3KP2MEXL1etZPZZDhTqJcuudPlS2bFAin3D+ndM8 4O0PAVTpOcoLju208enH5SZjXCwJqy6D0YD6vADqip53WUNd4z+rBQ4o0Ivos722N7b8 g2jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FUgWLZkXSc1Kc1aYFCXrFhD9Cnil7GsF+6o47zAxya0=; b=H0FcH3ViXYWZTgyzA7zYhSYRdFjMIaTehvIrSVqdAeBgviga8r39XLNGeeRVtyGg0E kilCx+O009alz5OsJMIOjpdGrBf6mfy6RCUYdWhqJRskjlDkkhCA+9ozYXgN2xDMeh6J UtqmVMzcjhSMTOMS9PVXOOFIfU4FzfHNyK3WIIUQNkuOxfhA4/0/uH/WTVBWYhQiJgbY XXrx9ATZra01QLLW79EM1854xUU5Obc+dnfHQGkhyhxWG/Mfnx3YTswssWj3BZUWYoJV sBSexbawtcFacqMLaMOwivC63hICJFGjzN0pIbIzjeLjNkyWavZ38PYiBrOI8cTuEtYb /JCA== X-Gm-Message-State: AKS2vOz2Z0dGCtYDz6hHS+0lmeafQVeum/6B73gtxBI47gBPBAcBs33f 2kyJUisMxZB7+rKn X-Received: by 10.99.184.25 with SMTP id p25mr18834821pge.22.1498791663723; Thu, 29 Jun 2017 20:01:03 -0700 (PDT) Received: from [192.168.178.21] ([118.149.105.228]) by smtp.gmail.com with ESMTPSA id 5sm12308319pfe.60.2017.06.29.20.01.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 20:01:03 -0700 (PDT) To: Anima WG References: <149879102820.4634.18247017002883901441@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 30 Jun 2017 15:01:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149879102820.4634.18247017002883901441@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-carpenter-anima-ani-objectives-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 03:01:06 -0000 Hi, As Sheng suggested, this is a complete update of the GRASP objectives for BRSKI, the ACP and the stable-connectivity draft. I apologise to Bing, my co-author, for not checking with him, but time was rather short. As far as BRSKI goes, this is intended to simply replace all the GRASP-related details in sections 3.1.1 and 3.1.2 of draft-ietf-anima-bootstrapping-keyinfra-06. Please don't waste time on the diffs from the -01 version, there are too many changes and deletions. I haven't had time to update my demo code for this new version; if I manage to do that before the IETF I will let you know. Regards Brian On 30/06/2017 14:50, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Technical Objective Formats for the Autonomic Network Infrastructure > Authors : Brian Carpenter > Bing Liu > Filename : draft-carpenter-anima-ani-objectives-02.txt > Pages : 9 > Date : 2017-06-29 > > Abstract: > This document defines the formats of several technical objectives for > the Generic Autonomic Signaling Protocol (GRASP) used by components > of the Autonomic Networking Infrastructure outlined in the ANIMA > reference model. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-ani-objectives/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02 > https://datatracker.ietf.org/doc/html/draft-carpenter-anima-ani-objectives-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-ani-objectives-02 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Jun 30 17:53:29 2017 Return-Path: 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 2EA6112EB21; Fri, 30 Jun 2017 17:53:27 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 A4jFZxpWkMla; Fri, 30 Jun 2017 17:53:24 -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 293F4120726; Fri, 30 Jun 2017 17:53:24 -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 A21F558C4B0; Sat, 1 Jul 2017 02:53:19 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8009CB0C44D; Sat, 1 Jul 2017 02:53:19 +0200 (CEST) Date: Sat, 1 Jul 2017 02:53:19 +0200 From: Toerless Eckert To: "Max Pritikin (pritikin)" Cc: Sheng Jiang , Anima WG , "anima-chairs@ietf.org" Message-ID: <20170701005319.GA28405@faui40p.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B927CDF0D16@NKGEML515-MBX.china.huawei.com> <818D85B2-F5DB-4253-A4D1-2B344CD273CA@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <818D85B2-F5DB-4253-A4D1-2B344CD273CA@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Anima] Result of WGLC on draft-ietf-anima-voucher-03 - Respond by June 23, 2017 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 00:53:27 -0000 Which WG chair ? i am purely a co-author here on this thread ;-) Hope i just resolved to the approval of my co-authors two more, leaving just one open item which is how we best compromise between some fairly recent improvements to bootstrap (using voucher format also to request vouchers) and expediency in finishing last call for voucher. Issues resolved: https://github.com/anima-wg/voucher/issues/8 - how to use grouping in yang for extensibility via followup documents. Hope i didn't make mistakes in what i wrote, but the issue tracker URL now has a longer explanation from me how such extensibility can be done in the future and the necessary stub was added into the voucher draft (Kent had proposed this in the past already, i also verified this with some Yang knowledgable colleagues, so i hope we're good here). https://github.com/anima-wg/voucher/issues/6 - describing how vouchers could be used with eg: JWS instead of PKCS#7 (via appropriate specs in other docs). Cheers Toerless On Tue, Jun 27, 2017 at 09:03:17PM +0000, Max Pritikin (pritikin) wrote: > Toerless (the other working group chair) has been involved in conversations concerning the open issues listed on the github repository for the voucher document. > The issues should be resolved now as per the current status in github. See here for details of three open issues remaining: > https://github.com/anima-wg/voucher/issues > The other issues have been resolved and the ???top of the tree??? is here: > https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher.txt > > If you are curious about what this resolves so far please look at these diffs (here summarized via the commit comments): > > [some minor editorial work] > typo in "hangTex" instead of "hangText" 2f0d64c > updated hangtext for artifact definition 4f6c710 > Updated the proximity description with minor editorial edits. ??? b742c5a > Merge branch 'master' into voucher_sync_061417 6cc9d72 > manual merge of a generated txt file sucks. committing built version ??? ??? > [substantive issues] > additional enum for ???proximity??? assertions: > https://github.com/anima-wg/voucher/commit/b8ec4919242bc26c9082f633099656e4851097ea > > addition of prior-signed-voucher to provide history in northbound BRSKI exchanges: > https://github.com/anima-wg/voucher/commit/b742c5a63e05f1341b37f96009d6bfcd5f5be0e1 > > We believe this provides enough to proceed with LC and to allow BRSKI to be finalized toward LC as well asap. > > - max > > On Jun 26, 2017, at 8:33 PM, Sheng Jiang > wrote: > > Hi, all > > Given there is no negative response to the WGLC on draft-ietf-anima-voucher-03 and we did receive good reviews through the WG document stage and considering the past history of this work, the ANIMA chairs feel it is has passed the WGLC and should advance. This conclusion is made with the condition that the authors would solve the comments received during the WGLC and these modifications were not substantial changes from 03 version. If there are big changes, a shorter second WGLC may be needed. > > Once the update is published and it meets the above condition, for which the second WGLC is not needed, as shepherd, Sheng Jiang will finalize the shepherd document and send the document on. > > Best regards, > > Toerless & Sheng > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- --- tte@cs.fau.de