答复: Tunnel Design Philosophy

Lizhenbin <lizhenbin@huawei.com> Sat, 31 October 2015 15:21 UTC

Return-Path: <lizhenbin@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE451A1B23 for <rtgwg@ietfa.amsl.com>; Sat, 31 Oct 2015 08:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.34
X-Spam-Level: **
X-Spam-Status: No, score=2.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Cevs80JmCItA for <rtgwg@ietfa.amsl.com>; Sat, 31 Oct 2015 08:21:44 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B151A1A5D for <rtgwg@ietf.org>; Sat, 31 Oct 2015 08:21:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDI60195; Sat, 31 Oct 2015 15:21:37 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 31 Oct 2015 15:21:36 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Sat, 31 Oct 2015 23:21:30 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: 答复: Tunnel Design Philosophy
Thread-Topic: Tunnel Design Philosophy
Thread-Index: AdEFapt5Fqf1Bn2CSemDcxAR3HYI/AAEY6RwA5zUlfE=
Date: Sat, 31 Oct 2015 15:21:29 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5E254@nkgeml506-mbx.china.huawei.com>
References: <004a01d1057c$47e02310$d7a06930$@org.cn>
In-Reply-To: <004a01d1057c$47e02310$d7a06930$@org.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.187.201]
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA5E254nkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/mxNFBKeG9lnU1Jeys1tT9AziQWc>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2015 15:21:48 -0000

Aijun,

Are you in Yokohama? Regarding your tunnel design philosophy, I would like to have a discussion with you before I do the presentation in RTGWG on Thursday.





Best Regards,

Zhenbin(Robin)









________________________________
·¢¼þÈË: rtgwg [rtgwg-bounces@ietf.org] ´ú±í Aijun Wang [wangaijun@tsinghua.org.cn]
·¢ËÍʱ¼ä: 2015Äê10ÔÂ13ÈÕ 13:58
ÊÕ¼þÈË: rtgwg@ietf.org; netmod@ietf.org
Ö÷Ìâ: Tunnel Design Philosophy

Hi, RTGWGer and NETMODer:

Here I want to ask for advices from any expert that is familiar with the usages and designs of various tunnel technologies that are wide deployed within the network.
What is the principle and philosophy about the design of Yang Model for these tunnel technologies?

Currently, there are several drafts that has touches this area, but there are some confusions about their designs, for example:
1. Can we organize these tunnel related-Yang models under one common tree?
2. What is the relationship between the tunnel related-Yang model and the interface Yang Model?

Our opinion is that Yang Model is one design tool/language used to standard the interface between the service provider and device(Device Yang Model), and between the service provider and their customer(Service Yang Model), then the design of them should from top to down, find the general aspects of every model branch first and augment them with specific technology later. This seems more common to all the Model/Object design language.

So, for above two questions, we recommend to design one general tunnel-related Yang model that augments from the interface Yang model, and expand to it to cover the various specific tunnel technologies. Doing so has the following benefits:
1. we can focus first the common characteristic of tunnel technology, especially the static tunnel technologies(dynamic tunnel for example MPLS-TE tunnel is the exception)
2. the appearance of the tunnel on router/switch are all one kind of interface. If it augments from the interface tunnel, it can inherit many variables of the interface Yang model.(several drafts have shown their overlapping design of these variables.)

So, how about your opinion and the reason to do them?
Wish can hear more valuable suggestions on the design of the Tunnel-related Yang Model.

Current available drafts about the Tunnel ¨Crelated Yang Model are bellows:
1. https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-v6-tunnel-yang-00
2. http://datatracker.ietf.org/doc/draft-wwz-netmod-yang-tunnel-cfg/
3. http://datatracker.ietf.org/doc/draft-wilton-netmod-intf-vlan-yang/
4. http://datatracker.ietf.org/doc/draft-liu-rtgwg-ipipv4-tunnel-yang/
5. http://datatracker.ietf.org/doc/draft-li-rtgwg-utunnel-yang/
6. https://tools.ietf.org/id/draft-ietf-teas-yang-te-00.txt( This draft is one exception, and seems can¡¯t be generalized with other five drafts)

Best Regards.


Aijun Wang

China Telecom Corporation Limited Beijing Research Institute
Intelligent Network Product Line