Subject: [Supa] New charter of YMCA

From: Tina TSOU <[email-masked]>
Date: Wed, 15 Oct 2014 15:14:52 +0000

Dear Benoit, Parviz, Eric, Andrew et al,

Luis, Ying, Georgios and I sat together today, came out with the following new charter, hoping to accomadate the comments received these days.

Juergen said we really need a better name, so Luis suggested YMCA.

-------------
Yang Models for Configuration and topology Abstraction (YMCA) charter

Description of Working Group:

As the underlying network infrastructure grows, and new services/traffic are rapidly increased, it becomes significantly more challenging than in the past to maintain the network and deploy new services. Programmatic ways to configure and operate networks, often called software-defined, are considered by many network operators in order to provide significant benefits in deployment agility. Yang Models for Configuration and topology Abstraction (YMCA) attempts to achieve this configuration automation by introducing multi-level and multi-technology network abstractions. It plans to create YANG model of general network topology and YANG model of application-specific configuration to provide topology information as applications expect and map network-wide configuration/topology into individual device-recognized configuration. As a result, standardized interfaces between applications and network controllers of all types could be established and automatic and programmable configuration can be achieved based on these interfaces. Although several organizations outside and inside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral and technology-wide (i.e., L0 to L7) standardized way for applications to transmit their needs to controllers.

The main goal of YMCA is to provide Yang models of vendor neutral service specific abstractions for the VPN and Inter-DCs traffic steering and tunneling network services, which allow applications to request these network services from network controllers of all types, e.g., single or multiple controllers, to be quickly and dynamically created/deleted/modified, using mechanisms for exchanging information to and from the NEs.

Work items for YMCA include:
1) Yang Models of views of L0-L7 Network topology with bi-directional and uni-directional links
2) Using Yang Models defined in 1), map Service Specific Yang Models of VPN and DDC virtual links Network Configuration to NE Specific configuration of Tunnel Policy and Traffic Steering Policy
3) Specify how NEs can interact with local or remote network controllers (e.g., exchange configuration information, status, etc)

Deliverables:
=============
o) Produce an informational RFC "Problem Statement".
o) Produce a standards-track RFC that specifies YANG models of different views of L0-L7 Network topology
o) Produce standards-track RFCs that specify extensions for the generic YANG models defined above for VPN and Inter-DCs traffic steering and tunneling network services
o) Produce an informational RFC that provides the guidelines for mechanisms that can map the Service Specific Yang Models of VPN and DDC virtual links Network Configuration to NE Specific configuration of Tunnel Policy and Traffic Steering Policy.
o) Produce a standards-track RFCs that specify how NEs can interact with local or remote network controllers (e.g., exchange configuration information, status, etc)

Milestones:
===========
Mar 2015  Initial "Problem Statement" WG I-D
May 2015  Initial "L0-L7 network topology view YANG Model" WG I-D
Jul 2015  Initial "VPN service specific data model" WG I-D
Jul 2015  Initial "Inter-DC service specific data model" WG I-D
Aug 2015  Initial "Mapping Guidelines" WG I-D
Oct 2015  Initial "NE to/from Controllers information exchange" WG I-D
Sep 2015  Submit "Problem Statement" I-D to IESG
Dec 2015  Submit "L0-L7 network topology view YANG Model" I-D to IESG
Feb 2016  Submit "VPN service specific data model " I-D to IESG
Feb 2016  Submit "Inter-DC service specific data model " I-D to IESG
May 2016  Submit "Mapping Guidelines" I-D to IESG
May 2016 Submit "NE to/from Controllers information exchange" I-D to IESG
-----------------

Thank you,
Tina

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 16 Oct 2014 09:21:27 +0000

Melodious name, sounds like a song. :)

Regards,
Will

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Wednesday, October 15, 2014 11:15 PM
To: [email-masked]
Cc: [email-masked]; LUIS MIGUEL CONTRERAS MURILLO
Subject: [Supa] New charter of YMCA

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

Deliverables:
=============

Milestones:
===========

Thank you,
Tina

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 17 Oct 2014 15:16:32 +0800

Hi,

Some quick questions:

1.       Why YANG? Are there any alternatives? 

2.       Is YANG capable to accomplish the object?

3.       Some SDN controllers (e.g., ONIX) make use of NIB (network
information base) to store the network view. How can the NIB and YANG model
be related?

Best regards,

Guang

From: Liushucheng (Will) [mailto:[email-masked]] 
Sent: Friday, October 17, 2014 2:51 PM
To: sunqiong; xiechf; Kostas Pentikousis; [email-masked]
<mailto:[email-masked]> ; JF Tremblay; [email-masked]'; Jun
Bi; Guang Yao; [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]> 
Subject: FW: New charter of YMCA

Hi all,

Would you please review the new charter below and send your comments to the
list? Thank you!

Regards,

Will (Shucheng LIU)

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Wednesday, October 15, 2014 11:15 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; LUIS
MIGUEL CONTRERAS MURILLO
Subject: [Supa] New charter of YMCA

Luis, Ying, Georgios and I sat together today, came out with the following
new charter, hoping to accomadate the comments received these days.

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

As the underlying network infrastructure grows, and new services/traffic are
rapidly increased, it becomes significantly more challenging than in the
past to maintain the network and deploy new services. Programmatic ways to
configure and operate networks, often called software-defined, are
considered by many network operators in order to provide significant
benefits in deployment agility. Yang Models for Configuration and topology
Abstraction (YMCA) attempts to achieve this configuration automation by
introducing multi-level and multi-technology network abstractions. It plans
to create YANG model of general network topology and YANG model of
application-specific configuration to provide topology information as
applications expect and map network-wide configuration/topology into
individual device-recognized configuration. As a result, standardized
interfaces between applications and network controllers of all types could
be established and automatic and programmable configuration can be achieved
based on these interfaces. Although several organizations outside and inside
of the IETF have defined various schemes for the configuration of network
devices and specific network controllers, none of them offer a
vendor-neutral and technology-wide (i.e., L0 to L7) standardized way for
applications to transmit their needs to controllers.

The main goal of YMCA is to provide Yang models of vendor neutral service
specific abstractions for the VPN and Inter-DCs traffic steering and
tunneling network services, which allow applications to request these
network services from network controllers of all types, e.g., single or
multiple controllers, to be quickly and dynamically
created/deleted/modified, using mechanisms for exchanging information to and
from the NEs.  

1) Yang Models of views of L0-L7 Network topology with bi-directional and
uni-directional links

2) Using Yang Models defined in 1), map Service Specific Yang Models of VPN
and DDC virtual links Network Configuration to NE Specific configuration of
Tunnel Policy and Traffic Steering Policy

3) Specify how NEs can interact with local or remote network controllers
(e.g., exchange configuration information, status, etc)

Deliverables:

=============

o) Produce a standards-track RFC that specifies YANG models of different
views of L0-L7 Network topology

o) Produce standards-track RFCs that specify extensions for the generic YANG
models defined above for VPN and Inter-DCs traffic steering and tunneling
network services 

o) Produce an informational RFC that provides the guidelines for mechanisms
that can map the Service Specific Yang Models of VPN and DDC virtual links
Network Configuration to NE Specific configuration of Tunnel Policy and
Traffic Steering Policy.

o) Produce a standards-track RFCs that specify how NEs can interact with
local or remote network controllers (e.g., exchange configuration
information, status, etc)

Milestones:

===========

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

Thank you,

Tina

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 17 Oct 2014 20:40:12 +0000

Resending as I am not sure it really left by outbox...

From: Eric Voit, October 17, 2014 11:40 AM
To: 'Tina TSOU'; [email-masked]
Cc: [email-masked]; LUIS MIGUEL CONTRERAS MURILLO; 'Liushucheng (Will)'; sunqiong; xiechf; Kostas Pentikousis; [email-masked]; JF Tremblay; [email-masked]'; Jun Bi; Guang Yao; [email-masked]
Subject: RE: New charter of YMCA

I love the name YMCA.  However you might want to check with IETF legal on trademark issues with the YMCA<http://www.ymca.net/> (located in the US).  A quick scan shows no other WG names matching to well-known institutions.  More thoughts in line.

From: Supa, October 15, 2014 11:15 AM
Dear Benoit, Parviz, Eric, Andrew et al,

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

<Eric> Configuration and Topology is an arbitrary grouping of overlapping domains.  Per the meeting with Benoit, I can imagine the topology people for each protocol wanting to own much of their own abstractions.  (Because a topology is really a function of the protocol - i.e., the protocol is defining what is important about specific adjacencies at L1, L2, L3, etc.)

But perhaps the two term together "Topology Abstraction" could allow the pulling together of something generic across those protocols which might be interesting.  Specifically, how can you interact with an aggregate set of devices which have a relationship, and where the northbound applications don't care about the identity of specific devices.  Instead the applications want to config or monitor aggregate sets.  Some of this concept is certainly embodied in the text below.   Perhaps it could be teased out more?  More below...

As the underlying network infrastructure grows, and new services/traffic are rapidly increased, it becomes significantly more challenging than in the past to maintain the network and deploy new services. Programmatic ways to configure and operate networks, often called software-defined, are considered by many network operators in order to provide significant benefits in deployment agility. Yang Models for Configuration and topology Abstraction (YMCA) attempts to achieve this configuration automation by introducing multi-level and multi-technology network abstractions. It plans to create YANG model of general network topology and YANG model of application-specific configuration to provide topology information as applications expect and map network-wide configuration/topology into individual device-recognized configuration. As a result, standardized interfaces between applications and network controllers of all types domains could be established and automatic and programmable configuration can be achieved based on these interfaces. Although several organizations outside and inside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral and technology-wide (i.e., L0 to L7) standardized way for applications to transmit their needs to controllers.

The main goal of YMCA is to provide Yang models of vendor neutral service specific abstractions for the VPN and Inter-DCs traffic steering and tunneling network services,
<Eric> VPN, traffic steering, and tunneling are not particularly interesting to me.  I am sure they are for others.  Let me take some time to think about the abstractions I would think are interesting.  Dynamic NfV configuration comes to mind, but I haven't thought through the details.

which allow applications to request these network services from network controllers of all types, e.g., single or multiple controllers, or Network Element based controllers, to be quickly and dynamically created/deleted/modified, using mechanisms for exchanging information to and from the NEs.
<Eric>  Note: I think you run into IETF issues if you claim that the domain is for 'traditional' controllers Northbound.  Instead the abstractions could be also provided from Network Elements based controllers which represent an access point to a domain of devices.  By emphasizing this, you have less chance of people wondering why the IETF should care.

Work items for YMCA include:
1) Yang Models of views of L0-L7 Network topology with bi-directional and uni-directional links
<Eric> IMHO, if you are trying to enforce bindings between layers, this will prove very difficult.  If you are trying to define fields which are common for each Northbound abstraction from L0-L7, that could be interesting.

2) Using Yang Models defined in 1), map Service Specific Yang Models of VPN and DDC virtual links Network Configuration to NE Specific configuration of Tunnel Policy and Traffic Steering Policy
3) Specify how NEs can interact with each other locally, or with remote network controllers (e.g., exchange configuration information, status, etc)
<Eric> Yes, I like this one ;-)

Eric

Deliverables:
=============

Milestones:
===========

Thank you,
Tina

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 17 Oct 2014 15:40:26 +0000

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

Eric

Deliverables:
=============

Milestones:
===========

Thank you,
Tina

---

From: Ying Cheng <[email-masked]>
Date: Tue, 21 Oct 2014 10:24:34 +0800

Hi Eric,

Thanks for your comments. Please see my response for some of them in line. 

BR,
Ying

2014-10-21 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： Eric Voit (evoit) 
发送时间： 2014-10-18  04:43:26 
收件人： Tina TSOU; [email-masked] 
抄送： 
主题： Re: [Supa] New charter of YMCA 
 
Resending as I am not sure it really left by outbox…

I love the name YMCA.  However you might want to check with IETF legal on trademark issues with the YMCA (located in the US).  A quick scan shows no other WG names matching to well-known institutions.  More thoughts in line.

 
 
-------------
 
<Eric> Configuration and Topology is an arbitrary grouping of overlapping domains.  Per the meeting with Benoit, I can imagine the topology people for each protocol wanting to own much of their own abstractions.  (Because a topology is really a function of the protocol – i.e., the protocol is defining what is important about specific adjacencies at L1, L2, L3, etc.)
 
But perhaps the two term together “Topology Abstraction” could allow the pulling together of something generic across those protocols which might be interesting.  Specifically, how can you interact with an aggregate set of devices which have a relationship, and where the northbound applications don’t care about the identity of specific devices.  Instead the applications want to config or monitor aggregate sets.  Some of this concept is certainly embodied in the text below.   Perhaps it could be teased out more?  More below…

[Ying]Agreed with the above modification.
 
The main goal of YMCA is to provide Yang models of vendor neutral service specific abstractions for the VPN and Inter-DCs traffic steering and tunneling network services, 
<Eric> VPN, traffic steering, and tunneling are not particularly interesting to me.  I am sure they are for others.  Let me take some time to think about the abstractions I would think are interesting.  Dynamic NfV configuration comes to mind, but I haven’t thought through the details.
[Ying]IMHO, other area using YMCA are helpful and welcomed. Taking China Unicom as an example, VPN and Inter-DCs traffic steering and tunneling network services are important for the current cloud services deployment and provision. I am also interested in dynamic NFV configuration you mentioned and looking forward to more details.
 
which allow applications to request these network services from network controllers of all types, e.g., single or multiple controllers, or Network Element based controllers, to be quickly and dynamically created/deleted/modified, using mechanisms for exchanging information to and from the NEs.  
<Eric>  Note: I think you run into IETF issues if you claim that the domain is for ‘traditional’ controllers Northbound.  Instead the abstractions could be also provided from Network Elements based controllers which represent an access point to a domain of devices.  By emphasizing this, you have less chance of people wondering why the IETF should care.
[Ying]The solution you mentioned is feasible. It is proposed to discuss this issue in details.

 
Eric
 
Deliverables:
=============
 
Milestones:
===========
Mar 2015  Initial "Problem Statement" WG I-D
May 2015  Initial "L0-L7 network topology view YANG Model" WG I-D
Jul 2015  Initial “VPN service specific data model” WG I-D
Jul 2015  Initial “Inter-DC service specific data model” WG I-D 
Aug 2015  Initial "Mapping Guidelines" WG I-D
Oct 2015  Initial "NE to/from Controllers information exchange" WG I-D
Sep 2015  Submit "Problem Statement" I-D to IESG
Dec 2015  Submit "L0-L7 network topology view YANG Model" I-D to IESG
Feb 2016  Submit “VPN service specific data model " I-D to IESG
Feb 2016  Submit “Inter-DC service specific data model “ I-D to IESG
May 2016  Submit "Mapping Guidelines" I-D to IESG
May 2016 Submit "NE to/from Controllers information exchange" I-D to IESG
----------------- 

Thank you,
Tina

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.