Re: [netmod] Tunnel Design Philosophy

["Aijun Wang" <[e-mail]>]

Hi, Zhenbin:

 

>From my opinion, if the Yang Model can¡¯t be organized from top to down,
from common to specific, then it will be very difficult for service provider
to adopt them within their network. The reason to adopt the Yang Model for
service provider is to accelerate the deployment of various services,
compared with the speed that the service provider must deal with the
different vendor/technology specific solution.

If we can¡¯t find the general aspects of different tunnel technologies,
abstract them into some general models, then the Yang model will be evolved
into MIB-alike results. Is this the aim of Yang Model? 

Can the influential router vendors support this opinion and make some
changes for the health evolution of ecosystem? 

 

Best Regards.

 

Aijun Wang

 

China Telecom Corporation Limited Beijing Research Institute 

Intelligent Network Product Line

 

 

 

From: rtgwg [mailto:[e-mail]] On Behalf Of Lizhenbin
Sent: Monday, November 02, 2015 3:17 PM
To: Aijun Wang; [e-mail]; [e-mail]
Subject: ´ð¸´: Tunnel Design Philosophy

 

Hi Aijun,

I think your tunnel philosophy is reasonable. But there may be challenges in
the real implemention to support the philosophy. The challenges are as
follows:

1. There are too many types of IP tunnels such as IPv6/IPv4 over IPv4
tunnel, GRE Tunnel, IPSec/IKE Tunnel, L2TP Tunnel,etc. And now NVO3 work
proposes 

more IP tunnel types such as VXLAN Tunnel, NVGRE, GPE, MPLS in UDP, etc.
Though these IP tunnels may share common aspects, they may have essentially 

different usages which is does matter. 

2. Different IP tunnels may need more pre-configuration and operational data
which are different from each other which is difficult to be accommodated in
the 

module. But when configure these tunnels, these pre-configuration has to be
provided firstly. So the tunnel common modules has to intereract with other
tunnel

implementation modules.

3. Common Tunnel modules may need more interaction with modules implementing
different types of modules. The complexity may increase as the number of 

tunnel types. It may need very smart people to understand all possible types
of IP tunnels for implementation of the tunnel modules.
4. All these IP tunnel types do not emerge all at once. Even the possible
common attributes shown in your your models did not emerge at the beginning.
So it is

very difficult to change the existing implementation to abstact the possible
tunnel common modules. 

In fact we have ever tried your method at the beginning and at last we gave
up since nobody could take the challenging work.

 

Best Regards,

Zhenbin(Robin)

 

 

 

 

 

 

 

 

 

 

  _____  

·¢¼þÈË: rtgwg [[e-mail]] ´ú±í Aijun Wang
[[e-mail]]
·¢ËÍʱ¼ä: 2015Äê10ÔÂ13ÈÕ 13:58
ÊÕ¼þÈË: [e-mail]; [e-mail]
Ö÷Ìâ: 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