[Supa] SUPA for CASM?
"lichen.bri@chinatelecom.cn" <lichen.bri@chinatelecom.cn> Mon, 27 March 2017 19:40 UTC
Return-Path: <lichen.bri@chinatelecom.cn>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E5D129570 for <supa@ietfa.amsl.com>; Mon, 27 Mar 2017 12:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 gn-OPpUraun6 for <supa@ietfa.amsl.com>; Mon, 27 Mar 2017 12:40:44 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6212956E for <supa@ietf.org>; Mon, 27 Mar 2017 12:40:41 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.48:15117.140505556
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-31.133.130.132 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with ESMTP id 0A112280072 for <supa@ietf.org>; Tue, 28 Mar 2017 03:40:33 +0800 (CST)
Received: from ip<31.133.130.132> ([172.18.0.48]) by App0024(MEDUSA 0.0.0.0) with ESMTP id 34ff39c2-d5c7-4cc5-815d-f0937f4a5e3b for supa@ietf.org; Tue Mar 28 03:40:37 2017
0/X-Total-Score: 0:
X-FILTER-SCORE: to=<94969182618a8695874f909388>, score=<149064363755i55l55T5ilT09KNRf555ZZ9ZZqZZ/Z9q/5zeY2pZZZ>
X-Real-From: lichen.bri@chinatelecom.cn
X-Receive-IP: 172.18.0.48
X-MEDUSA-Status: 0
Date: Mon, 27 Mar 2017 14:40:32 -0500
From: "lichen.bri@chinatelecom.cn" <lichen.bri@chinatelecom.cn>
To: supa <supa@ietf.org>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 8, 379[cn]
Mime-Version: 1.0
Message-ID: <201703271440258426252@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart742640215041_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/supa/MmeewudBdD8mPR745d0QMZahcQE>
Subject: [Supa] SUPA for CASM?
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Mar 2017 19:40:48 -0000
Hi all, (Sorry that I’m late for this work.) You might already know that we’re proposing CASM BoF, to solve the issue of complex of address management for different scenarios. Besides CASM, I would like to see how can SUPA policy help us in dealing with close loop of address management, as we are also considering the policy mechanism of managing address, with a interface to issue the policy to CASM system and finally distribute to NEs. E.g., automatic allocate and reclaim for different scenarios, which can be found in CASM use case draft. We even have a demo to show the concept of flexibly allocate and reclaim address. If you need more details, I am happy to share. best regards Chen Li lichen.bri@chinatelecom.cn
- [Supa] SUPA for CASM? lichen.bri@chinatelecom.cn