Re: [v6ops] Comments on draft-sun-v6ops-openv6-address-pool-management.

Qiong <bingxuere@gmail.com> Mon, 28 October 2013 05:17 UTC

Return-Path: <bingxuere@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD73111E8311 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2013 22:17:32 -0700 (PDT)
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=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szJTgvpaQKHw for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2013 22:17:32 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC511E80FC for <v6ops@ietf.org>; Sun, 27 Oct 2013 22:17:28 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id pa12so4178172veb.2 for <v6ops@ietf.org>; Sun, 27 Oct 2013 22:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HbWS7l32gvugz3slDHcyG9ITzjS7VS7FtAbG0AWFaYw=; b=Dp3g5xlyIVZBDGLCX+/t27FaQHYsjU8FJBuped1ZYxb8F7dKBRWkY934rceq96FByX KqLbM1pLzItnvRBOBDKmpEbZKl7ssatiWdk6kZkFpkZCMynh/J6AVJ/I0ziEO7r0LpWq UNIZGW9Dyf+5V5LyPxDRqUqzOj4Me7/qF7gGBmfPoXR87nYo49fFQssUAXGZi5JMPxv4 Vh9IAiIb3o5YpGD5V8rrhthlqH+46XCbNlJ71hjncvAL7TdSXVvXP/nN5/fA+PhNz7Q5 GusmdY6lgizAvAtQNuhYxBdnL9Q8gf+MASo+JXTD1HgH5+8bHZrhpGDxVS3LHHvS6wXz EgZQ==
X-Received: by 10.52.118.73 with SMTP id kk9mr10109505vdb.13.1382937447991; Sun, 27 Oct 2013 22:17:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.93.6 with HTTP; Sun, 27 Oct 2013 22:16:47 -0700 (PDT)
In-Reply-To: <OFB7C11E0F.00D5BD9F-ON48257C12.000D206A-48257C12.000F93F1@zte.com.cn>
References: <526D9FFC.9060307@cernet.edu.cn> <OFB7C11E0F.00D5BD9F-ON48257C12.000D206A-48257C12.000F93F1@zte.com.cn>
From: Qiong <bingxuere@gmail.com>
Date: Mon, 28 Oct 2013 13:16:47 +0800
Message-ID: <CAH3bfABwivjseYHkFp6RU-52WzrgZY+G-nmwautG+WOz5K+jLw@mail.gmail.com>
To: meng.wei2@zte.com.cn
Content-Type: multipart/alternative; boundary=089e0122f0f255923b04e9c63752
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Comments on draft-sun-v6ops-openv6-address-pool-management.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2013 05:17:33 -0000

Hi Wei,

Thanks for your review and comments.

Yes, we are trying to solve the problem of the scattered address pool
management. Currently, there are many transition devices deployed in our
network (even multiple transition instances will be needed for different
purpose or redundancy). However, different transition instance needs to be
configured with separated address pools. That will bring a great burden for
operators to manage rather scattered address pools.

More detailed protocol and parameters definitions are needed and will be
included in the next version. Here we would like to get
suggestions/comments from v6ops about this framework/solution.

Your further comments/suggestion/input are highly appreciated.

Best wishes
Qiong



On Mon, Oct 28, 2013 at 10:48 AM, <meng.wei2@zte.com.cn> wrote:

>
> Hi authors,
>
>     Sharing global IP address is a interesting topic of pool management.
> The pool
> management will be migrated to centralized mode to avoid complex
> configurations in
> NAT44/NAT64, even in DHCP pools.
>
>     I reviewed this draft. I'm not sure whether we should define more
> detail in
> request-ack between client and server? Or we should defined a specific
> protocol?
> Or we should define some parameters ,such as priority/threshold...
>
> Cheers,
>
> Wei Meng
> ZTE
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>


-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================