[Anima] some comments about ACP connect

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 15 November 2019 14:20 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 287F812086B for <anima@ietfa.amsl.com>; Fri, 15 Nov 2019 06:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 f6fYIMCsvrlD for <anima@ietfa.amsl.com>; Fri, 15 Nov 2019 06:20:34 -0800 (PST)
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 10CD2120013 for <anima@ietf.org>; Fri, 15 Nov 2019 06:20:33 -0800 (PST)
Received: from [192.168.42.31] (unknown [209.171.88.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id DC87C3897C for <anima@ietf.org>; Fri, 15 Nov 2019 09:17:22 -0500 (EST)
To: anima@ietf.org
From: Michael Richardson <mcr+ietf@sandelman.ca>
Openpgp: preference=signencrypt
Autocrypt: addr=mcr@sandelman.ca; keydata= mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QSdv84oNe1 h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2IoHCU6ezhQz2TwJO7 l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF8lIIAYEbQ4YyYyjk5DS30x59 kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDDsMmTJWPkszvQoCjCbrvgDAuoRtL5su2V IQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVlL71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj 1N/2x7mGk35Zrvz0WHjZLcFJYJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQ gRI4pNs24NoxLXl5v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh0 5I5okPcENk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvUmQjFqXgsg4KhIWQb QBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSGTEH03oJIeYbdwlOCe5blA6h4 FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQMxgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU 8VTgenm4JpBdJQx7/7syvIaQilhN2fF25CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnp mspJTGptxFxH/GM/kW40iB4tUjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullzt u37BDVj/SmgbGhvTUXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollE Zcw9VIojPKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kBjQRdxGjv AQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5KhdcxjTlo6htNjRUuUy1Ld 0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOplKgMSoGpGamLSDzRs3SAJu4GF iHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zXfSmZqZwNp/6xosLCl3TKvFWX6421Vb/L WAOOAz/xSyS0GCUs/grBUfzu95+TTskRk7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOq e7/5y4bQkILGGMIux878DhAED865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD 7r5QL6iU57zI/B5U03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhD VmrDKLWXRm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUCXcRo7wIb DAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyytePFmS9NAwdT8A6mA4s +WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8WJVn0zH7LVCKMWo/tHE2rWyi Q1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJprKZAtiDJ897vv1jP09fWLEBhaDsHqLhg ckQpIoee0Id4FXGt7wxDsPwa64SUUCTYdt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7 UXVMQlEKG7E31G1XQMk6sFATF1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8 SFA6Uc+Bjr0i1jdnxS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot 8lIsHGAJQHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw=
Message-ID: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca>
Date: Fri, 15 Nov 2019 22:20:25 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/MCJqXQYOPJAOFuaIj6xGwAMqsBE>
Subject: [Anima] some comments about ACP connect
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2019 14:20:36 -0000

Toerless, I am preparing a document on Operational Considerations for
Registrars: "Operational Considerations for BRSKI Registrar"

I was reviewing section 8.1, on ACP connect.

   To allow for auto-configuration of NMS hosts, the ACP edge device and
   NMS hosts using ACP connect SHOULD support [RFC4191].  The ACP edge
   device should announce the whole ACP ULA prefix via that standards
   Router Advertisement signaling option.  It should also announce the
   default route (::/) with a lifetime of 0.  In result, NMS hosts
   supporting RFC4191 will route the ACP prefix via the ACP edge device,
   but will not route the default route via it.

I don't disagree with anything you say, btw.
I think that maybe some explanation is in order here though.
I recognize the document is in it's final stage, but maybe a word or two
could be added here.
First, what is the "whole ACP ULA prefix"?  Is it the /48?  I think we
could say so.
I will send a pull request once I finish writing.

Second, if 6.10.2 defines the base scheme, and it's 8+40+2=50, why in
6.10.3 does it
say "51*" above the "(base scheme)"?  Is that a typo?

It seems that we could advertise a 6.10.3 non-zero "Zone" on the NOC ACP
Connect "LAN"?

It seems that we ought to sending a Routing Information Option for the
/48, and a PIO for the specific /64 above.
We might want to set L=0 here. 
I understand that we advertise ::/0 with lifetime=0 because of RFC4191
section 3 analysis.
I don't know if type A,B,or C hosts are common out there, I think that
rfc4191 is widely implemented at this point, so I suspect most hosts are
type C at this point.

Generally, I think that NOC hosts should not autoconfigure (SLAAC or
stable private address) addresses, as they ought to be manually
configured.  I am open to discussion here.  I do think that they should
listen to RAs for the ACP route so that we can have multiple routers, etc.
*
I will be making a few more specific recommendations in my document in
line with the view above.