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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 27 February 2017 23:54 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 7DC2B126DFB; Mon, 27 Feb 2017 15:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 XCOD8meVjVT3; Mon, 27 Feb 2017 15:54:31 -0800 (PST)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 B9EEC127077; Mon, 27 Feb 2017 15:54:28 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id 25so20646785pgy.0; Mon, 27 Feb 2017 15:54:28 -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=Y7DvwihHWnTQC50H3m1r1iV3A7pYgQkxNztYHHSp0nI=; b=a95hVz0gJV0trh2RU6FcvCUVNVlWjuMAS4SGN+vLDDGs+HB0LXgjAL7eP7MUlmLREW +Etzc8cw8JoCGMnIw1/Kwvqdn6DQH/XfYKfWe0dc+9YLqdUrBtKbF3CP6cp4RyKNqLDt IsrGiNbb+EvavE5LSoHGiCD5rW/9kWguE2XfRr0Xt0lAXne+HgEYIIdidSXDt831hIGa 0pEqckKumWudewD/GzKJdo+M6IfUAxDOkTKCAtx60pD5uFasAwnMkFHOzVH1JX0vNS4Q yMXoDY0JUK18u/hqHQcj5AwYZ4TDYKN+MgkW+d91pyF7Lj93pJjNffkFiJnRLRIgM3iJ pLHw==
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=Y7DvwihHWnTQC50H3m1r1iV3A7pYgQkxNztYHHSp0nI=; b=AKEwhEckVyv/zLmc9UrGMtighzKbU5lMpbzlV1+qVyffPNDBrRCc8WTuJJQgpnQvrt U5BIHfBN0jm+e5Sfa7tS9ZubUiJOyEOBEUByRKN/f8D1+oPTRoJxHtNFMG6iw51+rUpW jHpoCD66i1iVRMWXPDRKOq33PBWPB8pWFmgfCBo4PdvLkMrDuZJbzZBya/4ImE7+TQAv T3hkfICH/zKO0vxWYFf9dYkz5rHCSUgluEQLeSW2dhaYCshXNZ2X3z0N2V0BVRuDjRXH fX8Kzmuj7V4A7WwoQBfbhk9XMCjQKD80pnKvYwIbmJLsJfbIjMUxU3NAW1B6ug+ZI9yL V1IQ==
X-Gm-Message-State: AMke39lKPwOLVRPolii2ig8jh7hKIDbXu5PUHs3b+beEKSHIdhds/kFyivgtKwnP147F+g==
X-Received: by 10.98.16.14 with SMTP id y14mr23841786pfi.63.1488239668293; Mon, 27 Feb 2017 15:54:28 -0800 (PST)
Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id t6sm32881661pgo.42.2017.02.27.15.54.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 15:54:27 -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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <1aed9ffa-5c0f-40ea-6afd-0af58930961a@gmail.com>
Date: Tue, 28 Feb 2017 12:54:23 +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: <2017021522094618095419@chinatelecom.cn>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/casm/8UnImzG0EDLjwBtQncc9b3h-76I>
Cc: "lichen.bri@chinatelecom.cn" <lichen.bri@chinatelecom.cn>, draft-ietf-anima-prefix-management@ietf.org, "'Liushucheng \(Will\)'" <liushucheng@huawei.com>, "wanghn.bri@chinatelecom.cn" <wanghn.bri@chinatelecom.cn>
Subject: Re: [Casm] =?utf-8?q?Which_interfaces_does_CASM_plan_on_standardizing?= =?utf-8?b?P++BoQ==?=
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: Mon, 27 Feb 2017 23:54:34 -0000

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
>