Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-01.txt

From: [email-masked]
Date: Mon, 24 Oct 2016 22:04:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling of the IETF.

        Title           : Framework for Abstraction and Control of Traffic Engineered Networks
        Authors         : Daniele Ceccarelli
                          Young Lee
	Filename        : draft-ietf-teas-actn-framework-01.txt
	Pages           : 28
	Date            : 2016-10-24

Abstract:
   Traffic Engineered networks have a variety of mechanisms to
   facilitate the
   separation of the data plane and control plane.  They also have a
   range of management and provisioning protocols to configure and
   activate network resources.  These mechanisms represent key
   technologies for enabling flexible and dynamic networking.

   Abstraction of network resources is a technique that can be applied
   to a single network domain or across multiple domains to create a
   single virtualized network that is under the control of a network
   operator or the customer of the operator that actually owns
   the network resources.

   This draft provides a framework for Abstraction and Control of
   Traffic Engineered Networks (ACTN).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Leeyoung <[email-masked]>
Date: Tue, 25 Oct 2016 05:13:52 +0000

Hi,

Per WG's request in the Berlin meeting, we worked on the terminology in this revision. Among the key terms used in ACTN drafts are listed as follows. We referenced RFC 7652 for some key terms. We clarified the definition of Virtual Network more clearly as well. Please see Section 1.1 for details. 

If there needs to be more clarify in those terms, please comment in this thread. 

Thanks.
Young and Daniele (on behalf of co-authors and contributors)

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

-	A Virtual Network is a client view (typically a network slice) of the transport network.  It is presented by the provider as a set of physical and/or abstracted resources. Depending on the agreement between client and provider various VN operations and VN views are possible.

		(1) VN Creation - VN could be pre-configured and created via static negotiation between customer and provider. In other cases, VN could also be created dynamically based on the request from the customer with given SLA attributes which satisfy the customer's objectives. 

		(2) Dynamic Operations - VN could be further modified and deleted based on customer request to request changes in the network resources reserved for the customer. The customer can further act upon the virtual network resources to perform E2E tunnel management (set-up/release/modify). These changes will incur subsequent LSP management on the operator's level. 

		(3) VN View - (a) VN can be seen as an (or set of) e2e tunnel(s) from a customer point of view where an e2e tunnel is referred as a VN member. Each VN member (i.e., e2e tunnel) can then be formed by recursive aggregation of lower level paths at a provider level. Such end to end tunnels may comprise of customer end points, access links, intra domain paths and inter-domain link. In this view VN is thus a list of VN members. (b) VN can also be seen as a terms of topology comprising of physical and abstracted nodes and links. The nodes in this case include physical customer end points, border nodes, and internal nodes as well as abstracted nodes. Similarly the links includes physical access, inter-domain and intra-domain links as well as abstracted links. The abstracted nodes and links in this view can be pre-negotiated or created dynamically. 

-	Abstraction is the process of applying policy to the available TE information within a domain, to produce selective information that represents the potential ability to connect across the domain.  Thus, abstraction does not necessarily offer all possible connectivity options, but it presents a general view of potential connectivity according to the policies that determine how the domain's administrator wants to allow the domain resources to be used. [RFC7926]

-	Abstract Link: An abstract link is the representation of the characteristics of a path between two nodes in a domain produced by abstraction.  The abstract link is advertised outside that domain as a TE link for use in signaling in other domains.  Thus, an abstract link represents the potential to connect between a pair of nodes. [RFC7926]

-	Abstract Topology: Every lower controller in the provider network, when is representing its network topology to an higher layer, it may want to hide details of the actual network topology. In such case, an abstract topology may be used for this purpose. Abstract topology enhances scalability for the MDSC to operate multi-domain networks

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 25, 2016 12:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-01.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas