Subject: [Actn] comments on Charter

From: "WRIGHT, STEVEN A" <[email-masked]>
Date: Fri, 7 Mar 2014 11:07:51 +0000

A couple of comments to try to improve clarity

1)     The charter talks about abstraction e.g.

  *   Abstraction of the underlying network resources to higher-layer applications and users (customers);

Abstraction implies hiding data from the higher layers . Can  we be more specific about the types of information we want to hide from the higher layers ?  Is the objective here to survey and compare existing abstractions? Or to define a new one?  What exactly are we proposing to do about abstraction?

2)      The charter talks about transport networks. This needs to be more specific.

The discussion seemed to center on connection oriented networks, but it was not clear that the abstraction of connectionless network transport was excluded. Clarify whatever is expected, but CO is probably simpler to start with.

3)      The payload of the transport should be identified, or at least constrained. Transport networks could include wavelength services, for example, but I don't think that is within the scope of what you intend.  Is payload layer 2 frames? Layer 3 packets ? if you are connecting different subnets the interconnection format is important.

4)      I'm confused by the requirements document. Which actor is generating these requirements?, of whom? And what happens if they are not met? A requirements document also seems to assume that there would be follow on work in a later group ?

Best regards

Steven Wright, MBA, PhD, JD.
NFV & SDN Industry Engagement
Standards & Industry Alliances
AT&T Services Inc.
1057 Lenox Park Blvd NE, STE 4D28
Atlanta, GA 30319
P: 404.499.7030

[email-masked]<mailto:[email-masked]>

---

From: Leeyoung <[email-masked]>
Date: Mon, 10 Mar 2014 20:33:47 +0000

Hi Steven,

Please see inline for my comment.

Thanks,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of WRIGHT, STEVEN A
Sent: Friday, March 07, 2014 5:08 AM
To: [email-masked]
Subject: [Actn] comments on Charter

YOUNG>> There are varying degree of hiding in terms of granularity. The objective here is to explore what abstraction is required and its method. For instance, the abstraction can have different forms. We are not talking about the entire network abstraction. This abstraction is driven by the customers; Given the end points of their interest, the network can provide (i) potential resources they can grab --- how to represent this is subject to the work in the ACTN once it is chartered. Some sophisticated customer may want some graph form of abstraction that shows some network link bottleneck. This map would be useful for multi-commodity flows (concurrent traffic demand). Some other application may require abstracted LSPs (Label Switched Path) that showed the network paths reserved for the customers. In all cases, hiding is essential and the naming/addressing schemes have to be mapped as part of VNE (virtual network embedding problem).

To answer your question, we are not proposing any abstraction method. That is a part of solutions for this work and there needs to be survey of available techniques and possibly new ways of abstraction to meet the requirement.

YOUNG>> Our starting point is CO-based TE networks. We can be clearer on this in the problem statement. We have the following paragraph in the framework, maybe it is worth to import it to the problem statement:

  Transport networks in this draft refer to a set of different type of
   connection-oriented networks, primarily Connection-Oriented Circuit
   Switched (CO-CS) networks and Connection-Oriented Packet Switched
   (CO-PS) networks. This implies that at least the following transport
   networks are in scope of the discussion of this draft: L1 optical
   networks (e.g., OTN and WDM), MPLS-TP, MPLS-TE, as well as other
   emerging connection-oriented networks such as Segment Routing (SR).
   One of the characteristics of these network types is the ability of
   dynamic provisioning and traffic engineering such that resource
   guarantee can be provided to their clients.

YOUNG>> I think the above text from the framework clarifies the type of data planes we are considering. Wavelength services are included in the scope. Payload types and encoding/switching capability are important in the control of physical network. Some constraints need to be abstracted to the clients expressed generically in terms of the language the customer understands. We don't necessarily present data plane types to the customer, but express in terms of latency, b/w, etc. When you connect different subnets with different type of transport, then each subnet can be presented (if customer wants to know such details) in terms of generic QoS/service parameters. Is this agreeable?

YOUNG>> Not sure this question. Can you be more specific? Perhaps, Dhruv or Xian, Oscar can answer this question.
Best regards