Re: [Casm] FW: notes from my side

Brian E Carpenter <> Tue, 14 March 2017 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 061A012948C for <>; Tue, 14 Mar 2017 07:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P_iOVHIyyMGU for <>; Tue, 14 Mar 2017 07:58:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3457F128C84 for <>; Tue, 14 Mar 2017 07:58:30 -0700 (PDT)
Received: by with SMTP id m27so48733314iti.0 for <>; Tue, 14 Mar 2017 07:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=CqjLLKOm5YNZGj2igHTOTt3PvS2NX4grP6qL4RfGmNQ=; b=uZ6FlWI5jdHvhXO/pdI9lkdbtzY+y5cdaQiK7u/6rsW49V4ou/sCnEy4pD72InWQfR L8B8NXiZ2OWvzm3aH+eiFTSoj2sqzra+6RznfmaBNTKePkhMLwTQ9ZP3Igm4o9ZPD3UG wx46exACthaXuSy2G+B4M6vck9ZBgwurSrtEOYdDmIBgj2UcqCHnogH8el+e5jTZf5XY g0WUkTI4qMQpN7Cfz2h6xg/R7NQRWRhEMh9COEc5Nx7AauP6WnNxyOtu5rCA3FKvM/a/ dS4DwmbMFJFjyGhrJiiy2etOkLHypx4yKnT+b+DmkVFlp3hOXDaLOvceMe8MGe587Yi4 OleA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=CqjLLKOm5YNZGj2igHTOTt3PvS2NX4grP6qL4RfGmNQ=; b=UnoaN+nJPAD941oIJucMPhmYuZu4+Qk79H4YAKPfalPH18mM3sNwllwyCHU4TcitIq 3F10U2uUw0ZXzyEUmTAP2tFJWGN1Ym7jOcY3cxjbRn+RantNEPHnWxF+v8Gn8DX2HlEJ 4f6jX2410xjc+Tz5uxgGA+VKUfm8VHnAkrMPUSj8cR0mkHBFZeEaKX21oq03KQmP6NcK c0jgA6wwv1SGF/Bw4w9EcKM71zTqtsleQO8pbdIlXo2nZcE6hKBcFM2FG7wq3jEXjVId 2Y9W3TYI7M2DBdyDN9AMk+kxqySMy/adpghQ7NH/x3mAiCeBK78An4OuI6DVDNmnQH7Y W7Gg==
X-Gm-Message-State: AFeK/H3roY7zTwTH0fYUaTFFU5c0oTS4El5IrkqIKXkD81I20UzKGam/ku7y5Qomu94/6w==
X-Received: by with SMTP id v23mr17114596ite.100.1489503509439; Tue, 14 Mar 2017 07:58:29 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j102sm52083ioo.40.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 07:58:28 -0700 (PDT)
To: Rakesh Kumar <>, "" <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 15 Mar 2017 03:58:33 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Casm] FW: notes from my side
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Centralized Address Space Management <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 14:58:33 -0000

On 14/03/2017 17:50, Rakesh Kumar wrote:
> Hi Brian,
> The “address” record mean a fully qualified address or a network prefix, basically whatever the allocation unit is by address management functions.

OK, but that does need to be defined as part of the scoping of this work;
you can't assume that it is understood the same way by everybody. However...

> Yes, we have to ensure data models are flexible but I think, this should be a common practice anyway. I believe RFC 7277 discuss this.
> I hope, this is what you had asked about.

Not exactly. Yes, it is fairly simple to represent a single prefix or single address.
But when you think about the basic purpose of this work, i.e., allocating prefixes
out of prefixes and maintaining a record of what has been allocated, on a scale that
might extend from say /20 out to /64 in the case of IPv6, I think that the question
of data representation is quite complex and certainly not addressed by RFC 7277.
IPAM systems have to solve this internally of course, but the question is how much
of that complexity needs to be expressed in the API. For example, do we need the
ability to attach a bitmap to a prefix, indicating which subprefixes are available
or unavailable?

(I don't suggest that we need to decide this now, but I would be worried if we
decided in advance that the simple model is sufficient. That's why I asked what
"address records" means.)


> Regards,
> Rakesh
> On 3/13/17, 5:01 PM, "Brian E Carpenter" <> wrote:
> Hi,
> Does "interface to get/update address records" really mean *address* records?
> It seems to me that the elementary item should be a prefix (with IPv4/32
> and IPv6/128 being used for individual addresses when appropriate) or a
> choice between a prefix and an address if you prefer.
> (draft-xie-ps-centralized-address-management mentions this aspect)
> It seems to me one has to think very carefully about this, because for
> IPv6 the number of prefixes (and of course of addresses) can be extremely
> large. The data representation can be tricky.
> Regards
>    Brian Carpenter
> On 14/03/2017 04:34, Rakesh Kumar wrote:
>> From: "Liushucheng (Will Liu)" <>
>> Date: Monday, March 13, 2017 at 1:55 AM
>> To: Rakesh Kumar <>
>> Subject: RE: notes from my side
>> Dear Rakesh,
>> After a second read, I think this email is very clear and worth to post to list so that to answer Warrant’s question about scope.
>> Regards,
>> Will LIU (Shucheng LIU)
>> From: Rakesh Kumar []
>> Sent: Thursday, March 09, 2017 4:32 PM
>> To: Liushucheng (Will Liu) <>om>;; Marc Blanchet <>ca>; Ralph Droms <>
>> Cc:; 'Ying Cheng' <>cn>; Pengtao (Tony) <>om>; Xie Chongfeng <>cn>;; Rakesh Kumar <>
>> Subject: Re: notes from my side
>> Hi Will,
>> My apologies for late response.
>> Like you mentioned there are two set of interfaces as shown in the draft:
>> 1.       Client/Northbound interface to allow unified access to address management system (CASM). This should be RESTful interface with YANG data model.
>> 2.       Addressing function/Southbound interface to get/update address records. This could be protocol or RESTful interface but in my opinion, it is better to do RESTful interface so that existing system (standard-based or proprietary) could implement CASM defined interface on top of these functions to integrate with “CASM”.
>> I hope this gives us a very clear charter.
>> Thanks
>> Rakesh
>> From: "Liushucheng (Will Liu)" <<>>
>> Date: Thursday, March 2, 2017 at 6:05 AM
>> To: "<>" <<>>, Marc Blanchet <<>>, Ralph Droms <<>>
>> Cc: "<>" <<>>, 'Ying Cheng' <<>>, "Pengtao (Tony)" <<>>, Xie Chongfeng <<>>, Rakesh Kumar <<>>, "<>" <<>>
>> Subject: notes from my side
>> Sorry that due to my pc, I missed some. Here is what I have, hope can help Adrian:
>> Attendees: Adrian Farrel, Chen LI(China Telecom), Declan Ma(ZDNS), Ignas Bagdonas, Laurent Ciavaglia(AL/Nokia), Ralph Droms,  Ying CHNEG(China Unicom),Will LIU(Huawei), Tony Peng(Huawei)
>> Will: Unfortunately neither Rakesh from Juniper nor Chongfeng from CT can join us. However, we can use the framework draft to show their ideas, which is the interface or interfaces they want to standardize, and what are the scope. IMOH, in Rakesh draft there are two interfaces, NBI and SBI. Chen, please let them know how is your prototype working with these two interfaces.
>> Chen LI: SBI - netconf with YANG models, connecting three vendors develop;
>> NBI - restful , connecting with APP, now only one APP, but the system can connect to multiple, such as OSS, orchestrator.
>> Regards,
>> Will
>> -----------------------------------------------------------------------------------
>> Shucheng LIU (Will), Ph.D.
>> Senior Researcher & Standard Representative, Project Manager
>> Huawei Technologies Co.,Ltd
>> Email:<>
>> -----------------------------------------------------------------------------------
>> _______________________________________________
>> CASM mailing list