Re: [Casm] Which interfaces does CASM plan on standardizing?

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 28 February 2017 02:18 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 D5263129498; Mon, 27 Feb 2017 18:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 1-y_-gk3-fK9; Mon, 27 Feb 2017 18:18:51 -0800 (PST)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 4F2541293F0; Mon, 27 Feb 2017 18:18:51 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id s67so51487920pgb.3; Mon, 27 Feb 2017 18:18:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CVytQU4I48dH3K2MpSc2+ySxh+dVeGuofnvjxgtU+ZY=; b=hVwaVjfgPN6yLDWAONqtw1xnZLEHF/rgVfHVblVDzZB2h0oiS//FEjG6Q67xWDlvua Qzdqu2dTB26b4IdKvPaIhtJPUiIkawBZg9MM74s4iMcL/NubB5rOpx5a9I1XdueoEcrt o+wEYRIXErH3AbmD8Z4DN0yQDAWfJerw5SvO4Awoh0YRM256LTYXTke1Z3Xm6iDq/BoO 9pKKNq8B2s3LnM10mf0Jyek9Z7BQFXuuLMmgEjrzLw6GzJopgMrrnmIOHcI8AUzUGvwO ytEMPPqPIvyMCFOezqS7VYKayL3Pql2UUtUs1KxUKZLXn4KxBx5MYyJoVTZ6jysdLuXp +qVQ==
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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=CVytQU4I48dH3K2MpSc2+ySxh+dVeGuofnvjxgtU+ZY=; b=WLoh7VUQMPBfpC9uDcZcCIJNJAmXevS1EQRrrc3jAltS55QB9q1BJ26vIPKCyz/cPr FWW1wc0Y1xO6uARPazz7nRWKx0IYgqsfKO9qqilfxmw6Nw5PgIgn8xivvH5/RPyIlJm7 Xo5IVtMwe6bv2yFR5syhnDC+oyL7ij6ntxI9wYn586fwohpRZOWRzgTsfva0ApfRJCjw 8239GCY06sKwqXwwhsgdXR8dRy9TKL623vZro5FV1aTUuijNtezJBmI+HsXJgiGJlfuo D5BxkRHP0glX2Qyoy0xJU9SLeFT7BFCioeOUDU/rPFLXlZSZQiqiAJvE//aEPlmal0pw g/NQ==
X-Gm-Message-State: AMke39mn8ImTXa/YzW98UgZEU915sQLQKAym1a858DsoHE3wjXDqfqZ6+8xQVE5f4U+OVA==
X-Received: by 10.84.217.212 with SMTP id d20mr28540732plj.53.1488248330711; Mon, 27 Feb 2017 18:18:50 -0800 (PST)
Received: from [192.168.178.21] ([118.148.75.173]) by smtp.gmail.com with ESMTPSA id p17sm244893pfi.97.2017.02.27.18.18.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 18:18:49 -0800 (PST)
To: Xie Chongfeng <xiechf.bri@chinatelecom.cn>, "marc.blanchet@viagenie.ca" <marc.blanchet@viagenie.ca>, bclaise <bclaise@cisco.com>, "CASM@ietf.org" <CASM@ietf.org>
References: <2111FF63-4AAA-4C50-8358-39CD55397D82@juniper.net> <B39211B7-A3CD-4C94-B5CF-470EB319244A@viagenie.ca> <2017021522094618095419@chinatelecom.cn> <1aed9ffa-5c0f-40ea-6afd-0af58930961a@gmail.com> <2017022809122853035318@chinatelecom.cn>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <d8b47200-0660-f663-d643-a05a8f11b678@gmail.com>
Date: Tue, 28 Feb 2017 14:57:11 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <2017022809122853035318@chinatelecom.cn>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/p2Cc4OM5dAWTBRVeRSdOLjwrnlE>
Cc: "lichen.bri@chinatelecom.cn" <lichen.bri@chinatelecom.cn>, draft-ietf-anima-prefix-management <draft-ietf-anima-prefix-management@ietf.org>, "'Liushucheng (Will)'" <liushucheng@huawei.com>, "wanghn.bri@chinatelecom.cn" <wanghn.bri@chinatelecom.cn>
Subject: Re: [Casm] Which interfaces does CASM plan on standardizing?
X-BeenThere: casm@ietf.org
X-Mailman-Version: 2.1.17
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, 28 Feb 2017 02:18:53 -0000

Hi,

On 28/02/2017 14:20, Xie Chongfeng wrote:
> 
> Hi,  Carpenter,
> 
> It is nice to receive your comments. 
> 
> CASM and ANIMA differ with each otherin the following aspects. 
> 
> Firstly, ANIMA is a self-managing in  
> AUTONOMIC networking environment, the configurations to network elements 
> are mainly done by the network elements themselves. while in CASM, in order 
> to make the task easier, we propose the use centralizedserver or platform to do 
> the configuration task, of course, the server may be distributed physically. 

Yes, I understand the different models. What I hope is that the two approaches
can be consistent as far as possible. So if you can express the policy to
a CASM system, and we can express the policy to an Autonomic Service Agent,
we get similar results. That's why I asked about the level of abstraction,
not about the details.
 
> Secondly, they have different use case, more the 3 
> years ago, I had a long talk with Dr. Jiang Sheng in Beijing, and propose 
> that the IP RAN may be a suitable use case to ANIMA, although the name 
> didn't exist yet.  the primary use case for CASM is the address pool 
> configuration for broadband IP network, CT has implemented the whole system 
> based on the current CASM dratfs, and 3 vendors have joined the field test 
> last year. The field trial prove this approach can solve the issues we 
> are concernd with.

I have no doubt of that, and Anima is not yet a mature technology. However,
the Anima solution can be much broader than the IPRAN case - any device roles
that involve prefix delegation could easily be covered. So I think it is
quite important to have comparable policy options.
> 
> The detailed description of the interface is shown in,
> https://datatracker.ietf.org/doc/draft-sun-i2apm-address-pool-management-yang/

OK, I will try to study that.

Regards
   Brian
> 
> 
> Thank you!
> 
> Chongfeng  
>  
> 
> 
> 
> 
> xiechf.bri@chinatelecom.cn
>  
> 发件人: Brian E Carpenter
> 发送时间: 2017-02-28 07:54
> 收件人: Xie Chongfeng; marc.blanchet@viagenie.ca; bclaise; CASM@ietf.org
> 抄送: lichen.bri@chinatelecom.cn; 'Liushucheng (Will)'; wanghn.bri@chinatelecom.cn; draft-ietf-anima-prefix-management
> 主题: Re: [Casm] Which interfaces does CASM plan on standardizing?
> Hi Chongfeng,
>  
>> Network operation team needs configure manaually IP address pool in each  
>> BRAS/vBRAS
>  
> Obviously that is a hopeless task. That's exactly why this is one
> of the test cases for ANIMA. So can you please comment on the
> level of detail needed in that interface? Is it similar to
> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-02#section-6.1
> That is an example for an IPRAN operator.
>  
> Note, I'm not asking about technical details - just about the
> level of abstraction.
>  
> Regards
>    Brian Carpenter
>  
> On 16/02/2017 03:09, Xie Chongfeng wrote:
>>
>> Hi,Benoit and all,
>>
>> This subject was originally raised by China Telecom, our use case is clear and straightforward.  In CT's network, there are tens of thousands of BRAS equipments,which are the major gateway to the broadband users. When the vBRAS was introduced, the volume will be even higher. Network operation team needs configure manaually IP address pool in each  
>> BRAS/vBRAS, which are time-consuming and low -efficient. Can DHCP solve this problem? The answer is NO, since DHCP deals with address allocation for end users.   
>>
>> In order to autimate the configuration process and improve the IP adress usage, a centralized address pool managment approach may be more reasonable. We discucssed with verdors and carriers, we found that there have been some proprioritary inplementations, they differ in the south-bound interface, so  we propose to standardize the south-bound interface in the early stage, which will benefit to all the players.
>>
>> Since the requirements are pressing to CT, we begun the filed trial last year and 3 vendors have implementated the interface defined in draft-sun-i2apm-address-pool-management-yang, luckily they all passed the field test by our joint efforts.
>>
>> As mentioned in other drafts of CASM, the address management capability will be  opened to other applications,such as SDN and Cloud , the  north-bound interface will be standanized as well.  
>>
>> Of course, in order to define the interface and its relatvie workflow, a unified framwork or architecture will need to be defined in advance.
>>
>> Thank you!
>>
>> Chongfeng Xie 
>>
>>
>>  
>>
>>
>>
>> xiechf.bri@chinatelecom.cn
>>  
>> From: Marc Blanchet
>> Date: 2017-02-14 20:24
>> To: Rakesh Kumar
>> CC: Liushucheng; Xie Chongfeng
>> Subject: Re: IPAM design from microsoft
>> will look into it. were you able to get Bloomsberg or else to support the work?
>> Marc.
>> On 14 Feb 2017, at 6:57, Rakesh Kumar wrote:
>> HI,
>>  
>> I found a very good document on the web from Microsoft about IPAM. This is good document that explains some of the concept we have listed in the drafts.
>> I thought, you guys might want to take a look at this for your reference.
>>  
>> Thanks & Regards
>> Rakesh
>>
>>
>>
>> _______________________________________________
>> CASM mailing list
>> CASM@ietf.org
>> https://www.ietf.org/mailman/listinfo/casm
>>
>  
>