Re: [Openv6] Starting discussion

"Guang Yao" <yaoguang@cernet.edu.cn> Tue, 28 January 2014 04:48 UTC

Return-Path: <yaoguang@cernet.edu.cn>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC251A0198 for <openv6@ietfa.amsl.com>; Mon, 27 Jan 2014 20:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level:
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535] autolearn=ham
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 nTqgmtWZqNiY for <openv6@ietfa.amsl.com>; Mon, 27 Jan 2014 20:48:42 -0800 (PST)
Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id CA2251A016B for <openv6@ietf.org>; Mon, 27 Jan 2014 20:48:41 -0800 (PST)
Received: from AndrewYaoPC (unknown [59.66.253.132]) by centos (Coremail) with SMTP id AQAAf3CLMgMhM+dSvsgKAA--.796S2; Tue, 28 Jan 2014 12:33:37 +0800 (CST)
From: Guang Yao <yaoguang@cernet.edu.cn>
To: "'Liushucheng (Will)'" <liushucheng@huawei.com>, openv6@ietf.org
References: <C9B5F12337F6F841B35C404CF0554ACB5FE6A1CF@SZXEMA509-MBS.china.huawei.com>
In-Reply-To: <C9B5F12337F6F841B35C404CF0554ACB5FE6A1CF@SZXEMA509-MBS.china.huawei.com>
Date: Tue, 28 Jan 2014 12:48:29 +0800
Message-ID: <000401cf1be4$302cf5a0$9086e0e0$@cernet.edu.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01CF1C27.3E51BC40"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFvW9gPnTcDP4CyGvej6nmQe2mzJptZEKEg
Content-Language: zh-cn
X-CM-TRANSID: AQAAf3CLMgMhM+dSvsgKAA--.796S2
X-Coremail-Antispam: 1UD129KBjvJXoWxXrWfWr15KFWrJr18KFW3Wrg_yoWrJFyUpF W3Gw47t3WkJr1xCr4kXw18uw45Wa97J3yUJFnxXr9Yyw4UAa4Ikrn5tw4rZFy5Xr97Xr12 qr1qqrs8CFnrZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c804VAF z4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC2z280aV AFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48IcxkI 7VAKI48G6xCjnVAKz4kxMxkIecxEwVAFwVW8XwCF04k20xvY0x0EwIxGrwC20s026c02F4 0E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1l IxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxV AFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUcJ 5rDUUUU
X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/
Subject: Re: [Openv6] Starting discussion
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 04:48:47 -0000

Hi Will and folks,

 

I want to introduce SAVI and discuss whether it can be adopted in the OpenV6
framework. 

 

SAVI(Source Address Validation Improvements, http://tools.ietf.org/wg/savi/)
sets up bindings between IP address and binding anchor. It has following
features:

 

1.       There are at least 3 SAVI solutions for IPv6: SAVI-DHCP,SAVI-FCFS,
SAVI-SEND. The solutions are designed based on the address assignment
mechanism (DHCPv6, Stateless, SEND-CGA). If new address assignment
mechanisms (or address usage guideline) are introduced, e.g., IKEv2, Mobile
IPv6, Ipv4/IPv6 transition, corresponding SAVI solutions should be
implemented.

 

2.       In general, only one of the SAVI solutions should be enabled,
depending on the deployment scenario.

 

3.       Multiple SAVI solutions can coexist on the same device. For
example, SAVI-DHCP and SAVI-FCFS may work together for the scenarios where
both DHCP and stateless addresses are allowed.

 

4.       SAVI solutions have the same data plane model (or abstraction):
binding table. Binding table contains the valid associations between IP
address and the corresponding binding anchor.

 

5.       The differences of SAVI solutions are in the control plane.
Difference SAVI solutions snoop difference protocols, and even data packets.

 

6.       SAVI solutions can benefit from a global view of the network,
because a protection perimeter composed by multiple SAVI devices can be
automatically formed.

 

We have implemented a prototype of Openflow-based SAVI. It is quite simple
and effective, but it's a pity that it cannot work with non-Openflow
devices. Besides, currently it is hard for the Openflow-based SAVI to
cooperate with other applications, e.g., transition applications. We are
interested in whether an Openv6-based SAVI can have more advantages than the
Openflow-based one? (it seems more general interfaces are supported?)

 

Best regards,

Guang

 

 

From: Liushucheng (Will) [mailto:liushucheng@huawei.com] 
Sent: Monday, January 27, 2014 4:16 PM
To: openv6@ietf.org
Subject: Starting discussion

 

(Sorry for duplicated mails.)

 

Hello,

 

Thanks for joining the Open IPv6 (openv6) mailing list. It's great to see so
much interest in the topic!

 

The following questions are listed to be discussed here: 
(1) What are the problems and use cases existing in various IPv6
applications, e.g., multiple IPv6 transition technologies co-exist? 
(2) How to enable the applications to program the equipment to tunnel IPv6
traffic across an IPv4 data plane? 
(3) How this work can be done through a general interface, e.g., to
incorporate the transition policies, simplifying the different stages
through the transition and guaranteeing that current decisions do not imply
a complicated legacy in the future? 
(4) How to make the end-to-end configuration of devices: concentrator/CGN,
CPE and the provisioning system? 
(5) How to extend the existing IETF protocols, e.g., netconf, to support
this open interface?

 

In addition to the above questions, we've laid out an initial description of
the problem in
https://datatracker.ietf.org/doc/draft-sun-openv6-problem-statement/ and are
looking for productive discussion and feedback on this list. We are now
modifying it and a new version will be released accordingly. :)

 

Regards,

Shucheng LIU (Will)

----------------------------------------------------------------------------
-------

Shucheng LIU (Will), Ph.D.

Researcher & Standard Representative 

Huawei Technologies Co.,Ltd

liushucheng@huawei.com <mailto:liushucheng@huawei.com> 

http://www.linkedin.com/in/shucheng

----------------------------------------------------------------------------
-------