Re: [Casm] prefix assignment

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 29 March 2017 15:04 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: casm@ietfa.amsl.com
Delivered-To: casm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDF5126DD9; Wed, 29 Mar 2017 08:04:12 -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 tQYj2VUu4ADE; Wed, 29 Mar 2017 08:04:10 -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 E3634127599; Wed, 29 Mar 2017 08:04:09 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 938BB200A3; Wed, 29 Mar 2017 11:28:03 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BBB12636E0; Wed, 29 Mar 2017 11:04:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: casm@ietf.org, anima@ietf.org
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Mark Townsley <townsley@cisco.com>, homenet@ietf.org
In-Reply-To: <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com>
References: <21984.1490644275@obiwan.sandelman.ca> <CANMVOuzYpcBdG2ZOhEXRnQU0Q=_i0i-09SPKzruJnznVoWW=OA@mail.gmail.com> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 29 Mar 2017 11:04:08 -0400
Message-ID: <28218.1490799848@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/wt-FTfFdqUsn0w1xZjLEUwr6nxw>
Subject: Re: [Casm] prefix assignment
X-BeenThere: casm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Coordinated Address Space Management <casm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/casm>, <mailto:casm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/casm/>
List-Post: <mailto:casm@ietf.org>
List-Help: <mailto:casm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/casm>, <mailto:casm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 15:04:12 -0000

This discussion started in a private thread, so I'll try to bring people
up-to-date by repeating and moving around text.

The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
to do distributed prefix allocation.  This is very much in the space of
*coordinated* address management.

(My take, BTW, is that CASM should be considered the first spin-off WG
From ANIMA...)

Mark and Brian discussed how HNCP does prefix distribution within Homenet.

Brian then suggests:

  brian> But if the CE includes a little autonomic service agent (ASA) which
  brian> is in the ISP's security domain (not the SOHO domain), it can act for
  brian> HNCP to solicit address space from the ISP. That's the southern side
  brian> of the CASM model and the northern side of HNCP.

I asked a simple question: don't we have DHCPv6 for this?

I also then asked:

    > a) the CPE device is now part of the ISP's ACP.
    > That's okay if the CPE device is owned by the ISP and/or the CPE device
    > includes some kind of trusted computation environment.
    > {But a CPE owned by the ISP, might not be trusted by the home owner,
    > so another router in between would be needed,

Brian answered:
    > Really? Why not?

I don't think that the ISP can trust to have code controlled by end users
running in their ACP domain.

I also think that many end-users will be quite reasonably upset that their
ISPs can snoop on their internal traffic.  This may in fact violate many
work-at-home agreements; which is often the case of why you see multiple
routers/firewalls in documents like
         https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.

(Fred had more interesting diagrams in presentations, which I could dig up)

    >> b) DHCPv6 PD is already the protocol that solves prefix allocation across
    >> trust boundaries.

    > Indeed. That's why we have "PD supported"  as a Boolean property of the
    > PrefixManager objective. There's no intention to undermine PD.

Why do I need to run a protocol in order to find if I can run a protocol,
when DHCP has the same mechanism already.  And use of DHCPv6 itself is well
defined in cable and DSL connections already.

    >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals with
    >> prefixes.  It would speak DHCPv6-PD to the south, and GRASP/ASA to the north.

    > Yes, the DSLAM is definitely a good place to put one.


    >> North of the ISP's device would be the ISP's (distributed) IPAM.
    >> GRASP/ASA-Prefix would be the protocol between.

    > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
    > complementary not competitors.

I don't see you saying that.

I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
in the home) such that they interact directly, rather than using PD.  You
say this right here:

  brian> But if the CE includes a little autonomic service agent (ASA) which


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-