[Teas] New Version Notification for draft-ceccarelli-teas-actn-framework-02.txt

[Daniele Ceccarelli <[e-mail]>]

Working group,



A new version of the ACTN framework draft has just been uploaded. It implements the changes discussed in the email below.



> Name:                               draft-ceccarelli-teas-actn-framework

> Revision:          02

> Title:                  Framework for Abstraction and Control of Traffic Engineered

> Networks

> Document date:           2016-04-14

> Group:                              Individual Submission

> Pages:                               28

> URL:            https://www.ietf.org/internet-drafts/draft-ceccarelli-teas-actn-framework-02.txt

> Status:         https://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework/

> Htmlized:       https://tools.ietf.org/html/draft-ceccarelli-teas-actn-framework-02

> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ceccarelli-teas-actn-framework-02

Thanks!
Daniele for the authors

From: Teas [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: giovedì 7 aprile 2016 01:54
To: Gert Grammel; TEAS WG
Subject: Re: [Teas] comments related draft-ceccarelli-teas-actn-framework-01

Hi Gert,

Thanks a lot for finding the time to discuss the comments face to face.
Working group, please find inline some notes of the changes.
Version -02 will be uploaded ASAP.

Thanks
Daniele & co-authors

From: Teas [mailto:[e-mail]] On Behalf Of Gert Grammel
Sent: martedì 5 aprile 2016 16:32
To: TEAS WG
Subject: [Teas] comments related draft-ceccarelli-teas-actn-framework-01

Daniele,

below a few more detailed comments in line to what I mentioned on the mic, hope they help to progress the draft.
https://datatracker.ietf.org/doc/draft-ceccarelli-teas-actn-framework/?include_text=1


To sum up:

There is quite some vague language in the current draft that would deserve definition. A good source to start with, would be to use references found in https://tools.ietf.org/html/rfc4397

It would help to separate the service aspect from the network aspect. The amount of data exposed to a customer is a policy decision controlled by the provider. Considerations about what to expose is based on business considerations across an externally visible interface that need security hardening etc. That isn't sufficiently covered in the current framework.

Totally agree with your analysis. Isn't the description of the Negotiation phase in section 4 enough? If you have in mind some improvements to the text they are more than welcome.



Another aspect is related to exposing network date inside a provider network, namely between regions (aka switching layers) in order to enable traffic engineering on the client region. In particular, layer transitions are always made in nodes, not links. In other words, every node in a network is basically a multi-layer capable node. (think about a router with Ethernet interfaces). So Layering is orthogonal to service separation and mixing both concepts is a safe source of confusion.

I would propose to clarify that the service aspect is essentially building a service chain (customer - provider1 - provider2 - customer) and is therefore a 'horizontal' flow. Pointing out which kind of information would be required of the various use cases would be great. E.g. For a dual homing case the client would need to understand that both access points to the provider are disjoint, ...). This part should not be guided by abstraction considerations but rather by identifying the provider information required for a customer to perform a sort of Traffic engineering on his part. Note also that there is no layering aspect here as client and provider may use the same layer as it is today the case in IP routing.

On the other hand, Traffic engineering in Multi-region networks (aka. Multiple switching layers) is about vertical network abstraction that allows a higher (aka client) region to provide TE capabilities based on a limited knowledge of lower (aka server) region TE information. https://datatracker.ietf.org/doc/draft-ietf-ccamp-interconnected-te-info-exchange/ provides a great source of which abstractions are conceivable and mapping them with requirements identified before could provide valuable guidance.



More details:

p.3: "Particular attention needs to be paid to the multi-domain case" -> there is no definition of 'domain' here. There is a lot of confusion about "vendor-domains", "routing-domains", "protocol-domains", "provider-domains", "geographical-area domains". Note that theme repeatedly come up throughout the document.

In this context a domain is whatever is controlled by a PNC and that requires the intervention of a MDSC to get to another domain. This is something that does not match with any of the existing domains definition. The term PNC domain will be added to the terminology section with a picture and covering both border nodes and border links.



P.3: "Abstraction of the underlying network resources" -> the term 'abstraction' is borrowed from ONF. However we are operating with https://tools.ietf.org/html/draft-ietf-ccamp-interconnected-te-info-exchange-01<https://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-00> here where the term 'abstract' link is defined. Make sure that the vocabulary is used consistently.

The term abstraction is used in a number of different contexts and both the interconnected-TE draft and the ONF architecture use it in exactly the same way. No problem in referencing the interconnected-TE wrt abstraction. The draft references to the ONF architecture for the virtualization, not for the abstraction.



P.4: "  - Creation of a virtualized environment allowing operators to view and control multi-subnet multi-technology networks into a single virtualized network;" -> Multi-control multi-subnet in a single virtualized network? Note that when you slice a physical node into different virtual nodes, it is still controlled by the same controller. If in the end everything ends up in the same virtualized network, why splitting it in the first place?

The term multi-subnet is an inheritance of a copy-paste, will be substituted with multi-domain.



P.4: "A node, in a VN network, can be represented by single physical entity or by a group of nodes" -> that suggests that a node is always a physical entity, later the term 'node' seems to mean a single layer switching entity or something similar.

Right, the text here is misleading, the meaning is that a physical node can be: i) represented as it is in the topology exposed to the customer, ii) split into a number of virtual nodes or iii) grouped with other physical nodes to build a single virtual node. The choice between i), ii) or iii) depends on the abstraction policies agreed between customer and provider.

How about changing the text into:

"A node, in a VN, could represent a physical node (no abstraction), a group of nodes or a portion of a physical node"



P.4: "Network virtualization refers to allowing the customers of network operators (see Section 2.1) to utilize a certain amount of network resources as if they own them and thus control their allocated resources with higher layer or application processes that enables the resources to be used in the most optimal way." -> since the term 'customer' is related to a business relationship, the case where controllers in a provider network exchange TE-Topology in an automated way would be excluded. I would argue that this is the primary use case and providing visibility to customers is something that needs to be handled by a Service Management entity which is not defined here.

This piece of text is not adding much value. We can drop it.



P.5: "not tied to any particular physical characteristics like timeslots, wavelength, packet." -> difficult to parse. It is also hard to consider timeslots, wavelength and packets as 'physical' characteristics.

Changed from physical characteristics to technology specific characteristics



P.5: "Depending on the agreement between client and Provider" -> the term "client" is usually assumed to represent a a logical entity talking to a server. Does client here means 'customer'?

Yep, Changed to customer



P.5: "In the first case can be seen as an (or set of) e2e connection(s) that can be formed by recursive aggregation of lower level connections at provider level.  Such end to end connections include: customer end points, access links (physical or virtual), intra domain tunnels and inter-domain link (physical or virtual). -> if the term customer means a commercial customer, then recursiveness is difficult to think of. If it means client, then an access link needs to be hooked at a node, but it doesn't show up here.

Changed to: In the first case the VN can be seen at customer level as an e2e connectivity that can be formed by recursive aggregation of lower layers tunnels within the provider domain.



P.6: 2.1 spells out that it talks about "customers", not "clients". While I think this is a correct statement here, the other part of the draft mixes customers and clients.

Fixed



P.10: "The network provider space is the one where recursiveness occurs." -> see above. It is strange that the use case is focussed on advanced customer cases, but the recursiveness is "only" applied to the network provider case which doesn't even interact with the customer (as a service provider (see fig 3) provides that).

Section dropped



P.10: "With the definition of domain being "everything that is under the control of the same controller" -> might be advantageous to utilize the terminology already set up in RFC5212: "In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN).  When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN).

The term PNC domain is now used and defined in the terminology section...and has nothing to do with layering.



P.11: "Network Function Virtualization Services: These kinds of services are usually setup between customers' premises an service provider premises and are provided mostly by cloud providers or content delivery providers." -> so which entity is considered customer  and which one is server? Is the DC provider a service provider that is different from the service provider mentioned above? Is it a client of a topology provider? It's challenging to map this case into figure 3.

Text re-edited.



P.13: "application stratum" -> what do you mean? Is that meant to be a bucket of controllers of all kinds?

Substituted application stratum with applications.



P.13: Fig 4 doesn't show different providers. Isn't that where particular attention was placed?

Figure fixed.



P.14: 3.2 talks about multiple domains. Those seem to mean "everything under the same controller". Later it is said: "In order to allow for a hierarchy of MDSC, the interface between the parent MDSC and a child MDSC must be the same as the interface between the MDSC and the PNC." While a PNC deals with abstracting a set of network resources MDSC deals with services. Is the assumption here that a Service-Domain is different from technology domains and the service-domain boundary may not match the PNC boundaries?

The intention is to say that the two interfaces are based on similar information, but there is no assumption that the interfaces are the same. Text fixed.



P.16: "a multi service domain controller needs to be built on top of physical network controller to support network virtualization." Why a MDSC is *required* for a virtualization? Perhaps it is required to provide virtualized services, but not virtualization as such (we have VRFs implemented on routers, do we still need a MDSC now?

Correct



P.17: Fig 6: why are the individual physical networks not connected? Which controller is in charge of such an interconnection between physical networks? Note that there is no customer-provider interfae here and no AP needs to be defined. Keep also in mind that in cases where e.g. Isis and OSPF domains are separated, they overlap on nodes, not links.

Figure fixed, only logical interfaces left, IF E removed (physical IF)



P.19: fig. 7: what is the link in between those domains? As the customer (in a service model) is not aware of domains, why are they depicted? Note that the AP seems only being required if the network is hidden from a customer. However that is not required in a network model.

Correct. The figure was a mix of customer view and provider view. Fixed as customer view only.



P.20: fig 8: why is this a provider view? The provider has a full view of ist network why is it limited like this? The figure looks a bit like an abstract client topology. However not the view of a network provider.

The focus of fig 8 is to show what the provider sees about the AP, not the rest of the network (abstraction and so on).



P.21: "In this case the customer will request for a VN between AP1, AP2 and AP3 specifying a dual homing relationship between AP1 and AP2. As a consequence no traffic will be flowing between AP1 and AP2." First of all the customer in this model can't figure out if it is physically connected to a single provider node or not. If so, how can it request a diverse path? Things like this need to be negotiated in advance. If you would imagine 3 interfaces here, how would a client figure out which pair of interfaces can be used of a diverse routed connection and which other combination does not - other than bugging the opaque server. Note that here you describe a customer-provider relationship. The link between customer and provider is a single layer link.

P.21 6.1: what is the role of the data centre here: Customer or provider?

The text has been updated to state that the customer of the ACTN network is the VNF provider.