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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 13 May 2017 02:00 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 6F4DE129C34 for <casm@ietfa.amsl.com>; Fri, 12 May 2017 19:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hpAWnBKJYe4x for <casm@ietfa.amsl.com>; Fri, 12 May 2017 19:00:25 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 60C0C129C4B for <casm@ietf.org>; Fri, 12 May 2017 18:57:48 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id e193so37717068pfh.0 for <casm@ietf.org>; Fri, 12 May 2017 18:57:48 -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=g6wgJPMDTuPgrgOt5865oNfZ5xB45z6BogtPjkHKRbo=; b=jnlJN5SgaXXOImXVYfRPXidYijW5YxZ7W25DX03rqO0pHEmcLme/Z1No7vQHofV2qs qVFt974DwoTbA+xinq/ZYEXqke1vxA7C9XVR6PdpuJ+qQ00P6Uy2Unw7zTdDRhgvuN2O kk7sAG7U5I4J41rmowmmKbzPyFpov+/eXJ002OD4lS1IMTG37RWf3kHCBCSAyk/KmGxb lp1gWv2nazkUMK4D1IazNJ0IBfOBLJ83ny5uEwXbwdmLFHwijW5r6LF+ShPzABsjFg/g GzLlPTYcEmWN68YIJ80wN/TAcCisjgeib0bo7jOQPEkPvQ7ih/eNjwyNZJDMHBftLp7d nsnQ==
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=g6wgJPMDTuPgrgOt5865oNfZ5xB45z6BogtPjkHKRbo=; b=KP2h29flGqlkgZV3aFwAvRdrhZX0NcB6LCHSwf0j6r4j6hd6cGdkrsqkMoSDWkkgqL gmg8hnEAIvuTN9FaFyRskHIPExa2/We58x8LfLGuUpFBDWYWXDqghqKHa3JhBL8Kga6I lvKnFwAGaExImERatzSEh4tQ/F/bbsna9TLUNX+DduIfkLEtIeaTIh7MtNNdDp7K9USJ iPpg9NZwW5q3gBl3oxGOjjG+Kcpn+IkyICw8ndtIotru1lqYoI3liO9dgnp/XOKYV5cT hFHKQDE43FvwpjcxkDetyr32TwbUD5rN4fDT2dpzhmJkSMhA/m9RGzBz9lc8aAHcy6as EGqg==
X-Gm-Message-State: AODbwcAj1XwYixOB8tJQAI3dHCkfDjMp7BxZ7THIjtRjEuFiSvx66E+L /VHuM4mnJnZGWv3o
X-Received: by 10.84.176.100 with SMTP id u91mr9581600plb.39.1494640667776; Fri, 12 May 2017 18:57:47 -0700 (PDT)
Received: from [192.168.178.21] ([118.149.101.24]) by smtp.gmail.com with ESMTPSA id g23sm729538pfb.54.2017.05.12.18.57.46 for <casm@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 18:57:47 -0700 (PDT)
To: casm@ietf.org
References: <149395650243.6922.17434599893857692648@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <aafc4043-06bf-e48c-ac05-4fe1396d0040@gmail.com>
Date: Sat, 13 May 2017 13:57:57 +1200
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: <149395650243.6922.17434599893857692648@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/88GVRT5YAt_nsYf_wljWWlk4D_w>
Subject: Re: [Casm] I-D Action: draft-li-casm-address-pool-management-architecture-00.txt
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: Sat, 13 May 2017 02:00:26 -0000

Hi,

Thanks for this interesting draft.

First, here is one of the definitions:

>       CASM Coordinator: A management system which has a centralized
>       database manage the overall address pools and allocate address
>       pools to the device in the devices.

Ther is no need for this database to be centralized or for the
allocation of address pools to be centralized. It can be done with
a completely distributed system. (I agree that centralized logging
might be needed.) In fact, sections 4.2 and 4.3 describe a centralized
model for everything, not just for logging.

Could we perhaps agree that this is only one possible architecture?
If so, we would also need a second draft describing a distributed
architecture. It's quite hard to cover both designs in one document.

>    The overall procedure is as follows:
> 
>    o  Operators will configure remaining address pools centrally in the
>       Address Pool Management System (APMS).  There are multiple address
>       pools which can be configured centrally.  The APMS server will
>       then divide the address pools into addressing unit (AU) which will
>       be allocated to the agent in devices by default.

Certainly the NOC will configure initial address pools into a master agent.
But from that moment, a distributed process can take over in which pools
(prefixes) will allocated to distributed agents on demand, with no need
for default allocations.

>    o  If the lifetime of the address pool is going to expire, the DA
>       should issue an AddressPoolRenew request to extend the
>       lifetime,including the IPv4, IPv6, Ports, etc.

A couple of questions on this.:

1. Why is the lifetime useful? Firstly, once an address has been
allocated to an end-user, it must be left there as long as necessary;
you can't recover an address while it is in active use. That will
block the address pool that contains it indefinitely, so what is the
value of the lifetime? Secondly, if there is no lifetime, the agent
can release the address pool on demand if it is not in use. Again,
there is no value in the lifetime that I can see.

2. Is it really useful to include the notion of ports in an address
pool? In the case of IPv6 it is definitely useless. In the case of
IPv4 with A+P (port-based address sharing, RFC6346), surely you never
want to share a single address across different agents? That would
lead to complex and fragile CASM operations at rather high frequency.
RFC6346 defines how A+P gateways may talk to each other (horizontally,
not north-south) to share an address using A+P. You seem to be
duplicating that function. Also, RFC7768 seems to assume that port
sharing occurs entirely within a single CGN. So it seems to me that
it's wrong to include port ranges in the CASM model.

(Note: I have no problem with 'port-range' being defined in the
CASM YANG model; that seems necessary for completeness. My problem
is with using it in network-wide resource management, which doesn't
seem reasonable.)

> 5.1.1.1.  Address pools
...
>    o  IPv6 addresses

I suggest dividing this into 'Globally routable' and 'ULA'

>    o  MAC Addresses

Can you explain this? Where do layer 2 addresses fit in?

...
>   Multicast address pool:

This topic needs more discussion.

Regards
   Brian