Subject: [Actn] related standards work

From: "Shew, Stephen" <[email-masked]>
Date: Thu, 31 Jul 2014 12:00:29 -0400

As discussed in the actn bof last week, I list some related standards that I think should be considered by actn so that things don't get re-invented.

1.      Virtual Network.  There are various semantics to the word "virtual" so adopting or stating a definition is important. RFC4847 describes virtual networks in terms of ITU-T Y.1312 and Y.1313.  Those Recommendations address both the data plane aspect of VPNs as well as the control plane aspect.  Concepts of private and shared VPNs are described.  I find them quite useful and suggest that uses cases adopt these terms so that the commonality of the use cases can more readily be determined.

2.      Abstraction and arrangement of control.  The recently published ONF SDN Architecture (https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf) describes various arrangements of SDN controllers which I think should be adopted by actn.  They define "abstraction" in way that makes "virtual" a subset of abstraction.  Having a clear definition of the 2 terms is important.  The Multiple Vendor Domain Transport Networks use case could be covered by a limited hierarchy of SDN controllers.  One of the suggestions in the SDN Architecture document is that there may be a need for inter-domain control and this may be a gap that actn addresses.

3.      Interfaces.  Implementations of interfaces imply some design, and it is helpful to expose that design upfront so that limitations, extensibility, and commonality are understood.  To that end, use of a common information model has been beneficial.  I point in particular to TM Forum's TR215 and is draft successor TR225.  From an information model, a more specific information model can be derived (like an instantiation of an aspect of the general one).  Then, data models can be developed from that specific information model.  If a common information model is used, then the particular encoding of the data model is less critical.  I don't suggest that actn start with just a data model because the architecture behind it is not exposed.

Stephen Shew | Director, Standards
[email-masked]<mailto:[email-masked]> | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
Direct +1.613.670.3211

---

From: Leeyoung <[email-masked]>
Date: Thu, 31 Jul 2014 16:43:42 +0000

Hi Stephen,

Thanks for posting this list of reference.

My overall comment is: in light of many works in the past and even presently in other SDOs, it is ironic that operators came to IETF to address their problems and see IETF as viable and practical place for their problem to be solved.

>From a transport network perspective, there have been many tools IETF championed in regard to GMPLS control plane, PCE and other configuration/management tools. Some of your pointer for ONF seems irrelevant to many operators as OF is a green-field for them.  As you were in the BoF, the operators brought their current problems on their brown field. Are you aware of any real deployment of ONF-based transport networks? ACTN can certainly treat OF-based transport as a domain among others once it is deployed.

Your Virtual network reference from ITU-T is quite theoretical and VPNs have been implemented in L2VPN/L3VPN WGs focusing on practical issues. I also see some gap of many ITU-T references and the reality.

Your pointer for TMF is all appreciated. We will look at if data model is necessary to enable abstraction. For TE model of IETF, we did not have either IM or DM in GMPLS/PCE implementation. At this point, I am not sure if we need IM or DM. One of the homeworks from the BoF is to investigate if we need IM/DM. If we do need IM/DM, there have been some efforts in IETF around Yang and JSON. I have proposed JSON based abstraction models in the past in IETF (In a BoF called I2AEX under ALTO) , which seems working very well for transport network resource abstraction.  There are also BGP-LS based models that have progressed in IETF quite a bit. I tend to think these lists are a starting point. TMF is a bit foreign to IETF and to me.

Thanks,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: [email-masked]
Subject: [Actn] related standards work

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 31 Jul 2014 17:05:47 +0000

Hi Young,

Please see below for my two cents ;-)

With best regards,
Eve

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; [email-masked]
Subject: Re: [Actn] related standards work

Hi Stephen,

<ELV> I am not surprised that operators are seeking to find solutions across a range of standards and industry forums.  This is not exclusive to IETF - e.g.,  consider related ETSI NVF work items.

>From a transport network perspective, there have been many tools IETF championed in regard to GMPLS control plane, PCE and other configuration/management tools. Some of your pointer for ONF seems ir…

<ELV> The reference was to a protocol-neutral SDN Architecture document (i.e., independent of the protocol used over interfaces), which has some very useful material that has also been shared with other SDOs, and IMHO is quite relevant to the ACTN problem domain.  I would certainly understand your comment if the document were focused/optimized for the OF protocol.  However, it is not.  It is my view that protocol-independent architectural work should be examined regardless of what group produces it, as we have so many colleagues contributing across multiple standards and industry forums, which allows for leverage of applicable work.

<ELV> Perhaps the language used in the ITU-T Rec. could be a barrier for some, but there is useful information.  You'll find some good material, leveraging this, in the SDN Architecture document discussion of this area.

<ELV>  If one is looking from a broader transport networking perspective, an underlying information model from which various data models/interfaces can be derived enables interoperability (not to mention leverage of significant industry experience in networking & forwarding domain).  However, this is a much larger discussion topic area (beyond ACTN).

Thanks,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Shew, Stephen
Sent: Thursday, July 31, 2014 11:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Actn] related standards work

---

From: Leeyoung <[email-masked]>
Date: Thu, 31 Jul 2014 17:34:01 +0000

Hi Eve,

Good to hear from you in ACTN list. Thanks for your comment. I think you clarified some misunderstanding and confusion. Here's my comment for you in-line.

Regards,
Young

From: Varma, Eve L (Eve) [mailto:[email-masked]]
Sent: Thursday, July 31, 2014 12:06 PM
To: Leeyoung; Shew, Stephen; [email-masked]
Subject: RE: related standards work

Hi Young,

With best regards,
Eve

From: ACTN [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, July 31, 2014 12:44 PM
To: Shew, Stephen; [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] related standards work

Hi Stephen,

YOUNG>> Yes, that is a reality.

YOUNG>> The assumption for SDN arch. Document (as far as I understand from the initial version) is, however, tied with OF based philosophy, meaning that the SDN controller is a "God"-box as to what to control as to how much it wants to know. The ACTN is on a different assumption. ACTN control hierarchy would not touch existing domain control of many kinds (e.g., GMPLS/ASON, PCE-based, NMS/EMS-based, etc.) and let them continue control/operate their networks (which is one of the requirements from many operators). What they need is a overarching "overseer" that allows quick service provisioning based on an end-to-end global abstraction view of all encompassing domains. For instance, cross-connect and other low level control of NE will need not be abstracted in ACTN scope as these controls will continue to be done at existing domain level control. I think this assumption makes a huge difference. I believe what ACTN is trying to do based on operators' use-cases has a different starting point from what you are referring to, namely, the ONF SDN Control architecture models has been trying to do. ACTN does not replace any existing network control and operation. It builds on top of that.

YOUNG>> language is always a tremendous stumbling block. :) I will try to update myself with the mentioned references.

YOUNG>> Agree. My point is that models are only tools that should help the functions. As pointed previously, for simple functions to fulfill, the validity of models needs to be carefully evaluated.

Thanks,
Young