Re: [Casm] I-D Action: draft-li-casm-address-pool-management-arch-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 March 2017 22:05 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 E91CB129C08 for <casm@ietfa.amsl.com>; Tue, 21 Mar 2017 15:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] 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 Z91n3PwMyaO8 for <casm@ietfa.amsl.com>; Tue, 21 Mar 2017 15:05:40 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 2984012F27C for <CASM@ietf.org>; Tue, 21 Mar 2017 15:05:40 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id f84so56699487ioj.0 for <CASM@ietf.org>; Tue, 21 Mar 2017 15:05: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-transfer-encoding; bh=nUFxIORZEtsfVS/2KOOzL/dVzQPGPRdY7YMh1UtbThY=; b=JAyPHIUtCTMlS4T7COXDGDAB1UvLomskYQXa07WuOM5pPBXh4RdkNTrADHdZF1q8MV s75xnaU1wcnNx03ECpeUFEckgqfv1HmMJLbyGhSZRo58MV9N1Dg3UgCT9TF3NmZo6Fio xb2Up/o1vmEWYSZ/AoeYKwnlEVJHVSR8bgRByxEStDCj9tJCxM06G5arI51VU1eECw1Q vXPjT7qz/VGwld7ouExazd3gZJwv6T3dmTNEEqXMd1ntXptAjcGkqDFqxuMKdBkDbJmA UTX0Ns+X9lj3iUzD4yc2Cg4ow7VvPzIZNbHNid6HV/fSQyHY6Qf8Y8+0CafVjb/XbOo2 bLpg==
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-transfer-encoding; bh=nUFxIORZEtsfVS/2KOOzL/dVzQPGPRdY7YMh1UtbThY=; b=JohF1dAI2mouHY+sfBqjvyAwkiZgfK75ypyUTixXOzocAHjzu86qtvQPik591O3Trh yaaNjEFe4984z6s3yVJH42UBXKajs6XGrmNoXtYTZZIDRdp/JWp+2XD6OvfxREdwNwVq ta8Na0CnadF8nA/1eoyKzOsF2Pxt60rBLdl2R6BQVIqxhgOmV8J5E7UhBXDhxIq9HGqn +8rgiwhEux96aTr/gA8MFPJhxDdJDzE/iv2bEbmZ+/nxeOX1bhYRYl6sMCJY7qqpbKju rgxI/DABzd18RNjpMIhGqPay4C88Lv1xElTf/tKcI1R4vIkVjGMpjjGx3wPmYGZjWlrE /HBg==
X-Gm-Message-State: AFeK/H1JVO/KnxwDv6WIm6NSe1+BKjJnzWmipGh5rJhKRHHuZecbRX0i9QKf+z28ixWmEA==
X-Received: by 10.107.137.103 with SMTP id l100mr31751458iod.215.1490133939167; Tue, 21 Mar 2017 15:05:39 -0700 (PDT)
Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id x26sm6897486ioi.5.2017.03.21.15.05.38 for <CASM@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 15:05:38 -0700 (PDT)
To: CASM@ietf.org
References: <148912379958.5722.2883329103732032085@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <29263994-2dfe-ad98-750a-ff0f7024cb2d@gmail.com>
Date: Wed, 22 Mar 2017 11:05:42 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <148912379958.5722.2883329103732032085@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/5emZPZArSIDj0Frh6zPA56qFErw>
Subject: Re: [Casm] I-D Action: draft-li-casm-address-pool-management-arch-00.txt
X-BeenThere: casm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Centralized 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: Tue, 21 Mar 2017 22:05:42 -0000

Hi,

Thank you for this draft. I have a few general comments, let me start with the Abstract:

>    it is complicated to
>    manually configure the address pools on lots of Broadband Network
>    Gateways(BNGs) for operators.

Not only for BNGs. I believe the same problem arises in any kind of large
network. Also, although the IPv4 exhaustion is a problem, so is the enormous
size of the IPv6 space - it also needs coordinated management.

> By introducing SDN/NFV in BNG, the

The problem exists without SDN and NFV. I agree that virtualization of
any kind makes the problem bigger, but it doesn't *create* the problem.

>    address pools can be allocated in a centralized way.

As we have already discussed, the *requirement* is coordination, not
centralization. In fact, again considering the enormous IPv6 space
within a carrier, a distributed solution seems unavoidable in the
long run.

>       APMS A management system which has a centralized databse manage
>       the overall address pools and allocate address pools to the device
>       in the devices.

Again, although a central database is the traditional approach, we must
be open to a scalable approach and that means distribution. Certainly
there must be an *initial* pool that originates by human action in
the NOC. But that does not require a central database that records
every detail. 

If an ISP has say a /29 and is delegating /48 to subscribers, it
has to manage up to 2**19 prefixes. That isn't an impossible size
for a central database, but it is large. (And this is a small ISP.)
The problem becomes much easier if you distribute it among, say, 100
agents spread around the network.

Apart from that comment I like your model with numerous agents
in the network. Actually it corresponds very closely to the ANIMA
model except that we will distribute the function of the APM server
among those agents. In my toy implementation I found that it was
necessary to define an initial "master" agent that provides the
initial pool - the difference from your APM server is that the master
is identical to all the other agents except for having the initial pool.
(However, I repeat that this is a toy, not a serious implementation.)

I look forward to discussions in Chicago.

Regards
   Brian Carpenter