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 [[email protected]] 代表 Aijun Wang [[email protected]]
发送时间: 2015年10月13日 13:58
收件人: [email protected]; [email protected]
主题: 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



_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to