Re: Rquesting An MPLS-TP Creation Review
To be honest, the time is very inconvenient for us (3 a.m. in the morning), but add to that some of our core members have language barriers when it comes to speaking and listening to English. However, They do have good reading and writing skills in English.
So if it is possible, we would like to do our creation review over e-mail.
From: Colin Dixon [mailto:colin@...]
Sent: Friday, April 08, 2016 12:27 AM
Cc: Weiqiang Cheng; 박수명; 임창규; 신지수; Pradeeban Kathiravelu; George Zhao; Wang Lei; lihan; zhangtingtingyjy; liqin; project-proposals@...; tsc@...
Subject: Re: Rquesting An MPLS-TP Creation Review
Would you be available to do the creation review on 4/14 at that time then? If attending at that time is too difficult, we are also experimenting with doing creation reviews over e-mail in those cases.
On Wed, Apr 6, 2016 at 2:33 PM, 박세형 <labry@...> wrote:
Thank you for your offer.
However, I am on a business trip right now and will not be able to do the creation review on 4/7 10a pacific time.
I've attached some YANG files in my other email, so please check.
보낸 사람 : "Colin Dixon" <colin@...>
보낸 날짜 : 2016-04-05 23:40:49 ( +09:00 )
받는 사람 : 박세형 <labry@...>
참조 : Weiqiang Cheng <chengweiqiang@...>, 박수명 <smpahk@...>, 임창규 <human@...>, 신지수 <jshin@...>, Pradeeban Kathiravelu <kk.pradeeban@...>, George Zhao <George.Y.Zhao@...>, Wang Lei <wangleiyj@...>, lihan <lihan@...>, zhangtingtingyjy <zhangtingtingyjy@...>, liqin <liqinyj@...>, project-proposals@... <project-proposals@...>, tsc@... <tsc@...>
제목 : Re: Rquesting An MPLS-TP Creation Review
Sorry for delaying so long, this project proposal has been public since 3/16, so you are entitled to a creation review at any time. We normally
do them on during the TSC call on Thursdays. More information is here:
We currently have two other creation reviews scheduled for this week: 4/7 at 10a pacific time, but we've done three creation reviews in a day before, so if you can make that time, we can try our best.
On Fri, Apr 1, 2016 at 9:44 AM, Colin Dixon <colin@...> wrote:
Fair enough. As the TSC, we try to avoid forcing collaboration where the developers decide that it's not the right idea from a technical perspective.
On Fri, Apr 1, 2016 at 6:59 AM, 박세형 <labry@...> wrote:
Thank you for agreeing with me, Weiqiang Cheng.
I understand that MPLS-TP YANG models are in your scope.
But I am guessing our MPLS-TP model is fundamentally different from MPLS-TP Solution team’s YANG model because our YANG models are designed to incorporate multiple protocols (MPLS-TP, OTN, and ROADM).
For that reason, we have extracted some sets of common features among those protocols and created a parent YANG model called “transport YANG model.”
Then, our MPLS-TP YANG model and OTN YANG model extend the transport model and add more attributes as necessary.
As much as I want to collaborate with MPLS-TP Solution team (China Mobile), I think we don't have the common grounds to work on for now.
However, I think we can have a very positive influence on each other as we share several keywords and technologies.
From: Weiqiang Cheng [mailto:chengweiqiang@...]
I agree with Justin. It is better to have separate projects.
One point I want to clarify is that the MPLS-TP YANG models for NBI is also in our scope.
I’m cc’ing tsc mailing list to get a creation review.
We carefully searched for a common ground to collaborate with China Mobile.
But as far as I understand, it seems like our common ground is limited to the keyword "MPLS-TP" only.
Our goals and models are different from each other.
China Mobile focuses on applying the MPLS-TP (PTN) solution in their wireless backhaul network using OpenFlowTTP and Qx.
We are working on bringing Optical Transport Network (OTN) and MPLS-TP in core networks together by integrating legacy EMS/NMS platforms through common YANG models.
That means we are not currently working on OpenFlowTTP and Qx, nor have any concrete plans to work on them in the near future.
Originally, we intended to create a project called "Transport SDN" solution to incorporate OTN, MPLS-TP, and ROADM protocols.
To think big but start small, we ended up choosing the keyword MPLS-TP instead of T-SDN.
However, now that we have a keyword conflict with China Mobile, we are willing to change our keyword from MPLS-TP to Transport SDN solution.
In the future, I think we can benefit and collaborate with MPLS-TP Solution team on OpenFlowTTP, Qx, and Southbound drivers.
Also, we hope China Mobile could reference our project when they want to start working on OTN.
For now, we think it would be wiser to have separate projects.
We will look forward hearing your opinions on this.
From: Colin Dixon [mailto:colin@...]
I'm cc'ing project-proposals just so this gets logged somewhere.
It sounds like common areas here would be the MPLS-TP TTP and the MPLS-TP support for OF-CONFIG. Beyond that, it sounds like we have two different applications that would use those APIs. Is that right?
On Thu, Mar 31, 2016 at 5:33 AM, Weiqiang Cheng <chengweiqiang@China Mobile.com> wrote:
Thank you very much for your information about the MPLS-TP service project.
Base on your description, I think the requirements are different. You hope to base on the OTN baseline to support MPLS-TP.
China Mobile hope to use MPLS-TP as the basic solution for Packet transport network(PTN). We hope to use ODL to implement both super controller and domain controller. I also hope to details the overview of MPLS-TP solution.
The contribution will include:
- Yang Model with restconf solution for the interface between super controller and domain controller.
- Yang Mode and intent interface for the interface between Application and controller
- Openflow TTP with MPLS-TP extension
- OF-config with MPLS-TP extension
Currently, we have setup a test environments based on our prototype. More than 7 PTN equipment vendors including Huawei, Alcatel-Lucent, ZTE, Fiberhome, GWTT, Raisecom, Shanshui Optoelectronic… are involved in the test environments. And we also developed the MPLS-TP Openflow TTP which currently has been supported by several chip vendors such as Broadcom, PMC, Centec, and we are running the interoperation test in parallel.
The test result shows that the models and mechanism work well and China mobile planed to do field trial recently.
The willing committers are also increasing. The developers from Ericsson, GWTT, Raisecom, ZTE, Broadcom are planning to contribute to the project.
This is Justin from ETRI.
Thank you for giving us a chance to do a creation review as an email Q&A.
Most of the details of our project can be found at the following link.
However, let me briefly introduce you to the status of our solution.
MPLS-TP Service Team has put intensive efforts into this project and has almost finished the prototype controller and the plugins.
We received our requirements from local carriers (SKT and KT) and have successfully demonstrated the creation/deletion of multiple services over two different vendors (Woorinet and ETRI devices).
The Telefield (a local vendor) MPLS-TP devices are expected to be added to our compatible vendor's list after tiny adjustments.
We are willing to share our YANG models and controller source code, as well as one of Southbound plugins to ODL community.
<Figure 1: T-SDN Platform based on ODL>
Regarding collaboration, we want to know more about MPLS-TP Solution Team’s project. We want to know which controller uses ODL, super, domain, or both? We also want to know if your super controller is equivalent to our super controller in the figure 1. I've looked at the architecture of MPLS-TP managers from MPLS-TP Solution Team, but the architecture seems very different from ours.
MPLS-TP Solution Team (China Mobile) seems like their main focus in on southbound drivers including Qx and OpenFlowTTP, whereas we are focusing on the northbound interface and using YANG models as a communication mechanism between the managers and the plugins. Currently, we are working on brownfield networks and bringing legacy devices into SDN realm, but we are not considering Qx nor OpenFlowTTP.
<Figure 2: T-SDN Platform>
To keep you informed, we are also working on OTN (Optical Transport Networking) over ODL, which will eventually evolve into a POTN solution, refer to figure 2.
The prototype OTN controller is almost ready, but we are still working on the internal details of OTN Southbound plugins and its counterpart EMS.
We are confident in saying that our prototypes (MPLS-TP and OTN controllers and plugins) prove that our approach is very promising. ODL has saved us enormous time and effort in bringing all these together.
We would welcome anyone who is willing to make contributions to our project or learn from us.
If you have any questions related to the project, I'd be glad to answer them..
• Project Dependencies
• Deliverable (Boron offset 1)
– Yang Models (MPLS-TP)
– MPLS-TP Controller (Serivce, Inventory, and Topology Managers)
– Southbound Plugin(s)
• Willing Committers (10+)
– ETRI: Justin Park, Jisoo Shin, Jin Won Kang, Chang-Gyu Lim, Soomyung Park (5)
– SKT: Jongyoon Shin, Junhee Lee (2)
– Woorinet: Moonho Yoo (1)
– Mobigen: Moonkuk Park, Hyungcheol Park (2)
• Planning to migrate to Beryllium and beyond
• Project Lead – Justin Park
• Document Contact – Justin Park
• Test Contact – Justin Park