[Teas] comments related draft-ceccarelli-teas-actn-framework-01

[Gert Grammel <[e-mail]>]

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.

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.

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.

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?

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.

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.

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.

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’?

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.

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.

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).

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).

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.

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

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

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?

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?

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.

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.

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.

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?