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

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 3 Jan 2017 00:09:59 +0000

Hi all,

I have read the latest version of the document and I run into quite some questions (inline below, flagged by [MS]). Sorry if they have already been discussed.

Thanks

Michael

**********************************************************************

Page 5:

   Network abstraction refers to presenting a customer with a view of
   the operator's network in such a way that the links and nodes in
   that view constitute an aggregation or abstraction of the real
   resources in the operator's network in a way that is independent of
   the underlying network technologies, capabilities, and topology.
   The customer operates an abstract network as if it was their own
   network, but the operational commands are mapped onto the underlying
   network through orchestration.

[MS] I think there is a lot of confusion regarding the term "orchestration". Would it be possible to add a reference to back this specific meaning? If not, I would suggest to remove the term here. BTW, any EMS maps service requests to operational commands on NEs and I am not sure if the term "orchestration" is typically used for the EMS function.

Page 5/6:

     . A virtualization/mapping network function that adapts the
        customer's requests for control of the virtual resources that
        have been allocated to the customer to control commands applied
        to the underlying network resources. Such a function performs
        the necessary mapping, translation, isolation and
        security/policy enforcement, etc. This function is often
        referred to as orchestration.

[MS] Same again: Is there a reference for this use of "orchestration"? IMHO the term is also used in other context and I don't fully understand why it has to be introduced in the ACTN framework.

Page 7:	

     . PNC: A Physical Network Controller is a domain controller that
        is responsible for controlling devices or NEs under its direct
        control.

[MS] Wouldn't it be reasonable to add a comment that the PNC may not control any "physical" links or "physical" network elements? MPLS-TE routers can run entirely virtualized as VNFs, right? Would a "PNC" not be able to manage VNFs running a PE router for MPLS-TE services? Without further explanation, I think the term "physical" is confusing at least for MPLS-TE. For what it is worth, I believe the term "domain controller" would better capture what this functional component is actually about.

Page 11:
		
   There are multiple types of service providers:

     . Data Center providers can be viewed as a service provider type
        as they own and operate data center resources for various WAN
        customers, and they can lease physical network resources from
        network providers.
     . Internet Service Providers (ISP) are service providers of
        internet services to their customers while leasing physical
        network resources from network providers.
     . Mobile Virtual Network Operators (MVNO) provide mobile services
        to their end-users without owning the physical network
        infrastructure.

[MS] I find this paragraph confusing. First, what is the difference between Data Center providers, ISPs, and MVNOs regarding the ACTN framework? Do they have different needs regarding optical, MPLS-TP, or MPLS-TE connectivity? Second, is this list comprehensive? For instance, what is different between a data center provider or ISP and, say, a corporate enterprise IT department that orders VPNs from a service provider, and offers this inside the company as a service to internal customers? The latter is classified as "advanced customer". I fail to see the difference "advanced customers" as defined in Section 2.1 and this list of "service providers". What do I miss?

Page 12:

   The ACTN architecture is aligned with the ONF SDN architecture [ONF-
   ARCH] and presents a 3-tiers reference model. It allows for
   hierarchy and recursiveness not only of SDN controllers but also of
   traditionally controlled domains that use a control plane.

[MS] Why does [ONF-ARCH] point to "Open Networking Foundation, "OpenFlow Switch Specification Version 1.4.0 (Wire Protocol 0x05)", October 2013"? Is the OpenFlow spec 1.4.0 indeed the best reference for the ONF SDN architectures? What about ONF TR-502, ONF TR-521, or ONF TR-522? (Note that I am not sure if these exactly define a three-tier architecture.)

Page 12:

     . Customer mapping/translation function: This function is to map
        customer requests/commands into network provisioning requests
        that can be sent to the Physical Network Controller (PNC)
        according to business policies provisioned statically or
        dynamically at the OSS/NMS. Specifically, it provides mapping and
        translation of a customer's service request into a set of
        parameters that are specific to a network type and technology
        such that network configuration process is made possible.

[MS] It is somehow surprising that OSS/NMS is only mentioned in this paragraph. If the role of NMS and OSS in ACTN is not discussed more comprehensively, wouldn't it be better remove the reference to OSS/NMS?  
		
Page 13:

   The virtual services that are coordinated under ACTN can be split
   into two categories:

     . Service-aware Connectivity Services: This category includes all
        the network service operations used to provide connectivity
        between customer end-points while meeting policies and service
        related constraints. The data model for this category would
        include topology entities such as virtual nodes, virtual links,
        adaptation and termination points and service-related entities
        such as policies and service related constraints. (See Section
        4.2.2)

     . Network Function Virtualization (NFV) Services: These kinds of
        service are usually set up in NFV (e.g. cloud) providers and
        require connectivity between a customer site and the NFV
        provider site (e.g., a data center). These NFV services may
        include a security function like a firewall, a traffic
        optimizer, and the provisioning of storage or computation
        capacity. In these cases the customer does not care whether the
        service is implemented in one data center or another. This
        allows the network provider divert customer requests to the
        most suitable data center. This is also known as the "end
        points mobility" case (see Section 4.2.3).

[MS] Here I am really lost. Why does this document even start talking about NFV services? Why does it matter for the transport service offered by an optical, MPLS-TP, or MPLS TE network whether the connectivity is used *specifically* by a NFV provider? I.e., is the assumption here that the "endpoint mobility use case" is only applicable to VNF but not to other general-purpose distribute datacenters, or other endpoint selection use cases? I don't believe this is true (see later). So, this reference to NFV is very confusing. And using the term "service" recursively in "Service-aware Connectivity Services" is also strange to me. If this section cannot be made more clear, I think the best solution would be to entirely remove it.

Page 14:

   Figure 3 also shows the following interfaces:

[MS] I am confused by the separation of PCE and PNC in Figure 3. From the functional description in Section 3 it seems that path computation is part of the "Virtualization/Abstraction" function realized by a PNC, i.e., part of the PNC, right? Section 3.3 explicitly states that the internal architecture of the PNC is out of scope and this figure contradicts this. The figure also seems to indicate that the only link between the "physical network" and a PNC is through a PCE. This would only be true of the PNC would not use e.g. NETCONF/YANG to manage NEs. I think the function split between PNC and PCE does not belong into this document and the Figure must be updated accordingly. 

Page 14:
  
   A Virtual Network Service is instantiated by the Customer Network
   Controller via the CNC-MDSC Interface (CMI). As the Customer Network
   Controller directly interfaces to the applications
   
[MS] What is "applications" in this context? "application" is a very widely used term in the IETF and the assumption that an "application" *directly* talks to a functional component realizing the functions of the CNC is certainly not true on all potential use cases of ACTN. Maybe Figure 5 should be introduces earlier in the document to introduce what ACTN assumes on "applications". But see also my questions on that Figure below - I think the use of "application" has to be re-considered entirely.

Page 16:

   In order to allow for multi-domain coordination a 1:N relationship
   must be allowed between MDSCs and between MDSCs and PNCs (i.e. 1
   parent MDSC and N child MDSC or 1 MDSC and N PNCs). In the case
   where there is a hierarchy of MDSCs, the interface above the top
   MDSC (i.e., CMI) and the interface below the bottom MDSCs (i.e.,
   SBI) remain the same. The recursion of MDSCs in the middle layers
   within this hierarchy of MDSCs may take place.

[MS] I don't understand how this recursion would work in the multi-layer case. Say, assume I have an "MDSC 1" controlling PNCs of an optical network, and "MDSC 2" controlling PNCs managing an MPLS-TE network. Do these two MDSCs indeed have exactly the same interface? That interface would have to be entirely technology agnostic, right? If the ACTN framework will only define entirely technology agnostic interfaces, this would IMHO have to made more explicit. Alternatively, if technology specifics are possible, I really don't understand how the recursion will work. Do I miss something?

Page 16:
   
   In addition to that, it could also be possible to have an M:1
   relationship between MDSCs and PNC to allow for network resource
   partitioning/sharing among different customers not necessarily
   connected to the same MDSC (e.g., different service providers).

[MS] Isn't another relevant case that a single "domain controller" controls/manages multiple layers/technologies, i.e., one software acts as PNC for different layers, while there are multiple different MDSCs and each MDSC only handles one layer/technology? In that case, one PNC has to talk to multiple MDSCs, right? The document earlier explicitly notes that a PNC may handle multiple layers. Also, isn't it possible that the same customer uses more than one MDSC (e.g., one to request optical services, and one to request MPLS-TE services)?

Page 16:

   The Physical Network Controller (PNC) is in charge of configuring
   the network elements, monitoring the physical topology of the

[MS] Why "physical topology"? Wouldn't it be the IGP-TE topology e.g. in case of PNC that controls an MPLS-TE or GMPLS network?

Page 17:

   A hierarchy of PNCs can be foreseen for scalability and
   administrative choices.

[MS] What is the difference between a "parent PNC" and a MDSC if there is this sort of hierarchy of "parent PNC" and "child PNC"? As this case is also shown in Figure 3, it seems a valid question. Isn't this an internal aspect of how the PNC is realized that doesn't matter to the ACTN framework? 

Page 18:

   Figure 5 depicts a high-level control and interface architecture for
   ACTN. A number of key ACTN interfaces exist for deployment and
   operation of ACTN-based networks. These are highlighted in Figure 5
   (ACTN Interfaces).

[MS] I don't understand why this figure introduces Interface A and "application". If only interfaces B and C are in scope, why does it matter how the CNC receives a service request, and the use of the term "application" here is questionable at best. For instance, the I-D mentions earlier that a CNC could itself offer connectivity services to customers of the CNC. In that case, the "application" would be a system of another customer/tenant. Alternatively, the "application" could be an orchestrator (e.g., ETSI MANO orchestrator) or an OSS/BSS system but I have some doubts whether the term "application" is really the best choice in any of these cases. Instead of introducing hypothetical interfaces that are then flagged as out-of-scope, why not only clearly introduce the interfaces that are in scope *only*?

Page 19:

     . Interface D: The provisioning interface for creating forwarding
        state in the physical network, requested via the Physical
        Network Controller.

[MS] Wouldn't it make sense to use replace the term "forwarding state" by something that is applicable to all potential realizations of a PNC (e.g., "resource provisioning" or "resource allication")? But, again, why to actually bother about defining an interface that is not in scope of ACTN?

Page 23:

6. End Point Selection and Mobility

   Virtual networks could be used as the infrastructure to connect a
   number of sites belonging to a customer or to provide connectivity
   between customer sites and Virtualized Network Functions (VNF) such
   as virtualized firewalls, virtual Broadband Network Gateway (vBNG),
   storage, or computational functions.

[MS] I really don't understand why this document discusses VNFs. I think this whole section has to be rephrased not to use the terms NFV and VNF. To me, the use cases are not specific to VNFs, but they refer to specific service requests that can also occur on non-NFV environments.

[MS] Also, if virtual network functions are to be discussed in this I-D, it may make sense to first analyze the implications of how the ACTN framework can handle a PNF that manages VNFs (e.g., virtual PE routers running as VNF). But even this topic seems a slippery slope and it may be easier to entirely remove NFV implications. More below.

Page 23:
   
6.1. End Point Selection

   A VNF could be deployed in different places (e.g., data centers A,
   B, or C in Figure 9), but the VNF provider (that is, the ACTN
   customer) doesn't know which is the best site in which to install
   the VNF from a network point of view (e.g., to optimize for low
   latency). For example, it is possible to compute a path minimizing
   the delay between AP1 and AP2, but the customer doesn't know if the
   path with minimum delay is towards DC-A, DC-B, or DC-C.

[MS] This problem can be solved without the ACTN framework. Why does this document not reference RFC 7971, in particular Section 6.1?

[MS] Note that in the way the problem is stated here, the "VNF provider" (the term should be replaced by ACTN terminology) only has to know the properties between the endpoints (e.g., delay) but not the path or a virtual TE topology. The IETF has defined the ALTO protocol for exactly that case.

[MS] And, the fact that the problem can be solved by ALTO actually shows that this "endpoint selection" is not specific to VNFs at all. The same problem applies to all endpoint selection problems, e.g., in peer-to-peer systems, content delivery cache selection, replica placement in distributed databases, etc. There is no need to only discuss this use case for VNFs.
   
   In this case the VNF provider (that is, the ACTN customer) should be
   allowed to ask for a VN between AP1 and a set of end points. The
   list of end points is supplied by the VNF provider. When the end
   point is identified the connectivity can be instantiated and a
   notification can be sent to the VNF provider for the instantiation
   of the VNF.

[MS] Does this description imply a workflow that an ACTN component decides on behalf of the VNF provider which endpoint to use? Now, what happens if there is not enough compute or storage resources at that endpoint? I am not sure if that workflow is what actual NFV systems would do. Is there running code for what is described here, or is this just speculation? The more straightforward workflow is that the VNF provider queries the network properties, picks the best endpoint that also fulfills the non-networking constraints (compute, storage, etc.), and then asks ACTN to provide the connectivity. That seems doable with the vanilla ACTN functionality. For that workflow, Section 6.1 is not needed at all. 

Page 24:
   
6.2. Pre-Planned End Point Migration

   A premium SLA for VNF service provisioning consists of offering of a
   protected VNF instantiated on two or more sites and with a hot
   stand-by protection mechanism. In this case the VN should be
   provided so as to switch from one end point to another upon a
   trigger from the VNF provider or from an automatic failure detection
   mechanism.  An example is provided in Figure 10 where the request
   from the VNF provider is for connectivity with resiliency between
   CE1 and a VNF with primary instantiation in DC-A and a protection
   instance in DC-C.

[MS] I don't understand why the document mentions this use case. First, hot standby is not a functionality specific to VNFs. Hot standby can also be used between two database instances running bar metal. So, talking only about VNFs is by far too limiting. But, more importantly, I don't understand how the use case is meant to work. If the connectivity is "switched" (e.g., reconfiguration of an optical service), it means that it will be difficult for the network to detect the failure, right? How would that work? IMHO only the "VNF provider" can know whether a hot standby is triggered and if the network connectivity has to be reconfigured. To me, from a TE perspective, this use case is not different to a re-configuration of an existing service to another access point, or is it? To the best of my knowledge, hot standby can also have many non-TE implications in reality but I don't believe this document wants to start discussing implications of dynamically reconfiguring load balancers, service function chaining, etc. that can came along with failover, too.

[MS] BTW, I wonder why the document discusses resiliency first for this very complex use case. It is not obvious to me how the ACTN interfaces would deal with basic resiliency mechanisms in the virtual networks (e.g., 1:1 protection). Any thoughts?

Page 25:
 
6.3. On the Fly End Point Migration

   On the fly end point migration concept is similar to the end point
   selection one. The idea is to give the provider not only the list of
   sites where the VNF can be installed, but also a mechanism to notify
   changes in the network that have impacts on the SLA. After an
   handshake with the customer controller/applications, the bandwidth
   in network would be moved accordingly with the moving of the VNFs.

[MS] Same comments like for all other parts of section 6: First, to me, this problem of SLA violation, notification of those violations, and bandwidth-on-demand is general and not specific to VNFs. In fact, it is not even specific to ACTN. Second, the description lacks any details how this "idea" affects the ACTN framework.

[MS] Bottom line question: Why is Section 6 in this document? I think it can be removed entirely as it discussed issues not specific to ACTN.
   
Page 29:

8.1. Interface between the Application and Customer Network Controller
   (CNC)

[MS] Why does the document discuss security considerations for an interface that is not in scope of ACTN?

---

From: Leeyoung <[email-masked]>
Date: Tue, 3 Jan 2017 22:58:46 +0000

Hi Michael,

Thanks for reviewing the updated framework document and providing us many comments. Please see inline for my comment back to you. I am sure other co-authors will provide their own to where applicable. 

Best regards,
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Monday, January 02, 2017 6:10 PM
To: Leeyoung; [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi all,

Thanks

Michael

Page 5:

YOUNG>> We used 'orchestration' as part of controller functionality. We don't have any specific reference for this term used here. EMS would not need orchestration for service requests mapped to operational commands, but here in ACTN we are talking about multiple control/management entities in a hierarchy, so we need to "coordinate" or "orchestrate" service requests into network operational primitives from the top control entity to all lower level control entities.  

Page 5/6:

YOUNG>> Not particular reference here as well. We are not attempting to define "orchestration", but to say some functions of ACTN such as virtual resource mapping, translation, etc. have some elements of orchestration, loosely speaking. 

Page 7:	

YOUNG>> We can add some comment as you suggested. 

Page 11:

YOUNG>> The list is just as examples not exhaustive. The difference of service providers may come the degree of network control. Some advanced service providers may want to manage/control more than end-to-end connectivity. And as you said, some services may require different data plane connectivity for its service objective (e.g., strict latency limit) and in some cases, the requests may be very specific (e.g., ODU(n)) for OVPN services depending on the Customer Edge connectivity to Provider Networks. Some Data Center providers may require specific data plane technology as their Data Center Edge may be already optical. ISP is quite different from DC provider in this regard. I agree with you, however, we need to be a bit more clear on the connection between "advanced customers" and the listed providers. We will make some comment on this.   

Page 12:

YOUNG>> I think you are correct. We should've referenced to ONF TR-521. Will correct in the next revision. 3-tier refers to the top and bottom and anything in between the top and the bottom. 

Page 12:

YOUNG>> OK. We can delete "at the OSS/NMS". Hope other co-authors would agree with the deletion of this.
		
Page 13:

YOUNG>> For the last term, I agree with you. We may say "service-aware connectivity". Why VNF matters for connectivity? ACTN concerns TE-connectivity where some connectivity has "service constraints" that require VNF/NFV functions such as firewall, virtual storage/compute resources, etc. We are dealing these VNF/NFV functions as constraints to the TE-connectivity. Yes, you're right in that traditional TE connectivity is a simple B/W connectivity; however, new requirements/constraints have emerged and ACTN is trying to deal with so-called "Advanced TE-services". Your comment on end point mobility, why it is only applicable to VNF, not to other cases, is correct. We did not mean to limit the endpoint mobility use-case only applicable to VNF (I think Daniele may give you a better answer for this question). 

Page 14:

YOUNG>> I think I tend to agree with you. We need to clarify this. I think the best way to deal with this is to add comment that the PCE in the figure is meant PCE as a controller (which is adopted in PCE WG). So we either delete PCE out of the figure or add comment that the PCE in the figure is PCE as a controller. Will discuss with the co-authors. 

Page 14:

YOUNG>> We meant application as the end-user application that CNC supports. CNC may request a VN to operate on and there may be multiple end-user applications that use the VN resources allocated to the CNC (a VN thereof). 

Page 16:

YOUNG>> First of all, we are talking about the recursion in multi-domain (not multi-layer). ACTN does not assume its interfaces to be technology agnostic alone. ACTN interfaces can be tech-agnostic or tech-specific depending on how operators want to use them. Abstract topology in its extreme is the actual topology, which means the topology has to be tech-specific topology. ACTN has to support this case as well as tech-agnostic case. The text is applicable to tech-agnostic case. We will add some comments to clarify that recursion of the MDSCs takes place primarily in tech-agnostic case.    

Page 16:

YOUNG>> Yes, I agree. We will add these cases. 

Page 16:

YOUNG>> We used "physical topology" to mean encompassing physical ports/links and physical nodes as well as TE links/nodes because some network may not operate IGP-TE. We can make this distinction more clear by saying, "monitoring the physical topology or TE-topology of the..." 

Page 17:

YOUNG>> A parent PNC only control physical networks as in Figure 3. I would say MDSC is above a parent PNC. Figure 3 is only depicting some implementable architecture as an illustration. 

Page 18:

YOUNG>> I think your point is valid. I will discuss with other co-authors to determine if we should delete interface A or add comments to explain what "application" is really meant, etc. 

Page 19:

YOUNG>> OK. For the wording, "resource provisioning" sounds reasonable. Whether keeping interface D in the document or not will be discussed with other co-authors. If we keep, we will add some comments to make sure this is only for illustration. I still believe it does not harm as long as we have comments that this is not part of ACTN scope. 

Page 23:

YOUNG>> See the previous comment. 

YOUNG>> I don't think virtual PE router as VNF was intended in the mind of the co-authors. Perhaps either Dhruv or Daniele may clarify this point. 

Page 23:
   
6.1. End Point Selection

YOUNG>> RFC 7971 to me has a very different scope than ACTN. Again, as mentioned before, VNF is a constraint to the TE connectivity in ACTN context. We are not talking about the solution, but the applicability of VNF as ACTN TE constraints in this section. That is all!@ 

YOUNG>> ALTO is addressing a different issue than what the text 6.1 is saying. Here we are talking about how to provide VNF-aware TE connectivity in optimal way knowing where certain VNFs are located in its path computation. ACTN MDSC provides this connectivity to the CNC. 

YOUNG>> I see ALTO as generic mechanism to the client so that it would select one out of many choices. This is very different context from ACTN. In ACTN, the CNC makes request TE-services with constraints to the MDSC and MDSC compute the optimal path and provide this to the CNC. 

YOUNG>> Had enough discussion on this. 

Page 24:

YOUNG>> I defer this comment to Daniele. 

YOUNG>> I defer this comment to Daniele. 

Page 25:

YOUNG>> I am not sure why VNF location and re-location should not be considered in ACTN when TE-connectivity has VNF constraints. 

YOUNG>> I disagree with this. 
   
Page 29:

YOUNG>> I defer this to Dan King who wrote this section.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 4 Jan 2017 23:28:29 +0000

Hi Young,

I will wait for the responses of the co-authors how my questions will be addressed.

In this e-mail, I have removed below all discussion except the discussion on "NFV" as I believe my questions have not been addressed.

Before digging into details, some assumptions on my end:

I am not aware of a definition of the term "NFV" in the IETF. RFC 7426 refers to ETSI. Thus, one definition may be ETSI GS NFV 003: "Network Functions Virtualisation (NFV): principle of separating network functions from the hardware they run on by using virtual hardware abstraction."

I think the consequence of this definition for use of "NFV" in ACTN context is two-fold:

1/ If a use case is applicable also to network forwarding functions that not separated from hardware (e.g., a PNF), I believe the term "NFV" is misleading. I would fine with using e.g. the term "network function" in that case.

2/ If a use case is also applicable to software not offering network functions (e.g., non-telecommunication software) or any application that can run in a datacenter (e.g., in a VM), the term "NFV" is misleading and should be avoided. I would be fine with using e.g. the term "cloud function" (or something similar) in that case.

In my understanding, conditions 1/ and 2/ are currently fulfilled in all places where "NFV" is used in the document. The logical consequence is either to improve all the paragraphs to make clear why the use case is absolutely unique to NFV and not applicable to any other cloud use case, or, alternatively, to replace the term by a more general terms that makes clear that it is a general concept.

Flagging ACTN functions as "NFV" while they are generically applicable will be confusing to readers that do not care about these specific applications. 

More inline [MS2]

> [MS] Here I am really lost. Why does this document even start talking about
> NFV services? Why does it matter for the transport service offered by an
> optical, MPLS-TP, or MPLS TE network whether the connectivity is used
> *specifically* by a NFV provider? I.e., is the assumption here that the
> "endpoint mobility use case" is only applicable to VNF but not to other
> general-purpose distribute datacenters, or other endpoint selection use cases?
> I don't believe this is true (see later). So, this reference to NFV is very
> confusing. And using the term "service" recursively in "Service-aware
> Connectivity Services" is also strange to me. If this section cannot be made
> more clear, I think the best solution would be to entirely remove it.
> 
> YOUNG>> For the last term, I agree with you. We may say "service-aware
> connectivity". Why VNF matters for connectivity? ACTN concerns TE-connectivity
> where some connectivity has "service constraints" that require VNF/NFV
> functions such as firewall, virtual storage/compute resources, etc. We are
> dealing these VNF/NFV functions as constraints to the TE-connectivity. Yes,
> you're right in that traditional TE connectivity is a simple B/W connectivity;
> however, new requirements/constraints have emerged and ACTN is trying to deal
> with so-called "Advanced TE-services". Your comment on end point mobility, why
> it is only applicable to VNF, not to other cases, is correct. We did not mean
> to limit the endpoint mobility use-case only applicable to VNF (I think
> Daniele may give you a better answer for this question).

[MS2] If you agree that the use case is not *only* applicable to VNFs, can we agree that the term "NFV" is misleading to categorize services in ACTN context?

[MS2] Note that the functions "security function like a firewall, a traffic optimizer, and the provisioning of storage or computation capacity" can all be provided also as physical network function. And, for example, it can be perfectly possible that a network operator runs physical servers for functions like firewall and traffic optimizers at different places in the network, and during service setup it can be decided which physical function to use. In that case, again, the "customer does not care whether the service is implemented in one physical box or another physical box". In a nutshell: Nothing what is written here seems specific to NFV. This may perhaps be advanced service chaining use cases, but not NFV. If I miss something here, please improve the wording to make clear why what matters to ACTN only applies to VNFs running in an NFV infrastructure and cannot apply to physical network functions deployed traditionally (e.g., without OpenStack).

[MS2] BTW, how is what is described here different from service function chaining?

> [MS] I really don't understand why this document discusses VNFs. I think this
> whole section has to be rephrased not to use the terms NFV and VNF. To me, the
> use cases are not specific to VNFs, but they refer to specific service
> requests that can also occur on non-NFV environments.
> 

[MS2] Are you saying that the endpoint mobility use case is e.g. not applicable to a BNG that does not run virtualized? As far as I understand the use case, it can equally be used for a non-virtualized BNG if one wants to decide dynamically which out of a set of BNGs one would want to use. If I miss something here, please explain why the use caase is limited to vBNGs.
 
> [MS] Also, if virtual network functions are to be discussed in this I-D, it
> may make sense to first analyze the implications of how the ACTN framework can
> handle a PNF that manages VNFs (e.g., virtual PE routers running as VNF). But
> even this topic seems a slippery slope and it may be easier to entirely remove
> NFV implications. More below.
> 
> YOUNG>> I don't think virtual PE router as VNF was intended in the mind of the
> co-authors. Perhaps either Dhruv or Daniele may clarify this point.

[MS2] Couldn't a vPE affect the concept of access points introduces in Section 5? If PE1 is virtual, the fact that it has a "portW" has no particular physical implication - it is just an identifier in the VM. Maybe Section 5 needs some discussion on the virtual topologies if the physical network controller just manages virtual machines?
 
> [MS] This problem can be solved without the ACTN framework. Why does this
> document not reference RFC 7971, in particular Section 6.1?
> 
> YOUNG>> RFC 7971 to me has a very different scope than ACTN. Again, as
> mentioned before, VNF is a constraint to the TE connectivity in ACTN context.
> We are not talking about the solution, but the applicability of VNF as ACTN TE
> constraints in this section. That is all!@

[MS2] Then this sentence need to rephrased to make the difference clear. The statement "the customer doesn't know if the path with minimum delay is towards DC-A, DC-B, or DC-C" can be solved by ALTO very easily and RFC 7971 outlines how.
 
> [MS] Note that in the way the problem is stated here, the "VNF provider" (the
> term should be replaced by ACTN terminology) only has to know the properties
> between the endpoints (e.g., delay) but not the path or a virtual TE topology.
> The IETF has defined the ALTO protocol for exactly that case.
> 
> YOUNG>> ALTO is addressing a different issue than what the text 6.1 is saying.
> Here we are talking about how to provide VNF-aware TE connectivity in optimal
> way knowing where certain VNFs are located in its path computation. ACTN MDSC
> provides this connectivity to the CNC.

[MS2] I don't find this explanation in Section 6.1 and I am not sure what "VNF-aware" TE connectivity really implies (and, again, why it is specific to VNF and not applicable to physical network functions). Maybe I miss something here but I think the wording is confusing.
 
> [MS] And, the fact that the problem can be solved by ALTO actually shows that
> this "endpoint selection" is not specific to VNFs at all. The same problem
> applies to all endpoint selection problems, e.g., in peer-to-peer systems,
> content delivery cache selection, replica placement in distributed databases,
> etc. There is no need to only discuss this use case for VNFs.
> 
> YOUNG>> I see ALTO as generic mechanism to the client so that it would select
> one out of many choices. This is very different context from ACTN. In ACTN,
> the CNC makes request TE-services with constraints to the MDSC and MDSC
> compute the optimal path and provide this to the CNC.

[MS2] I look forward for a clear description of this. I wonder of the MDSC would be able to compute paths that take into account VNFs as "constraints" without understanding a lot of these VNFs and the NFV infrastructure (e.g., whether a VNF can actually be installed in the data center behind an ACTN access points). Are you looking for an MDSC that implements NFV MANO orchestration capabilities? If not, how does MDSC understand the non-TE constraints?

> [MS] Does this description imply a workflow that an ACTN component decides on
> behalf of the VNF provider which endpoint to use? Now, what happens if there
> is not enough compute or storage resources at that endpoint? I am not sure if
> that workflow is what actual NFV systems would do. Is there running code for
> what is described here, or is this just speculation? The more straightforward
> workflow is that the VNF provider queries the network properties, picks the
> best endpoint that also fulfills the non-networking constraints (compute,
> storage, etc.), and then asks ACTN to provide the connectivity. That seems
> doable with the vanilla ACTN functionality. For that workflow, Section 6.1 is
> not needed at all.
> 

[MS2] I have raised a very specific question on what is described in this paragraph and specifically the wording "when the end point is identified", which in the current form could imply that the MDSC identifies where to instantiate a VM. I try to understand if the MSDC would realize NFV MANO functionality for realizing what is described here, which may not be the intention of the authors but then I think the wording can be changed accordingly. 

> [MS] I don't understand why the document mentions this use case. First, hot
> standby is not a functionality specific to VNFs. Hot standby can also be used
> between two database instances running bar metal. So, talking only about VNFs
> is by far too limiting. But, more importantly, I don't understand how the use
> case is meant to work. If the connectivity is "switched" (e.g.,
> reconfiguration of an optical service), it means that it will be difficult for
> the network to detect the failure, right? How would that work? IMHO only the
> "VNF provider" can know whether a hot standby is triggered and if the network
> connectivity has to be reconfigured. To me, from a TE perspective, this use
> case is not different to a re-configuration of an existing service to another
> access point, or is it? To the best of my knowledge, hot standby can also have
> many non-TE implications in reality but I don't believe this document wants to
> start discussing implications of dynamically reconfiguring load balancers,
> service function chaining, etc. that can came along with failover, too.
> 
> [MS] BTW, I wonder why the document discusses resiliency first for this very
> complex use case. It is not obvious to me how the ACTN interfaces would deal
> with basic resiliency mechanisms in the virtual networks (e.g., 1:1
> protection). Any thoughts?
> 
> [MS] Same comments like for all other parts of section 6: First, to me, this
> problem of SLA violation, notification of those violations, and bandwidth-on-
> demand is general and not specific to VNFs. In fact, it is not even specific
> to ACTN. Second, the description lacks any details how this "idea" affects the
> ACTN framework.
> 
> YOUNG>> I am not sure why VNF location and re-location should not be
> considered in ACTN when TE-connectivity has VNF constraints.

[MS2] It could help to provide an example what "TE-connectivity with VNF constraints" could imply in practice. For instance, I would be interested in an informal example what input parameters would be used in a path computation or in a VN setup. Note that traditional TE systems may not understand "VNF constraints" so some discussion on how to realized this with standard TE could be useful. For instance, how would that work in GMPLS?
 
> [MS] Bottom line question: Why is Section 6 in this document? I think it can
> be removed entirely as it discussed issues not specific to ACTN.
> 

[MS2] Section 6 in the current form is very confusing. Given that the intention of all sections is very unclear, it is difficult for me to suggest how to improve the wording. Thus, just removing the whole section seems the simplest option but I am open to better suggestions.

Michael

---

From: Leeyoung <[email-masked]>
Date: Thu, 5 Jan 2017 00:21:13 +0000

Hi Michael,

Now I see more clearly the issues/problems you raised in regards to the term VNF/NFV. I believe it is by and large an issue of terminology. 

I will have chance to reply your specific questions the next day (since it is close to COB in my time zone). Here let me give you what is intended in ACTN in regards to VNF/NFV terms and how the MDSC may coordinate these constraints into the TE connectivity. 

1. VNF/NFV would be better termed as "network/service functions" regardless of its nature is virtual or physical. 

2. ACTN MDSC needs to learn the location of certain network/service functions and its instance status via CMI (CNC-MDSC interface). In this case, CNC is the provider of such information. CNC itself can be a form of NFV-MANO or a simply data center orchestrator that has access to network/service functions as to which DC location and the instance/resource status of such functions in each DC location. As we discussed this can be physical functions or virtual functions. 

3. Please note that this service function aware TE connectivity is an advanced case, not every use-case of ACTN may be applied to this feature. 

I will look forward to further discussion the next day.

Thanks.
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Wednesday, January 04, 2017 5:28 PM
To: Leeyoung; [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Young,

More inline [MS2]

> [MS] Here I am really lost. Why does this document even start talking 
> about NFV services? Why does it matter for the transport service 
> offered by an optical, MPLS-TP, or MPLS TE network whether the 
> connectivity is used
> *specifically* by a NFV provider? I.e., is the assumption here that 
> the "endpoint mobility use case" is only applicable to VNF but not to 
> other general-purpose distribute datacenters, or other endpoint selection use cases?
> I don't believe this is true (see later). So, this reference to NFV is 
> very confusing. And using the term "service" recursively in 
> "Service-aware Connectivity Services" is also strange to me. If this 
> section cannot be made more clear, I think the best solution would be to entirely remove it.
> 
> connectivity". Why VNF matters for connectivity? ACTN concerns 
> TE-connectivity where some connectivity has "service constraints" that 
> require VNF/NFV functions such as firewall, virtual storage/compute 
> resources, etc. We are dealing these VNF/NFV functions as constraints 
> to the TE-connectivity. Yes, you're right in that traditional TE 
> connectivity is a simple B/W connectivity; however, new 
> requirements/constraints have emerged and ACTN is trying to deal with 
> so-called "Advanced TE-services". Your comment on end point mobility, 
> why it is only applicable to VNF, not to other cases, is correct. We 
> did not mean to limit the endpoint mobility use-case only applicable to VNF (I think Daniele may give you a better answer for this question).

> [MS] I really don't understand why this document discusses VNFs. I 
> think this whole section has to be rephrased not to use the terms NFV 
> and VNF. To me, the use cases are not specific to VNFs, but they refer 
> to specific service requests that can also occur on non-NFV environments.
> 

> [MS] Also, if virtual network functions are to be discussed in this 
> I-D, it may make sense to first analyze the implications of how the 
> ACTN framework can handle a PNF that manages VNFs (e.g., virtual PE 
> routers running as VNF). But even this topic seems a slippery slope 
> and it may be easier to entirely remove NFV implications. More below.
> 
> YOUNG>> I don't think virtual PE router as VNF was intended in the 
> YOUNG>> mind of the

> [MS] This problem can be solved without the ACTN framework. Why does 
> this document not reference RFC 7971, in particular Section 6.1?
> 
> We are not talking about the solution, but the applicability of VNF as 
> ACTN TE constraints in this section. That is all!@

> [MS] Note that in the way the problem is stated here, the "VNF 
> provider" (the term should be replaced by ACTN terminology) only has 
> to know the properties between the endpoints (e.g., delay) but not the path or a virtual TE topology.
> Here we are talking about how to provide VNF-aware TE connectivity in 
> optimal way knowing where certain VNFs are located in its path 
> computation. ACTN MDSC provides this connectivity to the CNC.

> [MS] And, the fact that the problem can be solved by ALTO actually 
> shows that this "endpoint selection" is not specific to VNFs at all.
> The same problem applies to all endpoint selection problems, e.g., in 
> peer-to-peer systems, content delivery cache selection, replica 
> placement in distributed databases, etc. There is no need to only discuss this use case for VNFs.
> 
> YOUNG>> I see ALTO as generic mechanism to the client so that it would 
> YOUNG>> select
> one out of many choices. This is very different context from ACTN. In 
> ACTN, the CNC makes request TE-services with constraints to the MDSC 
> and MDSC compute the optimal path and provide this to the CNC.

> [MS] Does this description imply a workflow that an ACTN component 
> decides on behalf of the VNF provider which endpoint to use? Now, what 
> happens if there is not enough compute or storage resources at that 
> endpoint? I am not sure if that workflow is what actual NFV systems 
> would do. Is there running code for what is described here, or is this 
> just speculation? The more straightforward workflow is that the VNF 
> provider queries the network properties, picks the best endpoint that 
> also fulfills the non-networking constraints (compute, storage, etc.), 
> and then asks ACTN to provide the connectivity. That seems doable with 
> the vanilla ACTN functionality. For that workflow, Section 6.1 is not needed at all.
> 

> [MS] I don't understand why the document mentions this use case. 
> First, hot standby is not a functionality specific to VNFs. Hot 
> standby can also be used between two database instances running bar 
> metal. So, talking only about VNFs is by far too limiting. But, more 
> importantly, I don't understand how the use case is meant to work. If 
> the connectivity is "switched" (e.g., reconfiguration of an optical 
> service), it means that it will be difficult for the network to detect 
> the failure, right? How would that work? IMHO only the "VNF provider"
> can know whether a hot standby is triggered and if the network 
> connectivity has to be reconfigured. To me, from a TE perspective, 
> this use case is not different to a re-configuration of an existing 
> service to another access point, or is it? To the best of my 
> knowledge, hot standby can also have many non-TE implications in 
> reality but I don't believe this document wants to start discussing implications of dynamically reconfiguring load balancers, service function chaining, etc. that can came along with failover, too.
> 
> [MS] BTW, I wonder why the document discusses resiliency first for 
> this very complex use case. It is not obvious to me how the ACTN 
> interfaces would deal with basic resiliency mechanisms in the virtual 
> networks (e.g., 1:1 protection). Any thoughts?
> 
> [MS] Same comments like for all other parts of section 6: First, to 
> me, this problem of SLA violation, notification of those violations, 
> and bandwidth-on- demand is general and not specific to VNFs. In fact, 
> it is not even specific to ACTN. Second, the description lacks any 
> details how this "idea" affects the ACTN framework.
> 

> [MS] Bottom line question: Why is Section 6 in this document? I think 
> it can be removed entirely as it discussed issues not specific to ACTN.
> 

Michael

---

From: Leeyoung <[email-masked]>
Date: Thu, 5 Jan 2017 22:14:46 +0000

Hi Michael,

Following yesterday's comment, I'd like to response to your specific questions and pending issues one by one. Please see inline for my comments.

Thanks.
Young

-----Original Message-----
From: Leeyoung 
Sent: Wednesday, January 04, 2017 6:21 PM
To: 'Scharf, Michael (Nokia - DE)'
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Michael,

Thanks.
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Wednesday, January 04, 2017 5:28 PM
To: Leeyoung; [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Young,

YOUNG>> OK. Some of them are better termed as "service function". We can consider network function or service function as both conveys TE constraints. 

YOUNG>> I am not familiar with "cloud function". 

YOUNG>> This is reasonable. If I took out "NFV" but use VNF and/or NF/SF, that clarifies quite a bit of your question. 

YOUNG>> Agree. 

More inline [MS2]

YOUNG>> Yes. 

YOUNG>> in ACTN, there is no distinction if functions (service or network) to perform are virtual or physical. ACTN makes use of resource information associated with these functions to determine the optimal end-to-end path subject to meeting these resource constraints. 

YOUNG>> As mentioned before, ACTN can create TE-enabled service function chaining as it can also create TE-enabled network function (virtual or physical).  

YOUNG>> OK. How about:

OLD: Virtual networks could be used as the infrastructure to connect a

NEW: Virtual networks could be used as the infrastructure to connect a
    number of sites belonging to a customer or to provide connectivity
    between customer sites and Network Functions (NF)/Virtual Network Functions (VNF) such
    as firewalls/virtual firewalls, Broadband Network Gateway (BNG)/virtual BNG (vBNG),
    storage, or computational functions. 

YOUNG>> I still want either Dhruv or Daniele to answer this point. But I think this issue is not the main issue of ACTN. Whether it is virtual port or physical port, the access point still needs to be identified as an identifier - why would the customer care if the PE port is physical or virtual. 

YOUNG>> There in no intention to introduce ALTO in ACTN. There is no need to send the delay info to customer in ACTN since the customer is the one who asks the ACTN MDSC to provision the minimum delay path and set up such connectivity in the network. I think you are mixing up the two different contexts and assumptions. 

YOUNG>> Again this is a recurring issue around VNF/NF. ACTN deals with VNF-, NF-, SF- aware TE connectivity. Would changes from VNF to VNF/NF make you happy? 

YOUNG>> No. MDSC would not implement NFV MANO-O function. MSDC would get this information from other entities such as Data Center Operator/ or even NFV-MANO both of which can be regarded as a CNC in ACTN architecture. 

YOUNG>> This refers to multi-destination case where there could be a number of destination endpoint of a certain application. Customer can provide this information to MDSC and let the MDSC choose the best e2e path (selecting the optimal destination endpoint) via policy (delegation policy). Other choice can be that MDSC provides all possible TE-path information and let the customer choose the optimal path. Either one is possible, but here this section describes the delegated policy where MDSC is allowed to choose the best path.  

YOUNG>> If your TE-connectivity is gaming application where it consumes compute/VM at the server that connects the network path from the source D/C and destination D/C. This compute/VM information is provided by the Data Center operator CNC to the network provider MSDC: For each Data Center, it would have how many compute/VM available for this application. The service request would indicate how much compute/VM resource this particular gaming application would consume. In addition, which D/Cs are available as a pool of destinations. All these are provided by the DC operator's CNC to the network provider's MDSC. Then MDSC would compute the best network path while factoring VM resource information to find joint-optimized path. 

YOUNG>> As we agreed on the use of the term VNF, we will make come clarifications. Thanks.

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 6 Jan 2017 00:49:12 +0000

Inline [MS3], skipping some parts...

> 1/ If a use case is applicable also to network forwarding functions that not
> separated from hardware (e.g., a PNF), I believe the term "NFV" is misleading.
> I would fine with using e.g. the term "network function" in that case.
> 
> YOUNG>> OK. Some of them are better termed as "service function". We can
> consider network function or service function as both conveys TE constraints.

[MS3] I don't care whether you call it "network function" or "service function". My concerns are way more fundamental.
 
> 2/ If a use case is also applicable to software not offering network functions
> (e.g., non-telecommunication software) or any application that can run in a
> datacenter (e.g., in a VM), the term "NFV" is misleading and should be
> avoided. I would be fine with using e.g. the term "cloud function" (or
> something similar) in that case.
> 

[MS3] The better term would actually be just "software application" or "data center application", but as the document seems to define "application" with a very special meaning (which I believe should be re-considered - see my initial e-mail) I was looking for something else. I don't insist in any term as long as it is clear that ACTN applies to any IT application, not to telecommunication only. Examples for IT are databases, big data analytics systems, storage backup systems, etc. Of course they can run in distributed data centers and ACTN be used to dynamically provide connectivity to them. And of course they can have relatively special connectivity requirements.

> [MS2] Note that the functions "security function like a firewall, a traffic
> optimizer, and the provisioning of storage or computation capacity" can all be
> provided also as physical network function. And, for example, it can be
> perfectly possible that a network operator runs physical servers for functions
> like firewall and traffic optimizers at different places in the network, and
> during service setup it can be decided which physical function to use. In that
> case, again, the "customer does not care whether the service is implemented in
> one physical box or another physical box". In a nutshell: Nothing what is
> written here seems specific to NFV. This may perhaps be advanced service
> chaining use cases, but not NFV. If I miss something here, please improve the
> wording to make clear why what matters to ACTN only applies to VNFs running in
> an NFV infrastructure and cannot apply to physical network functions deployed
> traditionally (e.g., without OpenStack).
> 
> YOUNG>> in ACTN, there is no distinction if functions (service or network) to
> perform are virtual or physical. ACTN makes use of resource information
> associated with these functions to determine the optimal end-to-end path
> subject to meeting these resource constraints.

[MS3] How would that work? Do you plan to add e.g. virtual machine compute or storage resource information to the PCEP protocol, in case that e.g. the PNC uses a PCE for optimal path computation? I do *not* believe that this is what ACTN should do.
 
> YOUNG>> As mentioned before, ACTN can create TE-enabled service function
> chaining as it can also create TE-enabled network function (virtual or
> physical).

[MS3] Which of the four functions defined in Section 3 "creates TE-enabled network function"? I may miss something, but to me "create TE-enabled network function" is not in scope of the four functions defined in Section 3 and thus not an objective of ACTN. Of course, an ETSI MANO orchestrator, or another service fulfillment system, can provide this functionality.
 
> [MS2] Are you saying that the endpoint mobility use case is e.g. not
> applicable to a BNG that does not run virtualized? As far as I understand the
> use case, it can equally be used for a non-virtualized BNG if one wants to
> decide dynamically which out of a set of BNGs one would want to use. If I miss
> something here, please explain why the use caase is limited to vBNGs.
> 
> YOUNG>> OK. How about:
> 

[MS3] As you comment earlier, for ACTN it doesn't matter whether it is physical or virtual, so why to bother about mentioning both? Anyway, I'd focus this section on examples for "software applications" that can really leverage dynamic TE engineering as enabled by ACTN. The assumption that firewalls and BNGs will be the most important drivers for ACTN deployment is a bit interesting, but, sure, it is not impossible.
 
> [MS2] Then this sentence need to rephrased to make the difference clear. The
> statement "the customer doesn't know if the path with minimum delay is towards
> DC-A, DC-B, or DC-C" can be solved by ALTO very easily and RFC 7971 outlines
> how.
> 
> YOUNG>> There in no intention to introduce ALTO in ACTN. There is no need to
> send the delay info to customer in ACTN since the customer is the one who asks
> the ACTN MDSC to provision the minimum delay path and set up such connectivity
> in the network. I think you are mixing up the two different contexts and
> assumptions.

[MS3] No, I do not believe I am mixing up different contexts. I focus on the case in which an ETSI MANO orchestrator wants to decide which data center to pick and therefore asks the MDSC about the optimum end-to-end path properties between the different data centers, possibly for a new connectivity service to be set up. This is the use case explained in RFC 7971. In that case, an MDSC hypothetically supporting ALTO would be sufficient for providing said ETSI MANO orchestrator the information what is needed according to the wording currently in the I-D. Of course, ALTO only enables the MANO orchestrator to pick the right data center, and a second API will be needed for actually requesting the connectivity. That second service fulfillment API could e.g. the IETF L3SM or L2SM YANG model. They are not mentioned in RFC 7971 since they did not exist when RFC 7971 was written. But it seems to me that ALTO + L2SM or L3SM are sufficient for realizing the use case in this Section. BTW, we have actually implemented exactly this use case in 2012. And we didn't need any VNF-awareness in what ACTN calls MDSC.

[MS3] But my point is not about ALTO. Obviously one can provide the same information also e.g. with the TEAS YANG models. My point is that the use case doesn't clearly describe why any special support in ACTN is needed. As I said, an implementation without VNF-awareness seems possible.
 
> [MS2] I don't find this explanation in Section 6.1 and I am not sure what
> "VNF-aware" TE connectivity really implies (and, again, why it is specific to
> VNF and not applicable to physical network functions). Maybe I miss something
> here but I think the wording is confusing.
> 
> YOUNG>> Again this is a recurring issue around VNF/NF. ACTN deals with VNF-,
> NF-, SF- aware TE connectivity. Would changes from VNF to VNF/NF make you
> happy?

[MS3] My concern is not about terminology in this case. I would like to explicitly understand what extensions are needed e.g. in a PCE and the PCEP protocol for that "awareness". Please add an example how a PCE would calculate the optimum path with that "awareness" and what parameters it needs for that.
 
> [MS2] I look forward for a clear description of this. I wonder of the MDSC
> would be able to compute paths that take into account VNFs as "constraints"
> without understanding a lot of these VNFs and the NFV infrastructure (e.g.,
> whether a VNF can actually be installed in the data center behind an ACTN
> access points). Are you looking for an MDSC that implements NFV MANO
> orchestration capabilities? If not, how does MDSC understand the non-TE
> constraints?
> 
> YOUNG>> No. MDSC would not implement NFV MANO-O function. MSDC would get this
> information from other entities such as Data Center Operator/ or even NFV-MANO
> both of which can be regarded as a CNC in ACTN architecture.

[MS3] So, as a result of this use case, do you suggest that an CMI interface standardized in the IETF TEAS working group would standardize NFV MANO specific attributes?

[MS3] If so, I think we have to have a discussion about the term "general applicability" in the TEAS charter wording "Traffic-engineering architectures for generic applicability across packet and non-packet networks".
 
> [MS2] I have raised a very specific question on what is described in this
> paragraph and specifically the wording "when the end point is identified",
> which in the current form could imply that the MDSC identifies where to
> instantiate a VM. I try to understand if the MSDC would realize NFV MANO
> functionality for realizing what is described here, which may not be the
> intention of the authors but then I think the wording can be changed
> accordingly.
> 
> YOUNG>> This refers to multi-destination case where there could be a number of
> destination endpoint of a certain application. Customer can provide this
> information to MDSC and let the MDSC choose the best e2e path (selecting the
> optimal destination endpoint) via policy (delegation policy). Other choice can
> be that MDSC provides all possible TE-path information and let the customer
> choose the optimal path. Either one is possible, but here this section
> describes the delegated policy where MDSC is allowed to choose the best path.

[MS3] Thanks for the explanation. This wording makes this use case clearer. I think this describes a relatively generic "anycast" connectivity service request that has nothing to do with NFV. It can equally apply e.g. to certain dual-homing scenarios, right? So maybe it should be discussed in the context of dual-homing.
 
> [MS2] Section 6 in the current form is very confusing. Given that the
> intention of all sections is very unclear, it is difficult for me to suggest
> how to improve the wording. Thus, just removing the whole section seems the
> simplest option but I am open to better suggestions.
> 

[MS3] Given the explanations of the use cases in this discussion, I am even more convinces that Section 6 has to be entirely removed from the document. Unless I miss something, these use cases seem to be about technology-specific standardization of attributes for service provisioning/fulfillment of network/service functions, such as the standardization of NFV MANO-specific attributes in the CMI interface. To me, this standardization is not in scope of the current TEAS charter.

Michael

---

From: Leeyoung <[email-masked]>
Date: Mon, 9 Jan 2017 20:06:25 +0000

Hi Michael,

Please see inline for my further comments on your points. 

Thanks,
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Thursday, January 05, 2017 6:49 PM
To: Leeyoung
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

> 1/ If a use case is applicable also to network forwarding functions 
> that not separated from hardware (e.g., a PNF), I believe the term "NFV" is misleading.
> YOUNG>> OK. Some of them are better termed as "service function". We 
> YOUNG>> can

> 2/ If a use case is also applicable to software not offering network 
> functions (e.g., non-telecommunication software) or any application 
> that can run in a datacenter (e.g., in a VM), the term "NFV" is 
> misleading and should be avoided. I would be fine with using e.g. the 
> term "cloud function" (or something similar) in that case.
> 

YOUNG>> That is why I suggested to use NF/VNF/SF to convey this application you are referring to. S/W or DC application or cloud application are more confusing to me. 

> [MS2] Note that the functions "security function like a firewall, a 
> traffic optimizer, and the provisioning of storage or computation 
> capacity" can all be provided also as physical network function. And, 
> for example, it can be perfectly possible that a network operator runs 
> physical servers for functions like firewall and traffic optimizers at 
> different places in the network, and during service setup it can be 
> decided which physical function to use. In that case, again, the 
> "customer does not care whether the service is implemented in one 
> physical box or another physical box". In a nutshell: Nothing what is 
> written here seems specific to NFV. This may perhaps be advanced 
> service chaining use cases, but not NFV. If I miss something here, 
> please improve the wording to make clear why what matters to ACTN only 
> applies to VNFs running in an NFV infrastructure and cannot apply to physical network functions deployed traditionally (e.g., without OpenStack).
> 
> YOUNG>> in ACTN, there is no distinction if functions (service or 
> YOUNG>> network) to
> perform are virtual or physical. ACTN makes use of resource 
> information associated with these functions to determine the optimal 
> end-to-end path subject to meeting these resource constraints.

YOUNG>> We are not addressing in this document any particular solution. I think you mixed up PCE function and PCEP. Here I meant PCE function in ACTN, not PCEP in particular. The MDSC would gather different information from different means to compute end-to-end path subject to these constraints. The MDSC may get TE information from the MPI either via YANG model or PCEP/BGP while it may need to get other data center application information over the CMI from data center controllers/orchestrators. I don't envision nor have plan to add virtual machine compute or storage resource in PCEP. 
 
> YOUNG>> As mentioned before, ACTN can create TE-enabled service 
> YOUNG>> function

YOUNG>> I think this may be part of the two functions: (i) Virtualization/Abstraction function; (ii) Virtual Service Coordination function. In (i), we have this clause: "This function includes network path computation based on customer service connectivity request constraints, path computation based on the global network-wide abstracted topology, and the creation of an abstracted view of network slices allocated to each customer. These operations depend on customer-specific network objective functions and customer traffic profiles. And in (ii), we have "This function translates customer service-related information into virtual network service operations in order to seamlessly operate virtual networks while meeting a customer's service requirements."

YOUNG>> In regard to your comment on "an ETSI MANO orchestrator or other service fulfillment system can provide this functionality", can they perform PCE function with multiple constraints/objectives, where do they get TE/abstraction information from, can they perform multi-destination path computation? If they do, then they are not different from ACTN MDSC functionality. But I don't think so. 
 
> applicable to a BNG that does not run virtualized? As far as I 
> understand the use case, it can equally be used for a non-virtualized 
> BNG if one wants to decide dynamically which out of a set of BNGs one 
> would want to use. If I miss something here, please explain why the use caase is limited to vBNGs.
> 
> YOUNG>> OK. How about:
> 

YOUNG>> Where did you get the idea that firewalls and BNGs will be most important drivers for ACTN deployment? As I said before, this is an enhanced function of ACTN but not necessarily the main driver. 

> > YOUNG>> RFC 7971 to me has a very different scope than ACTN. Again, 
> > YOUNG>> as
> > We are not talking about the solution, but the applicability of VNF 
> > as ACTN TE constraints in this section. That is all!@
> 
> [MS2] Then this sentence need to rephrased to make the difference 
> clear. The statement "the customer doesn't know if the path with 
> minimum delay is towards DC-A, DC-B, or DC-C" can be solved by ALTO 
> very easily and RFC 7971 outlines how.
> 
> YOUNG>> There in no intention to introduce ALTO in ACTN. There is no 
> YOUNG>> need to
> send the delay info to customer in ACTN since the customer is the one 
> who asks the ACTN MDSC to provision the minimum delay path and set up 
> such connectivity in the network. I think you are mixing up the two 
> different contexts and assumptions.

YOUNG>> ACTN architecture does not assume anything about nor depend on ETSI MANO-O. L2SM/L3SM can be supported in the CMI of ACTN as well as other VN service request/instantiation model. We have no bearing with ALTO either. In ACTN architecture, CNC (Data Center Controller/Orchestrator as one type of CNC) may request the MDSC the underlying VN or connectivity information so that it would make the decision as to which data center may be chosen; then ask service provisioning request to the MDSC. Another way is the CNC that provides VNF/NF/SF information to the MDSC and let MDSC decide and provision the best choice VN/connectivity with VNF/NF/SC constraints. It is a policy decision between CNC and MDSC. ACTN supports both cases. 
 
> > to know the properties between the endpoints (e.g., delay) but not 
> > the path
> or a virtual TE topology.
> > YOUNG>> ALTO is addressing a different issue than what the text 6.1 
> > YOUNG>> is
> saying.
> > Here we are talking about how to provide VNF-aware TE connectivity 
> > in optimal way knowing where certain VNFs are located in its path 
> [MS2] I don't find this explanation in Section 6.1 and I am not sure 
> what "VNF-aware" TE connectivity really implies (and, again, why it is 
> specific to VNF and not applicable to physical network functions). 
> Maybe I miss something here but I think the wording is confusing.
> 
> YOUNG>> Again this is a recurring issue around VNF/NF. ACTN deals with 
> YOUNG>> VNF-,
> NF-, SF- aware TE connectivity. Would changes from VNF to VNF/NF make 
> you happy?

YOUNG>> As said before, we are not talking about PCEP here to carry these constraints. These information will come over CMI (CNC-MDSC) via a data model. 
 
> > The same problem applies to all endpoint selection problems, e.g., 
> > in peer-to-peer systems, content delivery cache selection, replica 
> > placement in distributed databases, etc. There is no need to only 
> > discuss
> this use case for VNFs.
> >
> > YOUNG>> I see ALTO as generic mechanism to the client so that it 
> > YOUNG>> would select
> > one out of many choices. This is very different context from ACTN. 
> > In ACTN, the CNC makes request TE-services with constraints to the 
> > MDSC and MDSC compute the optimal path and provide this to the CNC.
> 
> [MS2] I look forward for a clear description of this. I wonder of the 
> MDSC would be able to compute paths that take into account VNFs as "constraints"
> without understanding a lot of these VNFs and the NFV infrastructure 
> (e.g., whether a VNF can actually be installed in the data center 
> behind an ACTN access points). Are you looking for an MDSC that 
> implements NFV MANO orchestration capabilities? If not, how does MDSC 
> understand the non-TE constraints?
> 
> YOUNG>> No. MDSC would not implement NFV MANO-O function. MSDC would 
> YOUNG>> get this
> information from other entities such as Data Center Operator/ or even 
> NFV-MANO both of which can be regarded as a CNC in ACTN architecture.

YOUNG>> NO, not in particular NFV MANO, whatever data center operator provides for their dynamic mobility/connectivity can be a part of CMI model. 

YOUNG>> TE is a capability shared across packet and non-packet already in its definition. Not sure what you are trying to do here by bringing TEAS charter. 
 
> > decides on behalf of the VNF provider which endpoint to use? Now, 
> > what happens if there is not enough compute or storage resources at 
> > that endpoint? I am not sure if that workflow is what actual NFV 
> > systems would do. Is there running code for what is described here, 
> > or is this just speculation? The more straightforward workflow is 
> > that the VNF provider queries the network properties, picks the best 
> > endpoint that also fulfills the non-networking constraints (compute, 
> > storage, etc.), and then asks ACTN to provide the connectivity. That 
> > seems doable with the vanilla ACTN functionality. For that workflow, 
> > Section 6.1 is not needed
> at all.
> >
> [MS2] I have raised a very specific question on what is described in 
> this paragraph and specifically the wording "when the end point is 
> identified", which in the current form could imply that the MDSC 
> identifies where to instantiate a VM. I try to understand if the MSDC 
> would realize NFV MANO functionality for realizing what is described 
> here, which may not be the intention of the authors but then I think 
> the wording can be changed accordingly.
> 
> YOUNG>> This refers to multi-destination case where there could be a 
> YOUNG>> number of
> destination endpoint of a certain application. Customer can provide 
> this information to MDSC and let the MDSC choose the best e2e path 
> (selecting the optimal destination endpoint) via policy (delegation 
> policy). Other choice can be that MDSC provides all possible TE-path 
> information and let the customer choose the optimal path. Either one 
> is possible, but here this section describes the delegated policy where MDSC is allowed to choose the best path.

YOUNG>> Yes. Multi-destination is not same as dual homing. Destination can be a single-homing but we can have many of them. I don't think multi-destination should be discussed in the context of dual-homing. 
 
> > [MS] Bottom line question: Why is Section 6 in this document? I 
> > think it can be removed entirely as it discussed issues not specific to ACTN.
> >
> intention of all sections is very unclear, it is difficult for me to 
> suggest how to improve the wording. Thus, just removing the whole 
> section seems the simplest option but I am open to better suggestions.
> 

YOUNG>> I disagree with this again. No you still misunderstand the intention here. As discussed, let me make it clear: we have no intention of standardizing NFV MANO specific attributes (I don't even know what they are) in the CMI. 

Michael

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Jan 2017 09:30:00 +0000

Michael,

ACTN is about providing connectivity. The request for such connectivity can be received in two different shapes:

1. Connectivity between A and B (or more points, physical or virtual)- This is what we refer to as "Connectivity Services". The term "service aware" is used to indicate the fact that constraints can be defined against a service and then need to be translated to the underlay connectivity (VN, tunnels, whatever)

2. A "FUNCTION" offered to a site connected to point A - This is what we refer to as "NFV Services". What ACTN provides is again connectivity between two points, A and B, but this time B is not specified. Instead of B we have a list of (typically) data centers, because the customer was asking for a given "FUNCTION" for his site A and doesn't care where this function is implemented (physically or virtually). If you don't like the term VNF we can find a better term...application? Function? Whatever? But that is the concept.

Daniele  

> From: Teas [mailto:[email-masked]] On Behalf Of Leeyoung
> Sent: lunedì 9 gennaio 2017 21:06
> To: Scharf, Michael (Nokia - DE) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt
> 
> Hi Michael,
> 
> [MS3] The better term would actually be just "software application" or "data
> center application", but as the document seems to define "application" with a
> very special meaning (which I believe should be re-considered - see my initial
> e-mail) I was looking for something else. I don't insist in any term as long as it is
> clear that ACTN applies to any IT application, not to telecommunication only.
> Examples for IT are databases, big data analytics systems, storage backup
> systems, etc. Of course they can run in distributed data centers and ACTN be
> used to dynamically provide connectivity to them. And of course they can have
> relatively special connectivity requirements.
> 
> YOUNG>> That is why I suggested to use NF/VNF/SF to convey this application
> you are referring to. S/W or DC application or cloud application are more
> confusing to me.
> 
> > applies to VNFs running in an NFV infrastructure and cannot apply to physical
> network functions deployed traditionally (e.g., without OpenStack).
> >
> [MS3] How would that work? Do you plan to add e.g. virtual machine compute
> or storage resource information to the PCEP protocol, in case that e.g. the PNC
> uses a PCE for optimal path computation? I do *not* believe that this is what
> ACTN should do.
> 
> YOUNG>> We are not addressing in this document any particular solution. I
> think you mixed up PCE function and PCEP. Here I meant PCE function in ACTN,
> not PCEP in particular. The MDSC would gather different information from
> different means to compute end-to-end path subject to these constraints. The
> MDSC may get TE information from the MPI either via YANG model or
> PCEP/BGP while it may need to get other data center application information
> over the CMI from data center controllers/orchestrators. I don't envision nor
> have plan to add virtual machine compute or storage resource in PCEP.
> 
> [MS3] Which of the four functions defined in Section 3 "creates TE-enabled
> network function"? I may miss something, but to me "create TE-enabled
> network function" is not in scope of the four functions defined in Section 3 and
> thus not an objective of ACTN. Of course, an ETSI MANO orchestrator, or
> another service fulfillment system, can provide this functionality.
> 
> YOUNG>> I think this may be part of the two functions: (i)
> Virtualization/Abstraction function; (ii) Virtual Service Coordination function. In
> (i), we have this clause: "This function includes network path computation
> based on customer service connectivity request constraints, path computation
> based on the global network-wide abstracted topology, and the creation of an
> abstracted view of network slices allocated to each customer. These
> operations depend on customer-specific network objective functions and
> customer traffic profiles. And in (ii), we have "This function translates
> customer service-related information into virtual network service operations in
> order to seamlessly operate virtual networks while meeting a customer's
> service requirements."
> 
> YOUNG>> In regard to your comment on "an ETSI MANO orchestrator or other
> service fulfillment system can provide this functionality", can they perform PCE
> function with multiple constraints/objectives, where do they get
> TE/abstraction information from, can they perform multi-destination path
> computation? If they do, then they are not different from ACTN MDSC
> functionality. But I don't think so.
> 
> [MS3] As you comment earlier, for ACTN it doesn't matter whether it is
> physical or virtual, so why to bother about mentioning both? Anyway, I'd focus
> this section on examples for "software applications" that can really leverage
> dynamic TE engineering as enabled by ACTN. The assumption that firewalls and
> BNGs will be the most important drivers for ACTN deployment is a bit
> interesting, but, sure, it is not impossible.
> 
> YOUNG>> Where did you get the idea that firewalls and BNGs will be most
> important drivers for ACTN deployment? As I said before, this is an enhanced
> function of ACTN but not necessarily the main driver.
> 
> > > Page 23:
> > >
> > > 6.1. End Point Selection
> > >
> [MS3] No, I do not believe I am mixing up different contexts. I focus on the
> case in which an ETSI MANO orchestrator wants to decide which data center to
> pick and therefore asks the MDSC about the optimum end-to-end path
> properties between the different data centers, possibly for a new connectivity
> service to be set up. This is the use case explained in RFC 7971. In that case, an
> MDSC hypothetically supporting ALTO would be sufficient for providing said
> ETSI MANO orchestrator the information what is needed according to the
> wording currently in the I-D. Of course, ALTO only enables the MANO
> orchestrator to pick the right data center, and a second API will be needed for
> actually requesting the connectivity. That second service fulfillment API could
> e.g. the IETF L3SM or L2SM YANG model. They are not mentioned in RFC 7971
> since they did not exist when RFC 7971 was written. But it seems to me that
> ALTO + L2SM or L3SM are sufficient for realizing the use case in this Section.
> BTW, we have
>   actually implemented exactly this use case in 2012. And we didn't need any
> VNF-awareness in what ACTN calls MDSC.
> 
> [MS3] But my point is not about ALTO. Obviously one can provide the same
> information also e.g. with the TEAS YANG models. My point is that the use case
> doesn't clearly describe why any special support in ACTN is needed. As I said,
> an implementation without VNF-awareness seems possible.
> 
> YOUNG>> ACTN architecture does not assume anything about nor depend on
> ETSI MANO-O. L2SM/L3SM can be supported in the CMI of ACTN as well as
> other VN service request/instantiation model. We have no bearing with ALTO
> either. In ACTN architecture, CNC (Data Center Controller/Orchestrator as one
> type of CNC) may request the MDSC the underlying VN or connectivity
> information so that it would make the decision as to which data center may be
> chosen; then ask service provisioning request to the MDSC. Another way is the
> CNC that provides VNF/NF/SF information to the MDSC and let MDSC decide
> and provision the best choice VN/connectivity with VNF/NF/SC constraints. It
> is a policy decision between CNC and MDSC. ACTN supports both cases.
> 
> [MS3] My concern is not about terminology in this case. I would like to
> explicitly understand what extensions are needed e.g. in a PCE and the PCEP
> protocol for that "awareness". Please add an example how a PCE would
> calculate the optimum path with that "awareness" and what parameters it
> needs for that.
> 
> YOUNG>> As said before, we are not talking about PCEP here to carry these
> constraints. These information will come over CMI (CNC-MDSC) via a data
> model.
> 
> [MS3] So, as a result of this use case, do you suggest that an CMI interface
> standardized in the IETF TEAS working group would standardize NFV MANO
> specific attributes?
> 
> YOUNG>> NO, not in particular NFV MANO, whatever data center operator
> provides for their dynamic mobility/connectivity can be a part of CMI model.
> 
> [MS3] If so, I think we have to have a discussion about the term "general
> applicability" in the TEAS charter wording "Traffic-engineering architectures for
> generic applicability across packet and non-packet networks".
> 
> YOUNG>> TE is a capability shared across packet and non-packet already in its
> definition. Not sure what you are trying to do here by bringing TEAS charter.
> 
> [MS3] Thanks for the explanation. This wording makes this use case clearer. I
> think this describes a relatively generic "anycast" connectivity service request
> that has nothing to do with NFV. It can equally apply e.g. to certain dual-
> homing scenarios, right? So maybe it should be discussed in the context of
> dual-homing.
> 
> YOUNG>> Yes. Multi-destination is not same as dual homing. Destination can
> be a single-homing but we can have many of them. I don't think multi-
> destination should be discussed in the context of dual-homing.
> 
> [MS3] Given the explanations of the use cases in this discussion, I am even
> more convinces that Section 6 has to be entirely removed from the document.
> Unless I miss something, these use cases seem to be about technology-
> specific standardization of attributes for service provisioning/fulfillment of
> network/service functions, such as the standardization of NFV MANO-specific
> attributes in the CMI interface. To me, this standardization is not in scope of
> the current TEAS charter.
> 
> YOUNG>> I disagree with this again. No you still misunderstand the intention
> here. As discussed, let me make it clear: we have no intention of standardizing
> NFV MANO specific attributes (I don't even know what they are) in the CMI.
> 
> Michael
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 10 Jan 2017 14:08:29 +0000

Daniele,

What is the point of connecting location A to location B other than to connect a set of functions on A to set of functions on B?

Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Tuesday, January 10, 2017 4:30 AM
To: Leeyoung; Scharf, Michael (Nokia - DE)
Cc: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Michael,

Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Jan 2017 14:18:57 +0000

Hi Igor,

Connecting functions on A to functions on B could or could not be a business of the operator.

The customer could ask for connectivity from A to B and do whatever he wants with the traffic received on B (and vice versa), like e.g. a L3VPN. 
OR
The customer can ask for a function applied to the traffic generated from A and directed to whatever destination. IN that case the traffic goes through B (or C or D...) where it can be terminated by the function or pass through and be treated by the function (e.g. firewall, parental control...etc).

Cheers
Daniele  

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: martedì 10 gennaio 2017 15:08
> To: Daniele Ceccarelli <[email-masked]>; Leeyoung
> <[email-masked]>; Scharf, Michael (Nokia - DE)
> <[email-masked]>
> Cc: [email-masked]
> What is the point of connecting location A to location B other than to connect a
> set of functions on A to set of functions on B?
> 
> Igor
> 
> 
> 
> 1. Connectivity between A and B (or more points, physical or virtual)- This is
> what we refer to as "Connectivity Services". The term "service aware" is used
> to indicate the fact that constraints can be defined against a service and then
> need to be translated to the underlay connectivity (VN, tunnels, whatever)
> 
> 2. A "FUNCTION" offered to a site connected to point A - This is what we refer
> to as "NFV Services". What ACTN provides is again connectivity between two
> points, A and B, but this time B is not specified. Instead of B we have a list of
> (typically) data centers, because the customer was asking for a given
> "FUNCTION" for his site A and doesn't care where this function is implemented
> (physically or virtually). If you don't like the term VNF we can find a better
> term...application? Function? Whatever? But that is the concept.
> 
> Daniele
> 
> > > that not separated from hardware (e.g., a PNF), I believe the term
> > > "NFV" is
> > misleading.
> > [MS3] I don't care whether you call it "network function" or "service
> function".
> > My concerns are way more fundamental.
> >
> > > misleading and should be avoided. I would be fine with using e.g.
> > > the term "cloud function" (or something similar) in that case.
> > >
> > [MS3] The better term would actually be just "software application" or
> > "data center application", but as the document seems to define
> > "application" with a very special meaning (which I believe should be
> > re-considered - see my initial
> > e-mail) I was looking for something else. I don't insist in any term
> > as long as it is clear that ACTN applies to any IT application, not to
> telecommunication only.
> > Examples for IT are databases, big data analytics systems, storage
> > backup systems, etc. Of course they can run in distributed data
> > centers and ACTN be used to dynamically provide connectivity to them.
> > And of course they can have relatively special connectivity requirements.
> >
> > YOUNG>> That is why I suggested to use NF/VNF/SF to convey this
> > YOUNG>> application
> > you are referring to. S/W or DC application or cloud application are
> > more confusing to me.
> >
> > > capacity" can all be provided also as physical network function.
> > > And, for example, it can be perfectly possible that a network
> > > operator runs physical servers for functions like firewall and
> > > traffic optimizers at different places in the network, and during
> > > service setup it can be decided which physical function to use. In
> > > that case, again, the "customer does not care whether the service is
> > > implemented in one physical box or another physical box". In a
> > > nutshell: Nothing what is written here seems specific to NFV. This
> > > may perhaps be advanced service chaining use cases, but not NFV. If
> > > I miss something here, please improve the wording to make clear why
> > > what matters to ACTN only applies to VNFs running in an NFV
> > > infrastructure and cannot apply to physical
> > [MS3] How would that work? Do you plan to add e.g. virtual machine
> > compute or storage resource information to the PCEP protocol, in case
> > that e.g. the PNC uses a PCE for optimal path computation? I do *not*
> > believe that this is what ACTN should do.
> >
> > YOUNG>> We are not addressing in this document any particular
> > YOUNG>> solution. I
> > think you mixed up PCE function and PCEP. Here I meant PCE function in
> > ACTN, not PCEP in particular. The MDSC would gather different
> > information from different means to compute end-to-end path subject to
> > these constraints. The MDSC may get TE information from the MPI either
> > via YANG model or PCEP/BGP while it may need to get other data center
> > application information over the CMI from data center
> > controllers/orchestrators. I don't envision nor have plan to add virtual
> machine compute or storage resource in PCEP.
> >
> > > chaining as it can also create TE-enabled network function (virtual
> > > or physical).
> >
> > [MS3] Which of the four functions defined in Section 3 "creates
> > TE-enabled network function"? I may miss something, but to me "create
> > TE-enabled network function" is not in scope of the four functions
> > defined in Section 3 and thus not an objective of ACTN. Of course, an
> > ETSI MANO orchestrator, or another service fulfillment system, can provide
> this functionality.
> >
> > Virtualization/Abstraction function; (ii) Virtual Service Coordination
> > function. In (i), we have this clause: "This function includes network
> > path computation based on customer service connectivity request
> > constraints, path computation based on the global network-wide
> > abstracted topology, and the creation of an abstracted view of network
> > slices allocated to each customer. These operations depend on
> > customer-specific network objective functions and customer traffic
> > profiles. And in (ii), we have "This function translates customer
> > service-related information into virtual network service operations in
> > YOUNG>> In regard to your comment on "an ETSI MANO orchestrator or
> > YOUNG>> other
> > service fulfillment system can provide this functionality", can they
> > perform PCE function with multiple constraints/objectives, where do
> > they get TE/abstraction information from, can they perform
> > multi-destination path computation? If they do, then they are not
> > different from ACTN MDSC functionality. But I don't think so.
> >
> > > understand the use case, it can equally be used for a
> > > non-virtualized BNG if one wants to decide dynamically which out of
> > > a set of BNGs one would want to use. If I miss something here,
> > > please explain why the use
> > caase is limited to vBNGs.
> > >
> > > YOUNG>> OK. How about:
> > >
> > physical or virtual, so why to bother about mentioning both? Anyway,
> > I'd focus this section on examples for "software applications" that
> > can really leverage dynamic TE engineering as enabled by ACTN. The
> > assumption that firewalls and BNGs will be the most important drivers
> > for ACTN deployment is a bit interesting, but, sure, it is not impossible.
> >
> > YOUNG>> Where did you get the idea that firewalls and BNGs will be
> > YOUNG>> most
> > important drivers for ACTN deployment? As I said before, this is an
> > enhanced function of ACTN but not necessarily the main driver.
> >
> > > > Page 23:
> > > >
> > > > 6.1. End Point Selection
> > > >
> > > > [MS] This problem can be solved without the ACTN framework. Why
> > > > does this document not reference RFC 7971, in particular Section 6.1?
> > > >
> > > > YOUNG>> RFC 7971 to me has a very different scope than ACTN.
> > > > YOUNG>> Again, as
> > > > mentioned before, VNF is a constraint to the TE connectivity in
> > > > ACTN
> > > context.
> > > > We are not talking about the solution, but the applicability of
> > > > VNF as ACTN TE constraints in this section. That is all!@
> > >
> > > send the delay info to customer in ACTN since the customer is the
> > > one who asks the ACTN MDSC to provision the minimum delay path and
> > > set up such connectivity in the network. I think you are mixing up
> > > the two different contexts and assumptions.
> >
> > [MS3] No, I do not believe I am mixing up different contexts. I focus
> > on the case in which an ETSI MANO orchestrator wants to decide which
> > data center to pick and therefore asks the MDSC about the optimum
> > end-to-end path properties between the different data centers,
> > possibly for a new connectivity service to be set up. This is the use
> > case explained in RFC 7971. In that case, an MDSC hypothetically
> > supporting ALTO would be sufficient for providing said ETSI MANO
> > orchestrator the information what is needed according to the wording
> > currently in the I-D. Of course, ALTO only enables the MANO
> > orchestrator to pick the right data center, and a second API will be
> > needed for actually requesting the connectivity. That second service
> > fulfillment API could e.g. the IETF L3SM or L2SM YANG model. They are
> > not mentioned in RFC 7971 since they did not exist when RFC 7971 was
> written. But it seems to me that ALTO + L2SM or L3SM are sufficient for
> realizing the use case in this Section.
> > BTW, we have
> >   actually implemented exactly this use case in 2012. And we didn't
> > need any VNF-awareness in what ACTN calls MDSC.
> >
> > [MS3] But my point is not about ALTO. Obviously one can provide the
> > same information also e.g. with the TEAS YANG models. My point is that
> > the use case doesn't clearly describe why any special support in ACTN
> > is needed. As I said, an implementation without VNF-awareness seems
> possible.
> >
> > other VN service request/instantiation model. We have no bearing with
> > ALTO either. In ACTN architecture, CNC (Data Center
> > Controller/Orchestrator as one type of CNC) may request the MDSC the
> > underlying VN or connectivity information so that it would make the
> > decision as to which data center may be chosen; then ask service
> > provisioning request to the MDSC. Another way is the CNC that provides
> > VNF/NF/SF information to the MDSC and let MDSC decide and provision
> > the best choice VN/connectivity with VNF/NF/SC constraints. It is a policy
> decision between CNC and MDSC. ACTN supports both cases.
> >
> > > > provider" (the term should be replaced by ACTN terminology) only
> > > > has to know the properties between the endpoints (e.g., delay) but
> > > > not the path
> > > > YOUNG>> ALTO is addressing a different issue than what the text
> > > > YOUNG>> 6.1 is
> > > saying.
> > > what "VNF-aware" TE connectivity really implies (and, again, why it
> > > is specific to VNF and not applicable to physical network functions).
> > > YOUNG>> Again this is a recurring issue around VNF/NF. ACTN deals
> > > YOUNG>> with VNF-,
> > > NF-, SF- aware TE connectivity. Would changes from VNF to VNF/NF
> > > make you happy?
> >
> > [MS3] My concern is not about terminology in this case. I would like
> > to explicitly understand what extensions are needed e.g. in a PCE and
> > the PCEP protocol for that "awareness". Please add an example how a
> > PCE would calculate the optimum path with that "awareness" and what
> > parameters it needs for that.
> >
> > YOUNG>> As said before, we are not talking about PCEP here to carry
> > YOUNG>> these
> > constraints. These information will come over CMI (CNC-MDSC) via a
> > data model.
> >
> > > [MS2] I look forward for a clear description of this. I wonder of
> > > the MDSC would be able to compute paths that take into account VNFs
> > > as
> > "constraints"
> > > implements NFV MANO orchestration capabilities? If not, how does
> > > MDSC understand the non-TE constraints?
> > >
> > > information from other entities such as Data Center Operator/ or
> > > even NFV-MANO both of which can be regarded as a CNC in ACTN
> architecture.
> >
> > [MS3] So, as a result of this use case, do you suggest that an CMI
> > interface standardized in the IETF TEAS working group would
> > standardize NFV MANO specific attributes?
> >
> > [MS3] If so, I think we have to have a discussion about the term
> > "general applicability" in the TEAS charter wording
> > "Traffic-engineering architectures for generic applicability across packet and
> non-packet networks".
> >
> > YOUNG>> TE is a capability shared across packet and non-packet already
> > YOUNG>> in its
> > > > what happens if there is not enough compute or storage resources
> > > > at that endpoint? I am not sure if that workflow is what actual
> > > > NFV systems would do. Is there running code for what is described
> > > > here, or is this just speculation? The more straightforward
> > > > workflow is that the VNF provider queries the network properties,
> > > > picks the best endpoint that also fulfills the non-networking
> > > > constraints (compute, storage, etc.), and then asks ACTN to
> > > > provide the connectivity. That seems doable with the vanilla ACTN
> > > > functionality. For that workflow, Section 6.1 is not needed
> > > at all.
> > > >
> > > identifies where to instantiate a VM. I try to understand if the
> > > MSDC would realize NFV MANO functionality for realizing what is
> > > described here, which may not be the intention of the authors but
> > > then I think the wording can be changed accordingly.
> > >
> > > is possible, but here this section describes the delegated policy
> > > where MDSC
> > is allowed to choose the best path.
> >
> > [MS3] Thanks for the explanation. This wording makes this use case
> > clearer. I think this describes a relatively generic "anycast"
> > connectivity service request that has nothing to do with NFV. It can
> > equally apply e.g. to certain dual- homing scenarios, right? So maybe
> > it should be discussed in the context of dual-homing.
> >
> > YOUNG>> Yes. Multi-destination is not same as dual homing. Destination
> > YOUNG>> can
> > > [MS2] Section 6 in the current form is very confusing. Given that
> > > the intention of all sections is very unclear, it is difficult for
> > > me to suggest how to improve the wording. Thus, just removing the
> > > whole section seems the simplest option but I am open to better
> suggestions.
> > >
> > [MS3] Given the explanations of the use cases in this discussion, I am
> > even more convinces that Section 6 has to be entirely removed from the
> document.
> > specific standardization of attributes for service
> > provisioning/fulfillment of network/service functions, such as the
> > standardization of NFV MANO-specific attributes in the CMI interface.
> > To me, this standardization is not in scope of the current TEAS charter.
> >
> > YOUNG>> I disagree with this again. No you still misunderstand the
> > YOUNG>> intention
> > here. As discussed, let me make it clear: we have no intention of
> > standardizing NFV MANO specific attributes (I don't even know what they
> are) in the CMI.
> >
> > Michael
> >

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 10 Jan 2017 14:44:12 +0000

Daniele,

But customer cannot just say "connect me to a firewall", rather "connect me to a firewall with certain characteristics/properties, configured in a certain way, etc.". So, unless you make sure that several (physical or virtual) firewalls are identical twins, you cannot decouple the desired firewall from its location, right?

Igor

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2017 9:19 AM
To: Igor Bryskin; Leeyoung; Scharf, Michael (Nokia - DE)
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Igor,

Cheers
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Jan 2017 14:51:35 +0000

That's perfectly right!

Only the locations with an available firewall meeting the characteristics/properties will be considered. 

In addition to that 2 types of characteristics/properties will be considered:
1. The characteristics of the firewall itself (or any other function)
2. The characteristics of the paths between the customer premise and the firewalls.

If for example the request is to reach a firewall with given characteristics and with a max delay of 50 ms, and you have firewalls available on sites A, B, C, D it could happen that the firewall on D is discarded because it doesn't meet the requested characteristics (against the firewall) and the firewall on C is discarded because the path towards C does not meet the characteristics against the path (50 ms) and only A and B considered.

Cheers
Daniele  

> From: Teas [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: martedì 10 gennaio 2017 15:44
> But customer cannot just say "connect me to a firewall", rather "connect me to
> a firewall with certain characteristics/properties, configured in a certain way,
> etc.". So, unless you make sure that several (physical or virtual) firewalls are
> identical twins, you cannot decouple the desired firewall from its location,
> right?
> 
> Igor
> 
> The customer could ask for connectivity from A to B and do whatever he wants
> with the traffic received on B (and vice versa), like e.g. a L3VPN.
> OR
> The customer can ask for a function applied to the traffic generated from A
> and directed to whatever destination. IN that case the traffic goes through B
> (or C or D...) where it can be terminated by the function or pass through and
> be treated by the function (e.g. firewall, parental control...etc).
> 
> Cheers
> Daniele
> 
> > What is the point of connecting location A to location B other than to
> > connect a set of functions on A to set of functions on B?
> >
> > Igor
> >
> >
> >
> > ACTN is about providing connectivity. The request for such
> > connectivity can be received in two different shapes:
> >
> > 1. Connectivity between A and B (or more points, physical or virtual)-
> > This is what we refer to as "Connectivity Services". The term "service
> > aware" is used to indicate the fact that constraints can be defined
> > against a service and then need to be translated to the underlay
> > connectivity (VN, tunnels, whatever)
> >
> > 2. A "FUNCTION" offered to a site connected to point A - This is what
> > we refer to as "NFV Services". What ACTN provides is again
> > connectivity between two points, A and B, but this time B is not
> > specified. Instead of B we have a list of
> > "FUNCTION" for his site A and doesn't care where this function is
> > implemented (physically or virtually). If you don't like the term VNF
> > we can find a better term...application? Function? Whatever? But that is the
> concept.
> >
> > Daniele
> >
> > > > 1/ If a use case is applicable also to network forwarding
> > > > functions that not separated from hardware (e.g., a PNF), I
> > > > believe the term "NFV" is
> > > misleading.
> > > > YOUNG>> OK. Some of them are better termed as "service function".
> > > > YOUNG>> We can
> > > > 2/ If a use case is also applicable to software not offering
> > > > network functions (e.g., non-telecommunication software) or any
> > > > application that can run in a datacenter (e.g., in a VM), the term
> > > > "NFV" is misleading and should be avoided. I would be fine with using
> e.g.
> > > [MS3] The better term would actually be just "software application"
> > > or "data center application", but as the document seems to define
> > > > [MS2] Note that the functions "security function like a firewall,
> > > > a traffic optimizer, and the provisioning of storage or
> > > > computation capacity" can all be provided also as physical network
> function.
> > > > that case, again, the "customer does not care whether the service
> > > > is implemented in one physical box or another physical box". In a
> > > > may perhaps be advanced service chaining use cases, but not NFV.
> > > > If I miss something here, please improve the wording to make clear
> > > > why what matters to ACTN only applies to VNFs running in an NFV
> > > > information associated with these functions to determine the
> > > > optimal end-to-end path subject to meeting these resource constraints.
> > >
> > > compute or storage resource information to the PCEP protocol, in
> > > case that e.g. the PNC uses a PCE for optimal path computation? I do
> > > *not* believe that this is what ACTN should do.
> > >
> > > think you mixed up PCE function and PCEP. Here I meant PCE function
> > > in ACTN, not PCEP in particular. The MDSC would gather different
> > > information from different means to compute end-to-end path subject
> > > to these constraints. The MDSC may get TE information from the MPI
> > > either via YANG model or PCEP/BGP while it may need to get other
> > > data center application information over the CMI from data center
> > > > chaining as it can also create TE-enabled network function
> > > > (virtual or physical).
> > >
> > > TE-enabled network function"? I may miss something, but to me
> > > "create TE-enabled network function" is not in scope of the four
> > > functions defined in Section 3 and thus not an objective of ACTN. Of
> > > course, an ETSI MANO orchestrator, or another service fulfillment
> > > system, can provide
> > this functionality.
> > >
> > > Virtualization/Abstraction function; (ii) Virtual Service
> > > Coordination function. In (i), we have this clause: "This function
> > > includes network path computation based on customer service
> > > connectivity request constraints, path computation based on the
> > > global network-wide abstracted topology, and the creation of an
> > > operations depend on customer-specific network objective functions
> > > and customer traffic profiles. And in (ii), we have "This function
> > > translates customer service-related information into virtual network
> > > service operations in order to seamlessly operate virtual networks
> > > while meeting a customer's
> > service requirements."
> > >
> > > > [MS2] Are you saying that the endpoint mobility use case is e.g.
> > > > not applicable to a BNG that does not run virtualized? As far as I
> > > > non-virtualized BNG if one wants to decide dynamically which out
> > > > of a set of BNGs one would want to use. If I miss something here,
> > > [MS3] As you comment earlier, for ACTN it doesn't matter whether it
> > > is physical or virtual, so why to bother about mentioning both?
> > > Anyway, I'd focus this section on examples for "software
> > > applications" that can really leverage dynamic TE engineering as
> > > enabled by ACTN. The assumption that firewalls and BNGs will be the
> > > most important drivers for ACTN deployment is a bit interesting, but, sure,
> it is not impossible.
> > >
> > > > minimum delay is towards DC-A, DC-B, or DC-C" can be solved by
> > > > ALTO very easily and RFC 7971 outlines how.
> > > >
> > > > YOUNG>> There in no intention to introduce ALTO in ACTN. There is
> > > > YOUNG>> no need to
> > > [MS3] No, I do not believe I am mixing up different contexts. I
> > > focus on the case in which an ETSI MANO orchestrator wants to decide
> > > which data center to pick and therefore asks the MDSC about the
> > > optimum end-to-end path properties between the different data
> > > centers, possibly for a new connectivity service to be set up. This
> > > is the use case explained in RFC 7971. In that case, an MDSC
> > > hypothetically supporting ALTO would be sufficient for providing
> > > said ETSI MANO orchestrator the information what is needed according
> > > to the wording currently in the I-D. Of course, ALTO only enables
> > > the MANO orchestrator to pick the right data center, and a second
> > > API will be needed for actually requesting the connectivity. That
> > > second service fulfillment API could e.g. the IETF L3SM or L2SM YANG
> > > model. They are not mentioned in RFC 7971 since they did not exist
> > > when RFC 7971 was
> > written. But it seems to me that ALTO + L2SM or L3SM are sufficient
> > for realizing the use case in this Section.
> > > BTW, we have
> > > same information also e.g. with the TEAS YANG models. My point is
> > > that the use case doesn't clearly describe why any special support
> > > in ACTN is needed. As I said, an implementation without
> > > VNF-awareness seems
> > possible.
> > >
> > > ETSI MANO-O. L2SM/L3SM can be supported in the CMI of ACTN as well
> > > as other VN service request/instantiation model. We have no bearing
> > > with ALTO either. In ACTN architecture, CNC (Data Center
> > > provisioning request to the MDSC. Another way is the CNC that
> > > provides VNF/NF/SF information to the MDSC and let MDSC decide and
> > > provision the best choice VN/connectivity with VNF/NF/SC
> > > constraints. It is a policy
> > > > > has to know the properties between the endpoints (e.g., delay)
> > > > > but not the path
> > > > > Here we are talking about how to provide VNF-aware TE
> > > > > connectivity in optimal way knowing where certain VNFs are
> > > > > located in its path computation. ACTN MDSC provides this connectivity
> to the CNC.
> > > >
> > > > [MS2] I don't find this explanation in Section 6.1 and I am not
> > > > sure what "VNF-aware" TE connectivity really implies (and, again,
> > > > why it is specific to VNF and not applicable to physical network functions).
> > > to explicitly understand what extensions are needed e.g. in a PCE
> > > and the PCEP protocol for that "awareness". Please add an example
> > > how a PCE would calculate the optimum path with that "awareness" and
> > > what parameters it needs for that.
> > >
> > > > > [MS] And, the fact that the problem can be solved by ALTO
> > > > > actually shows that this "endpoint selection" is not specific to VNFs at
> all.
> > > > > The same problem applies to all endpoint selection problems,
> > > > > e.g., in peer-to-peer systems, content delivery cache selection,
> > > > > replica placement in distributed databases, etc. There is no
> > > > > need to only discuss
> > > > this use case for VNFs.
> > > > >
> > > > > In ACTN, the CNC makes request TE-services with constraints to
> > > > > the MDSC and MDSC compute the optimal path and provide this to the
> CNC.
> > > >
> > > > the MDSC would be able to compute paths that take into account
> > > > VNFs as
> > > "constraints"
> > > > without understanding a lot of these VNFs and the NFV
> > > > infrastructure (e.g., whether a VNF can actually be installed in
> > > > the data center behind an ACTN access points). Are you looking for
> > > > an MDSC that implements NFV MANO orchestration capabilities? If
> > > > not, how does MDSC understand the non-TE constraints?
> > > >
> > > > YOUNG>> No. MDSC would not implement NFV MANO-O function.
> MSDC
> > > would
> > > > YOUNG>> get this
> > > YOUNG>> NO, not in particular NFV MANO, whatever data center
> > > YOUNG>> operator
> > > YOUNG>> TE is a capability shared across packet and non-packet
> > > YOUNG>> already in its
> > > > > [MS] Does this description imply a workflow that an ACTN
> > > > > component decides on behalf of the VNF provider which endpoint
> > > > > to use? Now, what happens if there is not enough compute or
> > > > > storage resources at that endpoint? I am not sure if that
> > > > > workflow is what actual NFV systems would do. Is there running
> > > > > code for what is described here, or is this just speculation?
> > > > > The more straightforward workflow is that the VNF provider
> > > > > queries the network properties, picks the best endpoint that
> > > > > also fulfills the non-networking constraints (compute, storage,
> > > > > etc.), and then asks ACTN to provide the connectivity. That
> > > > > seems doable with the vanilla ACTN functionality. For that
> > > > > workflow, Section 6.1 is not needed
> > > > at all.
> > > > >
> > > > [MS2] I have raised a very specific question on what is described
> > > > in this paragraph and specifically the wording "when the end point
> > > > is identified", which in the current form could imply that the
> > > > MDSC identifies where to instantiate a VM. I try to understand if
> > > > the MSDC would realize NFV MANO functionality for realizing what
> > > > is described here, which may not be the intention of the authors
> > > > but then I think the wording can be changed accordingly.
> > > >
> > > > YOUNG>> This refers to multi-destination case where there could be
> > > > YOUNG>> a number of
> > > > destination endpoint of a certain application. Customer can
> > > > provide this information to MDSC and let the MDSC choose the best
> > > > e2e path (selecting the optimal destination endpoint) via policy
> > > > (delegation policy). Other choice can be that MDSC provides all
> > > > possible TE-path information and let the customer choose the
> > > > optimal path. Either one is possible, but here this section
> > > equally apply e.g. to certain dual- homing scenarios, right? So
> > > maybe it should be discussed in the context of dual-homing.
> > >
> > > YOUNG>> Yes. Multi-destination is not same as dual homing.
> > > YOUNG>> Destination can
> > > be a single-homing but we can have many of them. I don't think
> > > multi- destination should be discussed in the context of dual-homing.
> > >
> > > > > think it can be removed entirely as it discussed issues not
> > > > > specific to
> > ACTN.
> > > > >
> > > [MS3] Given the explanations of the use cases in this discussion, I
> > > am even more convinces that Section 6 has to be entirely removed
> > > from the
> > document.
> > > Unless I miss something, these use cases seem to be about
> > > technology- specific standardization of attributes for service

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 10 Jan 2017 15:02:30 +0000

By firewalls-twins I mean (among other things) firewalls with identically configured access lists, rules, etc. How does ACTN know/ensure that?

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2017 9:52 AM
To: Igor Bryskin; Leeyoung; Scharf, Michael (Nokia - DE)
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

That's perfectly right!

Cheers
Daniele

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 10 Jan 2017 15:22:58 +0000

ACTN doesn't know that, it only deals with the second type of constraints (the ones related to how to reach the GOOD firewalls).

The orchestrator or whatever entity sits on top of the MDSC is supposed to discard the firewalls not meeting the constraints. 

Please note that there will be cases (like the ones you described) in which an existing function will be re-used (and hence check for constraints against the firewall itself) but also cases in which a brand new function will be deployed interacting with tools dedicated to the function deployment. Such function could also be fully dedicated to that service and not shared with others.

Cheers
Daniele  

> Sent: martedì 10 gennaio 2017 16:03
> By firewalls-twins I mean (among other things) firewalls with identically
> configured access lists, rules, etc. How does ACTN know/ensure that?
> 
> Only the locations with an available firewall meeting the
> characteristics/properties will be considered.
> 
> 1. The characteristics of the firewall itself (or any other function) 2. The
> characteristics of the paths between the customer premise and the firewalls.
> 
> If for example the request is to reach a firewall with given characteristics and
> with a max delay of 50 ms, and you have firewalls available on sites A, B, C, D it
> could happen that the firewall on D is discarded because it doesn't meet the
> requested characteristics (against the firewall) and the firewall on C is
> discarded because the path towards C does not meet the characteristics
> against the path (50 ms) and only A and B considered.
> 
> Cheers
> Daniele
> 
> > But customer cannot just say "connect me to a firewall", rather
> > "connect me to a firewall with certain characteristics/properties,
> > configured in a certain way, etc.". So, unless you make sure that
> > several (physical or virtual) firewalls are identical twins, you
> > cannot decouple the desired firewall from its location, right?
> >
> > Igor
> >
> > The customer could ask for connectivity from A to B and do whatever he
> > wants with the traffic received on B (and vice versa), like e.g. a L3VPN.
> > OR
> > The customer can ask for a function applied to the traffic generated
> > from A and directed to whatever destination. IN that case the traffic
> > goes through B (or C or D...) where it can be terminated by the
> > function or pass through and be treated by the function (e.g. firewall,
> parental control...etc).
> >
> > Cheers
> > Daniele
> >
> > > What is the point of connecting location A to location B other than
> > > to connect a set of functions on A to set of functions on B?
> > >
> > > Igor
> > >
> > >
> > >
> > > 1. Connectivity between A and B (or more points, physical or
> > > virtual)- This is what we refer to as "Connectivity Services". The
> > > term "service aware" is used to indicate the fact that constraints
> > > can be defined against a service and then need to be translated to
> > > the underlay connectivity (VN, tunnels, whatever)
> > >
> > > 2. A "FUNCTION" offered to a site connected to point A - This is
> > > what we refer to as "NFV Services". What ACTN provides is again
> > > (typically) data centers, because the customer was asking for a
> > > given "FUNCTION" for his site A and doesn't care where this function
> > > is implemented (physically or virtually). If you don't like the term
> > > VNF we can find a better term...application? Function? Whatever? But
> > > that is the
> > concept.
> > >
> > > Daniele
> > >
> > > > > application that can run in a datacenter (e.g., in a VM), the
> > > > > term "NFV" is misleading and should be avoided. I would be fine
> > > > > with using
> > e.g.
> > > > "application" with a very special meaning (which I believe should
> > > > be re-considered - see my initial
> > > > e-mail) I was looking for something else. I don't insist in any
> > > > term as long as it is clear that ACTN applies to any IT
> > > > application, not to
> > > telecommunication only.
> > > > you are referring to. S/W or DC application or cloud application
> > > > are more confusing to me.
> > > >
> > > > > [MS2] Note that the functions "security function like a
> > > > > firewall, a traffic optimizer, and the provisioning of storage
> > > > > or computation capacity" can all be provided also as physical
> > > > > network
> > function.
> > > > > traffic optimizers at different places in the network, and
> > > > > during service setup it can be decided which physical function
> > > > > to use. In that case, again, the "customer does not care whether
> > > > > the service is implemented in one physical box or another
> > > > > physical box". In a
> > > > > nutshell: Nothing what is written here seems specific to NFV.
> > > > > This may perhaps be advanced service chaining use cases, but not NFV.
> > > > > If I miss something here, please improve the wording to make
> > > > > clear why what matters to ACTN only applies to VNFs running in
> > > > > an NFV infrastructure and cannot apply to physical
> > > > > YOUNG>> in ACTN, there is no distinction if functions (service
> > > > > YOUNG>> or
> > > > > YOUNG>> network) to
> > > > think you mixed up PCE function and PCEP. Here I meant PCE
> > > > function in ACTN, not PCEP in particular. The MDSC would gather
> > > > different information from different means to compute end-to-end
> > > > path subject to these constraints. The MDSC may get TE information
> > > > from the MPI either via YANG model or PCEP/BGP while it may need
> > > > to get other data center application information over the CMI from
> > > > data center controllers/orchestrators. I don't envision nor have
> > > > plan to add virtual
> > > > functions defined in Section 3 and thus not an objective of ACTN.
> > > > Of course, an ETSI MANO orchestrator, or another service
> > > > fulfillment system, can provide
> > > this functionality.
> > > >
> > > > abstracted view of network slices allocated to each customer.
> > > > These operations depend on customer-specific network objective
> > > > functions and customer traffic profiles. And in (ii), we have
> > > > "This function translates customer service-related information
> > > > into virtual network service operations in order to seamlessly
> > > > operate virtual networks while meeting a customer's
> > > service requirements."
> > > >
> > > > service fulfillment system can provide this functionality", can
> > > > they perform PCE function with multiple constraints/objectives,
> > > > where do they get TE/abstraction information from, can they
> > > > perform multi-destination path computation? If they do, then they
> > > > are not different from ACTN MDSC functionality. But I don't think so.
> > > >
> > > > > not applicable to a BNG that does not run virtualized? As far as
> > > > > I understand the use case, it can equally be used for a
> > > > > of a set of BNGs one would want to use. If I miss something
> > > > > here, please explain why the use
> > > > [MS3] As you comment earlier, for ACTN it doesn't matter whether
> > > > it is physical or virtual, so why to bother about mentioning both?
> > > > enabled by ACTN. The assumption that firewalls and BNGs will be
> > > > the most important drivers for ACTN deployment is a bit
> > > > interesting, but, sure,
> > it is not impossible.
> > > >
> > > > important drivers for ACTN deployment? As I said before, this is
> > > > an enhanced function of ACTN but not necessarily the main driver.
> > > >
> > > > > > Page 23:
> > > > > >
> > > > > > 6.1. End Point Selection
> > > > > >
> > > > > >    the delay between AP1 and AP2, but the customer doesn't
> > > > > > know if
> > the
> > > > > > [MS] This problem can be solved without the ACTN framework.
> > > > > > Why does this document not reference RFC 7971, in particular Section
> 6.1?
> > > > > >
> > > > > > mentioned before, VNF is a constraint to the TE connectivity
> > > > > > in ACTN
> > > > > context.
> > > > > > We are not talking about the solution, but the applicability
> > > > > > of VNF as ACTN TE constraints in this section. That is all!@
> > > > >
> > > > > [MS2] Then this sentence need to rephrased to make the
> > > > > difference clear. The statement "the customer doesn't know if
> > > > > the path with minimum delay is towards DC-A, DC-B, or DC-C" can
> > > > > be solved by ALTO very easily and RFC 7971 outlines how.
> > > > >
> > > > > YOUNG>> There in no intention to introduce ALTO in ACTN. There
> > > > > YOUNG>> is no need to
> > > > > send the delay info to customer in ACTN since the customer is
> > > > > the one who asks the ACTN MDSC to provision the minimum delay
> > > > > path and set up such connectivity in the network. I think you
> > > > > are mixing up the two different contexts and assumptions.
> > > >
> > > > focus on the case in which an ETSI MANO orchestrator wants to
> > > > decide which data center to pick and therefore asks the MDSC about
> > > > the optimum end-to-end path properties between the different data
> > > > centers, possibly for a new connectivity service to be set up.
> > > > This is the use case explained in RFC 7971. In that case, an MDSC
> > > > said ETSI MANO orchestrator the information what is needed
> > > > according to the wording currently in the I-D. Of course, ALTO
> > > > only enables the MANO orchestrator to pick the right data center,
> > > > and a second API will be needed for actually requesting the
> > > > connectivity. That second service fulfillment API could e.g. the
> > > > IETF L3SM or L2SM YANG model. They are not mentioned in RFC 7971
> > > > since they did not exist when RFC 7971 was
> > > >   actually implemented exactly this use case in 2012. And we
> > > > didn't need any VNF-awareness in what ACTN calls MDSC.
> > > >
> > > > [MS3] But my point is not about ALTO. Obviously one can provide
> > > > the same information also e.g. with the TEAS YANG models. My point
> > > > is that the use case doesn't clearly describe why any special
> > > > support in ACTN is needed. As I said, an implementation without
> > > > VNF-awareness seems
> > > possible.
> > > >
> > > > YOUNG>> ACTN architecture does not assume anything about nor
> > > > YOUNG>> depend
> > > on
> > > > as other VN service request/instantiation model. We have no
> > > > bearing with ALTO either. In ACTN architecture, CNC (Data Center
> > > > Controller/Orchestrator as one type of CNC) may request the MDSC
> > > > the underlying VN or connectivity information so that it would
> > > > make the decision as to which data center may be chosen; then ask
> > > > service provisioning request to the MDSC. Another way is the CNC
> > > > that provides VNF/NF/SF information to the MDSC and let MDSC
> > > > decide and provision the best choice VN/connectivity with
> > > > VNF/NF/SC constraints. It is a policy
> > > > > > provider" (the term should be replaced by ACTN terminology)
> > > > > > only has to know the properties between the endpoints (e.g.,
> > > > > > delay) but not the path
> > > > > > YOUNG>> ALTO is addressing a different issue than what the
> > > > > > YOUNG>> text
> > > > > > YOUNG>> 6.1 is
> > > > > saying.
> > > > > sure what "VNF-aware" TE connectivity really implies (and,
> > > > > again, why it is specific to VNF and not applicable to physical network
> functions).
> > > > > YOUNG>> Again this is a recurring issue around VNF/NF. ACTN
> > > > > YOUNG>> deals with VNF-,
> > > > [MS3] My concern is not about terminology in this case. I would
> > > > like to explicitly understand what extensions are needed e.g. in a
> > > > PCE and the PCEP protocol for that "awareness". Please add an
> > > > example how a PCE would calculate the optimum path with that
> > > > "awareness" and what parameters it needs for that.
> > > >
> > > > YOUNG>> As said before, we are not talking about PCEP here to
> > > > YOUNG>> carry these
> > > > > > e.g., in peer-to-peer systems, content delivery cache
> > > > > > selection, replica placement in distributed databases, etc.
> > > > > > There is no need to only discuss
> > > > > this use case for VNFs.
> > > > > >
> > > > > > YOUNG>> I see ALTO as generic mechanism to the client so that
> > > > > > YOUNG>> it would select
> > > > > [MS2] I look forward for a clear description of this. I wonder
> > > > > of the MDSC would be able to compute paths that take into
> > > > > account VNFs as
> > > > "constraints"
> > > > > the data center behind an ACTN access points). Are you looking
> > > > > for an MDSC that implements NFV MANO orchestration capabilities?
> > > > > If not, how does MDSC understand the non-TE constraints?
> > > > >
> > > > provides for their dynamic mobility/connectivity can be a part of
> > > > CMI
> > model.
> > > >
> > > > definition. Not sure what you are trying to do here by bringing
> > > > TEAS
> > charter.
> > > >
> > > > > > also fulfills the non-networking constraints (compute,
> > > > > > storage, etc.), and then asks ACTN to provide the
> > > > > > connectivity. That seems doable with the vanilla ACTN
> > > > > [MS2] I have raised a very specific question on what is
> > > > > described in this paragraph and specifically the wording "when
> > > > > the end point is identified", which in the current form could
> > > > > imply that the MDSC identifies where to instantiate a VM. I try
> > > > > to understand if the MSDC would realize NFV MANO functionality
> > > > > for realizing what is described here, which may not be the
> > > > > YOUNG>> This refers to multi-destination case where there could
> > > > > YOUNG>> be a number of
> > > > > provide this information to MDSC and let the MDSC choose the
> > > > > best e2e path (selecting the optimal destination endpoint) via
> > > > > policy (delegation policy). Other choice can be that MDSC
> > > > > provides all possible TE-path information and let the customer
> > > > > choose the optimal path. Either one is possible, but here this
> > > > > section describes the delegated policy where MDSC
> > > > connectivity service request that has nothing to do with NFV. It
> > > > can equally apply e.g. to certain dual- homing scenarios, right?
> > > > So maybe it should be discussed in the context of dual-homing.
> > > >
> > > > > > [MS] Bottom line question: Why is Section 6 in this document?
> > > > > > I think it can be removed entirely as it discussed issues not
> > > > > > specific to
> > > ACTN.
> > > > > >
> > > > > [MS2] Section 6 in the current form is very confusing. Given
> > > > > that the intention of all sections is very unclear, it is
> > > > > difficult for me to suggest how to improve the wording. Thus,
> > > > > just removing the whole section seems the simplest option but I
> > > > > am open to better
> > > suggestions.
> > > > >
> > > > > YOUNG>> As we agreed on the use of the term VNF, we will make
> > > > > YOUNG>> come
> > > > > clarifications. Thanks.
> > > >
> > > > [MS3] Given the explanations of the use cases in this discussion,
> > > > I am even more convinces that Section 6 has to be entirely removed
> > > > from the
> > > document.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 10 Jan 2017 22:51:24 +0000

> to indicate the fact that constraints can be defined against a service and
> then need to be translated to the underlay connectivity (VN, tunnels,
> whatever)

The term "service" is used in very different context in the IETF. In my understanding, in a TE network basically all connectivity (virtual network) setup is governed by some form of constraints. So the existence of "constraints" doesn't imply anything special in ACTN. As a result, I don't understand what is the difference is between "connectivity between A and B" and "service-aware connectivity between A and B".

For this sort of ambiguous terms, it would help to add examples that make the meaning clear, and add a rigorous definition of the terms. Albeit I actually suggest to avoid the term "service-aware" given that it can easily be misunderstood.
  
> points, A and B, but this time B is not specified. Instead of B we have a list
> of (typically) data centers, because the customer was asking for a given

According to Section 1.1 in the I-D, ACTN provides connectivity between Access Points (APs). So, IMHO the term is "Access Point" as defined in Section 1.1 (or, alternatively, VNAP). 

I understand from this e-mail discussion that one could request a connectivity service (virtual network) e.g between sets of source access points {s1, s2, s3} and destination access points {d1, d2, d3} and leave it up to the network (e.g. MDSC) to decide which source and destination access points to pick to actually set up the connectivity service (virtual network). This explanation seems to me a traffic engineering (TE) use case in scope of the TEAS charter, albeit I am not aware of commercial products for abstraction and control of transport networks that would offer this sort of specific workflow, specifically since NFV infrastructures don't require this specific logic, to the best of my knowledge of running code (e.g., OpenStack).

Of course, in this hypothetical use case it would inherently be up to systems entirely outside the scope of ACTN standardization to decide which sets of access points to provide as a set of access points to ACTN (i.e. MDSC). For instance, a system outside the scope of ACTN standardization could know that the networks behind access points {d1, d2, d3} have a certain capability, while e.g. access points {d4, d5} don't have said capability. ACTN components don't need any understanding of the difference between {d1, d2, d3} and {d4, d5}. It is sufficient to know that only the set of access points {d1, d2, d3} have to be considered for setting up connectivity services with TE constraints.

So, to me, all what is needed to describe the use cases under discussion is a "set of access points".
 
To make the long story short: What I understand from this e-mail thread is that there is a possible use case that can be described by the term "network-based selection within sets of access points". This use case is more advanced than the use cases in Section 4 and 5 of draft-ietf-teas-actn-framework-02, and they could be mentioned if needed e.g. as an example for further research.

With this focus on access points as endpoints of the connectivity services offered by ACTN, the terms "NFV", "VNF", "network function", "service function chaining", etc. can be entirely removed from the document. And the focus on the terminology used in Section 1.1 also ensures that the use cases are (a) described as a generic TE function only, and (b) that they is equally applicable both to packet and non-packet transport networks.

Michael

> > > that not separated from hardware (e.g., a PNF), I believe the term "NFV"
> is
> > misleading.
> function. In
> > > is possible, but here this section describes the delegated policy where
> MDSC
> standardizing

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Jan 2017 18:16:59 +0000

Something that seems to be missing from this work are the concepts of 
isolation and latency
which seem to be requirements for services of the type described in this 
document.

We latency has two components, the physical latency of the path due to 
distance, and
latency due to waiting for other packets. Clearly optimizing the paths 
traffic takes
is the key to addressing the delay to physical path length, and 
considering congestion
effects, bandwidth management and the choice of bearer technology impact 
the second.

I did not see any mention of latency in the abstract interface to the 
SDN system and
yet to address that emergent requirement it needs to be there.

Secondly I understand that isolation is an emergent requirement. 
Isolation can
take many forms. The most common is the need to avoid traffic leakage, 
but it
can also include the need to avoid control plane interactions whereby 
the demands
of one service impact another, and data plane interaction where a heavy 
demand
by one virtual service spills over into latency effects in another, at 
least in
classic network layer technologies such as MPLS-Tx.

- Stewart

---

From: Leeyoung <[email-masked]>
Date: Fri, 13 Jan 2017 19:42:02 +0000

Hi Stewart,

Thanks for your comments on the missing components which you pointed out on isolation and latency.

Theirs is a parallel ACTN requirement draft that addresses all ACTN requirements including isolation/latency. Please see: https://tools.ietf.org/html/draft-ietf-teas-actn-requirements-04

In Page 6, we have the following which is the principle of isolation. 

6. Requirement 6: VN Confidentiality/Security

        - A VN customer must not be able to control another customer's
           virtual network
        - A VN customer must not see any routing information (e.g. IGP
           database, TE database) relating to another customer's
           virtual network

You can also find latency requirement in the draft. 

Thanks.
Young
-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, January 13, 2017 12:17 PM
To: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Something that seems to be missing from this work are the concepts of isolation and latency which seem to be requirements for services of the type described in this document.

We latency has two components, the physical latency of the path due to distance, and latency due to waiting for other packets. Clearly optimizing the paths traffic takes is the key to addressing the delay to physical path length, and considering congestion effects, bandwidth management and the choice of bearer technology impact the second.

I did not see any mention of latency in the abstract interface to the SDN system and yet to address that emergent requirement it needs to be there.

Secondly I understand that isolation is an emergent requirement. 
Isolation can
take many forms. The most common is the need to avoid traffic leakage, but it can also include the need to avoid control plane interactions whereby the demands of one service impact another, and data plane interaction where a heavy demand by one virtual service spills over into latency effects in another, at least in classic network layer technologies such as MPLS-Tx.

- Stewart

---

From: Leeyoung <[email-masked]>
Date: Mon, 23 Jan 2017 21:25:02 +0000

Hi Michael,

We thank you for providing good comments and input in this thread. Co-authors of this draft have discussions to make sure to incorporate your comments/concerns in the last week. And here's the summary of our proposal and the diff file is enclosed with a proposed revision. 

1. In Section 1.1, we rid of two terms: service-aware connectivity service and NFV services. 
2. We rid of all "orchestration" term from the document. 
3. We rid of all NFV/VNF terms from the document.
4. We re-wrote Section 6 so that any NFV/VNF nuances are deleted. 
5. In Section 8, we rid of section 8.1 (which is application to CNC security implication) as you pointed out, this is not the scope of ACTN
6. In Section 3, we added a few words to make sure interfaces A and D are not in scope of ACTN:  

Old: The interfaces within the ACTN scope are B and C. 
NEW: The interfaces within the ACTN scope are B and C while interfaces A and D are out of the scope of ACTN and are only shown in Figure 5 to give a complete context of ACTN.

I believe most of your concerns/comments are incorporated in the proposed revision. Please let us know if there are still any major issues. We look forward to hearing from you soon. We'd like to submit the revision as a sable one to the WG so that the LC can proceed soon. 

Thanks & Best regards,
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2017 4:51 PM
To: Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

  
> specified. Instead of B we have a list of (typically) data centers, 
> because the customer was asking for a given "FUNCTION" for his site A 
> and doesn't care where this function is implemented (physically or 
> virtually). If you don't like the term VNF we can find a better term...application? Function? Whatever? But that is the concept.

 

Michael

> > > functions that not separated from hardware (e.g., a PNF), I believe the term "NFV"
> is
> > misleading.
> > > "NFV" is misleading and should be avoided. I would be fine with 
> > > using e.g. the term "cloud function" (or something similar) in that case.
> > >
> > "application" with
> a
> > very special meaning (which I believe should be re-considered - see 
> > my
> initial
> > as long
> as it is
> > clear that ACTN applies to any IT application, not to 
> > telecommunication
> only.
> > centers and ACTN be used to dynamically provide connectivity to 
> > them. And of course they can
> have
> > > function. And, for example, it can be perfectly possible that a 
> > > network operator runs physical servers for functions like firewall 
> > > and traffic optimizers at different places in the network, and 
> > > during service setup it can be decided which physical function to 
> > > use. In that case, again, the "customer does not care whether the 
> > > service is implemented in one physical box or another physical 
> > > box". In a nutshell: Nothing what is written here seems specific 
> > > to NFV. This may perhaps be advanced service chaining use cases, 
> > > but not NFV. If I miss something here, please improve the wording 
> > > to make clear why what matters to ACTN only applies to VNFs 
> > > running in an NFV infrastructure and cannot apply to
> physical
> > case that e.g. the
> PNC
> > uses a PCE for optimal path computation? I do *not* believe that 
> > this is
> what
> > ACTN should do.
> >
> > controllers/orchestrators. I don't envision
> nor
> > functions defined in Section 3
> and
> > thus not an objective of ACTN. Of course, an ETSI MANO orchestrator, 
> > or another service fulfillment system, can provide this functionality.
> >
> > Coordination
> > (i), we have this clause: "This function includes network path 
> > computation based on customer service connectivity request 
> > abstracted topology, and the creation of an abstracted view of 
> > network slices allocated to each customer. These operations depend 
> > on customer-specific network objective functions and customer 
> > traffic profiles. And in (ii), we have "This function translates 
> > customer service-related information into virtual network service 
> > operations
> in
> > order to seamlessly operate virtual networks while meeting a 
> > customer's service requirements."
> >
> > perform
> PCE
> > TE/abstraction information from, can they perform multi-destination 
> > path computation? If they do, then they are not different from ACTN 
> > MDSC functionality. But I don't think so.
> >
> > Anyway, I'd
> focus
> > dynamic TE engineering as enabled by ACTN. The assumption that 
> > firewalls and BNGs will be the most important drivers for ACTN 
> > deployment is a bit interesting, but, sure, it is not impossible.
> >
> > centers, possibly for a new
> connectivity
> > service to be set up. This is the use case explained in RFC 7971. In 
> > that
> case, an
> > MDSC hypothetically supporting ALTO would be sufficient for 
> > providing said ETSI MANO orchestrator the information what is needed 
> > according to the wording currently in the I-D. Of course, ALTO only 
> > enables the MANO orchestrator to pick the right data center, and a 
> > second API will be needed
> for
> > actually requesting the connectivity. That second service 
> > fulfillment API
> could
> > e.g. the IETF L3SM or L2SM YANG model. They are not mentioned in RFC 
> > 7971 since they did not exist when RFC 7971 was written. But it 
> > seems to me that ALTO + L2SM or L3SM are sufficient for realizing 
> > the use case in this
> Section.
> > BTW, we have
> > that the use
> case
> > doesn't clearly describe why any special support in ACTN is needed. 
> > As I
> said,
> > YOUNG>> ACTN architecture does not assume anything about nor depend 
> > YOUNG>> on
> > Controller/Orchestrator as
> one
> > information so that it would make the decision as to which data 
> > center may
> be
> > chosen; then ask service provisioning request to the MDSC. Another 
> > way is
> the
> > CNC that provides VNF/NF/SF information to the MDSC and let MDSC 
> > decide and provision the best choice VN/connectivity with VNF/NF/SC 
> > constraints. It is a policy decision between CNC and MDSC. ACTN supports both cases.
> >
> > > > located in its path computation. ACTN MDSC provides this connectivity to the CNC.
> > >
> > > > actually shows that this "endpoint selection" is not specific to VNFs at all.
> > > > the MDSC and MDSC compute the optimal path and provide this to the CNC.
> > >
> > > even NFV-MANO both of which can be regarded as a CNC in ACTN architecture.
> >
> > "Traffic-engineering
> architectures for
> > YOUNG>> already in
> its
> > > describes the delegated policy where
> MDSC
> > think this describes a relatively generic "anycast" connectivity 
> > service
> request
> > that has nothing to do with NFV. It can equally apply e.g. to 
> > certain dual- homing scenarios, right? So maybe it should be 
> > discussed in the context of dual-homing.
> >
> > > whole section seems the simplest option but I am open to better suggestions.
> > >
> > am even more convinces that Section 6 has to be entirely removed from the document.
> > provisioning/fulfillment
> of
> > network/service functions, such as the standardization of NFV 
> > MANO-specific attributes in the CMI interface. To me, this 
> > standardization is not in scope
> of

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 10:43:33 +0000

Hi Young,

I don't understand how many of my questions in https://www.ietf.org/mail-archive/web/teas/current/msg01861.html are addressed.

Examples (not a comprehensive list):

- Reference [ONF-ARCH]
- Term NMS/OSS
- PCE vs. PNC
- Explanation how recursiveness would actually work (specifically for multiple technologies)
- Terminology issues on "application", "forwarding state", ...

Thanks

Michael 

> From: Leeyoung [mailto:[email-masked]]
> Sent: Monday, January 23, 2017 10:25 PM
> To: Scharf, Michael (Nokia - DE)
> Cc: [email-masked]
> We thank you for providing good comments and input in this thread. Co-authors
> of this draft have discussions to make sure to incorporate your
> comments/concerns in the last week. And here's the summary of our proposal and
> the diff file is enclosed with a proposed revision.
> 
> 5. In Section 8, we rid of section 8.1 (which is application to CNC security
> implication) as you pointed out, this is not the scope of ACTN
> NEW: The interfaces within the ACTN scope are B and C while interfaces A and D
> are out of the scope of ACTN and are only shown in Figure 5 to give a complete
> context of ACTN.
> 
> I believe most of your concerns/comments are incorporated in the proposed
> revision. Please let us know if there are still any major issues. We look
> forward to hearing from you soon. We'd like to submit the revision as a sable
> one to the WG so that the LC can proceed soon.
> 
> Thanks & Best regards,
> Young

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 24 Jan 2017 13:51:06 +0000

HI Michael,

The update aims at solving the major issues, once we agree on those we can easily move to the minor ones like references and terms.
Could you start focusing on them?

Working group,
since this is a WG draft since a while and since it has already been reviewed by some of you, we'd like to hear more opinions and know whether the suggested changes are ok with everyone, don't care or someone prefers the actual version. If you speak now before the WG LC we can avoid further duplications of efforts.

Thanks
Daniele  

> From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael
> (Nokia - DE)
> Sent: martedì 24 gennaio 2017 11:44
> To: Leeyoung <[email-masked]>
> Cc: [email-masked]
> I don't understand how many of my questions in https://www.ietf.org/mail-
> archive/web/teas/current/msg01861.html are addressed.
> 
> > We thank you for providing good comments and input in this thread.
> > Co-authors of this draft have discussions to make sure to incorporate
> > your comments/concerns in the last week. And here's the summary of our
> > proposal and the diff file is enclosed with a proposed revision.
> >
> > implication) as you pointed out, this is not the scope of ACTN 6. In
> > Section 3, we added a few words to make sure interfaces A and D are
> > not in scope of ACTN:
> >
> > NEW: The interfaces within the ACTN scope are B and C while interfaces
> > A and D are out of the scope of ACTN and are only shown in Figure 5 to
> > give a complete context of ACTN.
> >
> > I believe most of your concerns/comments are incorporated in the
> > proposed revision. Please let us know if there are still any major
> > issues. We look forward to hearing from you soon. We'd like to submit
> > the revision as a sable one to the WG so that the LC can proceed soon.
> >
> > Thanks & Best regards,
> > Young
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 14:25:26 +0000

Not all of the concerns listed below are on references and terms only. Specifically, I have raised the question how recursion can work, specifically for multiple technologies (example: IP and Optical - or is this not in scope?). And I have raised the question why the document assumes that "applications" talk "directly" to the CNCs, which seems quite strange e.g. in a carrier-carrier scenario. And so on.

These are not minor issues to me. 

Michael

> Sent: Tuesday, January 24, 2017 2:51 PM
> To: Scharf, Michael (Nokia - DE); Leeyoung
> Cc: [email-masked]
> The update aims at solving the major issues, once we agree on those we can
> easily move to the minor ones like references and terms.
> since this is a WG draft since a while and since it has already been reviewed
> by some of you, we'd like to hear more opinions and know whether the suggested
> changes are ok with everyone, don't care or someone prefers the actual
> version. If you speak now before the WG LC we can avoid further duplications
> of efforts.
> 
> Thanks
> Daniele
> 
> 
> 
> > - Explanation how recursiveness would actually work (specifically for
> multiple
> > technologies)

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 24 Jan 2017 15:48:53 +0000

This is a framework document, not a solution one. To me saying that the ACTN hierarchy should allow for recursion is enough within the context of this ID. How it works is in the scope of the solution documents.
What we could discuss is what makes you think that, from an architecture perspective, recursion is not possible.

Thanks
Daniele  

> Sent: martedì 24 gennaio 2017 15:25
> <[email-masked]>
> Not all of the concerns listed below are on references and terms only.
> Specifically, I have raised the question how recursion can work, specifically for
> multiple technologies (example: IP and Optical - or is this not in scope?). And I
> have raised the question why the document assumes that "applications" talk
> "directly" to the CNCs, which seems quite strange e.g. in a carrier-carrier
> scenario. And so on.
> 
> > The update aims at solving the major issues, once we agree on those we
> > can easily move to the minor ones like references and terms.
> > since this is a WG draft since a while and since it has already been
> > reviewed by some of you, we'd like to hear more opinions and know
> > whether the suggested changes are ok with everyone, don't care or
> > someone prefers the actual version. If you speak now before the WG LC
> > we can avoid further duplications of efforts.
> >
> > Thanks
> > Daniele
> >
> >
> >
> > > From: Teas [mailto:[email-masked]] On Behalf Of Scharf,
> > > Michael (Nokia - DE)
> > > I don't understand how many of my questions in
> > > https://www.ietf.org/mail- archive/web/teas/current/msg01861.html are
> addressed.
> > >
> > > > Co-authors of this draft have discussions to make sure to
> > > > incorporate your comments/concerns in the last week. And here's
> > > > the summary of our proposal and the diff file is enclosed with a proposed
> revision.
> > > >
> > > > implication) as you pointed out, this is not the scope of ACTN 6.
> > > > In Section 3, we added a few words to make sure interfaces A and D
> > > > are not in scope of ACTN:
> > > >
> > > > NEW: The interfaces within the ACTN scope are B and C while
> > > > interfaces A and D are out of the scope of ACTN and are only shown
> > > > in Figure 5 to give a complete context of ACTN.
> > > >
> > > > issues. We look forward to hearing from you soon. We'd like to
> > > > submit the revision as a sable one to the WG so that the LC can proceed
> soon.
> > > >
> > > > Thanks & Best regards,
> > > > Young
> > >

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 16:40:11 +0000

As I wrote earlier in the thread: Let's assume that there is an MDSC dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs. Would the ACTN framework foresee that the DWDM MDSC and the MPLS-TE MDSC can be used recursively in any combination?

For what it is worth, I think I understand how reclusiveness could work if the scope of the ACTN framework is (1) limited to a single technology or protocol layer, or (2) if CMI and MPI are strictly technology-neutral. But if one of these constraints are not true, I get lost how recursion would work in reality.

Even more in general, it is not easy to understand how the ACTN framework deals with TE engineering in multi-layer networks. For instance, Figure 7 is confusing in this case. I don't think that these are questions specific to solutions.

Michael

> Sent: Tuesday, January 24, 2017 4:49 PM
> This is a framework document, not a solution one. To me saying that the ACTN
> hierarchy should allow for recursion is enough within the context of this ID.
> How it works is in the scope of the solution documents.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 24 Jan 2017 16:40:25 +0000

Hi Michael,

Can you explain what is your problem with the MDSC's recursivety?

In my mind MDSC talks down to its subordinate controllers. Whether the latter are PNCs (controllers directly managing NEs) or MDSCs in their own right (making use of subordinates of their own) the MDSC in question (top level MDSC) has no way of telling. For example, TE topologies provided by a lower hierarchy level controller to a higher level controller could be a product of merging of TE topologies catered by the former's subordinate controllers. Likewise, a TE tunnel requested by a higher level controller could be collectively provisioned by lower level controllers, with each tunnel segment further segmented by their subordinates, etc.

The described above applies to both single- and multi-layer connection oriented cs/ps TE technologies and controllers managing them (i.e. transport controllers), but is not applied IMHO to layer networks directly supporting connectionless services, such as L2 and L3 VPNs.

Cheers,
Igor   

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Tuesday, January 24, 2017 5:44 AM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Young,

- Reference [ONF-ARCH]
- Term NMS/OSS
- PCE vs. PNC

Thanks

Michael

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 24 Jan 2017 16:47:21 +0000

Why a top-level MPLS-TP controller can not use several optical controllers (one per optical network supporting MPLS network), each of which using several lower level optical controllers (each per one optical domain) ?

Igpr

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Tuesday, January 24, 2017 11:40 AM
To: Daniele Ceccarelli; Leeyoung
Cc: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Michael

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 24 Jan 2017 17:28:59 +0000

> As I wrote earlier in the thread: Let's assume that there is an MDSC dealing
> with DWDM PNCs and another one dealing with MPLS-TE PNCs. Would the
> ACTN framework foresee that the DWDM MDSC and the MPLS-TE MDSC can
> be used recursively in any combination?

Yes

> For what it is worth, I think I understand how reclusiveness could work if the
> scope of the ACTN framework is (1) limited to a single technology or protocol
> layer, or (2) if CMI and MPI are strictly technology-neutral. But if one of these
> constraints are not true, I get lost how recursion would work in reality.

ACTN is NOT limited to a single technology or protocol layer. The MPI can be technology agnostic or technology specific and I don't understand what is the problem of having an MDSC on top of that.
Regarding the CMI I'd say that it HAS to be technology agnostic, hence the technology complexity would be hidden to the parent MDSC from the child MDSCs.

BR
Daniele  

> Sent: martedì 24 gennaio 2017 17:40
> As I wrote earlier in the thread: Let's assume that there is an MDSC dealing
> with DWDM PNCs and another one dealing with MPLS-TE PNCs. Would the
> ACTN framework foresee that the DWDM MDSC and the MPLS-TE MDSC can
> be used recursively in any combination?
> 
> For what it is worth, I think I understand how reclusiveness could work if the
> scope of the ACTN framework is (1) limited to a single technology or protocol
> layer, or (2) if CMI and MPI are strictly technology-neutral. But if one of these
> constraints are not true, I get lost how recursion would work in reality.
> 
> Even more in general, it is not easy to understand how the ACTN framework
> deals with TE engineering in multi-layer networks. For instance, Figure 7 is
> confusing in this case. I don't think that these are questions specific to
> solutions.
> 
> Michael
> 
> 
> > This is a framework document, not a solution one. To me saying that
> > the ACTN hierarchy should allow for recursion is enough within the context
> of this ID.
> > What we could discuss is what makes you think that, from an
> > architecture perspective, recursion is not possible.
> >
> > Thanks
> > Daniele
> >
> > > have raised the question why the document assumes that
> > > "applications" talk "directly" to the CNCs, which seems quite
> > > strange e.g. in a carrier-carrier scenario. And so on.
> > >
> > > > The update aims at solving the major issues, once we agree on
> > > > those we can easily move to the minor ones like references and terms.
> > > > since this is a WG draft since a while and since it has already
> > > > been reviewed by some of you, we'd like to hear more opinions and
> > > > know whether the suggested changes are ok with everyone, don't
> > > > care or someone prefers the actual version. If you speak now
> > > > before the WG LC we can avoid further duplications of efforts.
> > > >
> > > > Thanks
> > > > Daniele
> > > >
> > > >
> > > >
> > > > > https://www.ietf.org/mail-
> > > > > > incorporate your comments/concerns in the last week. And
> > > > > > here's the summary of our proposal and the diff file is
> > > > > > enclosed with a
> > proposed
> > > revision.
> > > > > >
> > > > > > In Section 3, we added a few words to make sure interfaces A
> > > > > > and D are not in scope of ACTN:
> > > > > >
> > > > > > interfaces A and D are out of the scope of ACTN and are only
> > > > > > shown in Figure 5 to give a complete context of ACTN.
> > > > > >
> > > > > > I believe most of your concerns/comments are incorporated in
> > > > > > the proposed revision. Please let us know if there are still
> > > > > > any major issues. We look forward to hearing from you soon.
> > > > > > We'd like to submit the revision as a sable one to the WG so
> > > > > > that the LC can
> > proceed
> > > soon.
> > > > > >
> > > > > > Thanks & Best regards,
> > > > > > Young
> > > > >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 24 Jan 2017 17:30:44 +0000

Thanks Igor for the detailed explanation, you got it correctly.

Cheers
Daniele  

> Sent: martedì 24 gennaio 2017 17:47
> To: Scharf, Michael (Nokia - DE) <[email-masked]>; Daniele
> Ceccarelli <[email-masked]>; Leeyoung
> <[email-masked]>
> Cc: [email-masked]
> Why a top-level MPLS-TP controller can not use several optical controllers (one
> per optical network supporting MPLS network), each of which using several
> lower level optical controllers (each per one optical domain) ?
> 
> Igpr
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 24 Jan 2017 18:00:15 +0000

Hi Michael,

To echo with Igor's and Daniele's comment on recursive-ness discussion, I think the following figure may speak better than thousand words. 

                                                             MDSC
                                                         /             \
                                                     MDSC         MDSC
                                                    /       \        /            \
                                               PNC    PNC  MDSC       MDSC
                                                                      /    \          /     \
                                                                 PNC  PNC   PNC PNC

>From this figure, all interfaces shown are recursive no matter what the physical network layers (under PNC) from the standpoint of topology abstraction and setting up TE tunnels. 

When technology specific information needs to be included, this info will be add-ons on top of the general abstract topology. As far as general topology abstraction standpoint, all interfaces are still recursive in nature. 

Thanks.
Young

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 11:29 AM
To: Scharf, Michael (Nokia - DE) <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

> As I wrote earlier in the thread: Let's assume that there is an MDSC 
> dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs. 
> Would the ACTN framework foresee that the DWDM MDSC and the MPLS-TE 
> MDSC can be used recursively in any combination?

Yes

> For what it is worth, I think I understand how reclusiveness could 
> work if the scope of the ACTN framework is (1) limited to a single 
> technology or protocol layer, or (2) if CMI and MPI are strictly 
> technology-neutral. But if one of these constraints are not true, I get lost how recursion would work in reality.

BR
Daniele  

> As I wrote earlier in the thread: Let's assume that there is an MDSC 
> dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs. 
> Would the ACTN framework foresee that the DWDM MDSC and the MPLS-TE 
> MDSC can be used recursively in any combination?
> 
> For what it is worth, I think I understand how reclusiveness could 
> work if the scope of the ACTN framework is (1) limited to a single 
> technology or protocol layer, or (2) if CMI and MPI are strictly 
> technology-neutral. But if one of these constraints are not true, I get lost how recursion would work in reality.
> 
> Even more in general, it is not easy to understand how the ACTN 
> framework deals with TE engineering in multi-layer networks. For 
> instance, Figure 7 is confusing in this case. I don't think that these 
> are questions specific to solutions.
> 
> Michael
> 
> 
> > > > been reviewed by some of you, we'd like to hear more opinions 
> > > > and know whether the suggested changes are ok with everyone, 
> > > > don't care or someone prefers the actual version. If you speak 
> > > > now before the WG LC we can avoid further duplications of efforts.
> > > >
> > > > Thanks
> > > > Daniele
> > > >
> > > >
> > > >

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 21:48:47 +0000

> Sent: Tuesday, January 24, 2017 6:29 PM

As I said, I can see how this would hypothetically work for entirely technology agnostic interfaces.

> ACTN is NOT limited to a single technology or protocol layer. The MPI can be
> technology agnostic or technology specific and I don't understand what is the
> problem of having an MDSC on top of that.

Which interface would be used between two MDSC? The MPI? The CMI? Either one? A third class of interface? 

And is the interface between two MDSC technology-specific or technology-neutral?

Sorry, this is not at all clear from the document and the architecture therein.

Note one root cause of my confusion is this sentence in draft-ietf-teas-actn-framework-01:

   A key requirement for allowing recursion of MDSCs is that a single
   interface needs to be defined both for the north and the south
   bounds.

I see case where the south interface of an MDSC is technology-specific but possibly the north interface would be technology neutral. How can this be a single interface? What do I miss?

> Regarding the CMI I'd say that it HAS to be technology agnostic, hence the
> technology complexity would be hidden to the parent MDSC from the child MDSCs.

It is this sort of discussion that is missing in the document. But, one question on this specific suggestion: So, a CMI will *never* need access to technology-specific parameters in a ONC within what the ACTN framework standardizes? Is this what implementations would do?

Michael

> > > > multiple technologies (example: IP and Optical - or is this not in
> scope?).
> > > And I

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 21:53:14 +0000

Hi Young,

> To echo with Igor's and Daniele's comment on recursive-ness discussion, I
> think the following figure may speak better than thousand words.
> 
>                                                              MDSC
>                                                          /             \
>                                                      MDSC         MDSC
>                                                     /       \        /
> \
>                                                PNC    PNC  MDSC       MDSC
>                                                                       /    \
> /     \
>                                                                  PNC  PNC
> PNC PNC
> 
> From this figure, all interfaces shown are recursive no matter what the
> physical network layers (under PNC) from the standpoint of topology
> abstraction and setting up TE tunnels.

Thanks a lot for the figure, indeed, this helps.

As already noted, I do not understand the following: Which interface is used between the MDSC in this figure? The MPI? The CMI? 
  
> When technology specific information needs to be included, this info will be
> add-ons on top of the general abstract topology. As far as general topology
> abstraction standpoint, all interfaces are still recursive in nature.

To me, this wording is better than the current text in the I-D, so perhaps something along this lines should be added to the document.

But, if just to cross-check whether the document really means "recursive" or maybe rather "hierarchical": Is my understanding correct that ACTN framework also foresees the following setup:

     _____
    /     \
   V       \
  MDSC    MDSC
  /  \     ^ \
 /    \___/   \
PNC(s)        PNC(s)

As the document states that the northbound and the southbound interface of an MDSC are the same, nothing prevents this use of ACTN, right? BTW, I could perhaps imagine this scenario for MPLS-TE if there are two IGP domains and the MDSCs each use TE tunnels in the respective domain controlled by the other MDSC.

So, is it correct that in the ACTN framework MDSC's can be both client and parent at the same time?

Thanks

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 22:02:19 +0000

> Sent: Tuesday, January 24, 2017 5:47 PM
> To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Leeyoung
> Cc: [email-masked]
> Why a top-level MPLS-TP controller can not use several optical controllers
> (one per optical network supporting MPLS network), each of which using several

Good example, this sort of example is what I believe would be useful to discuss.

Now, since we discuss recursiveness, let's add a further MPLS-TE controller (e.g., as MDSC) to the picture, running on top of one or more MPLS-TP controller(s) (I assume you mean that the MPLS-TP controller acts as MDSC).

What interface would be used between the MPLS-TE controller and the MPLS-TP controller? And would it be identical or different to the interface used between the MPLS-TP controller and the lower level optical controllers?

Thanks

Michael

> with DWDM PNCs and another one dealing with MPLS-TE PNCs. Would the ACTN
> framework foresee that the DWDM MDSC and the MPLS-TE MDSC can be used
> recursively in any combination?
> 
> layer, or (2) if CMI and MPI are strictly technology-neutral. But if one of
> these constraints are not true, I get lost how recursion would work in
> reality.
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 24 Jan 2017 22:14:59 +0000

Hi Michael,

Thanks for your quick reply. My hope with the figure seems to have been indeed helpful. Anyhow, please see inline for my comments.

Best regards,
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 3:53 PM
To: Leeyoung <[email-masked]>; Daniele Ceccarelli <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Young,

> To echo with Igor's and Daniele's comment on recursive-ness 
> discussion, I think the following figure may speak better than thousand words.
> 
>                                                              MDSC
>                                                          /             \
>                                                      MDSC         MDSC
>                                                     /       \        /
> \
>                                                PNC    PNC  MDSC       MDSC
>                                                                       /    \
> /     \
>                                                                  PNC  
> PNC PNC PNC
> 
> From this figure, all interfaces shown are recursive no matter what 
> the physical network layers (under PNC) from the standpoint of 
> topology abstraction and setting up TE tunnels.

YOUNG>> Great!

YOUNG>> good point. This is "MMI". 
We have discussed this in Section 3.2 near Figure 4. We have the following paragraph:

> When technology specific information needs to be included, this info 
> will be add-ons on top of the general abstract topology. As far as 
> general topology abstraction standpoint, all interfaces are still recursive in nature.

YOUNG>> OK. We can add this text (or similar to this text) in the document. 

YOUNG>> Recursive-ness takes place in hierarchical settings. ACTN means both. 

     _____
    /     \
   V       \
  MDSC    MDSC
  /  \     ^ \
 /    \___/   \
PNC(s)        PNC(s)

YOUNG>>  Yes, this can be very possible. 

YOUNG>> Yes, that is correct. Client-server is the very nature of recursive-ness in hierarchical scenarios. As you said, the lower-level MDSC is a server for the top-level MDSC while it is also a client to anything that is below it (whether another MDSC or PNC). 

Thanks

Michael

> > technology-neutral. But if one of these constraints are not true, I 
> > get lost
> how recursion would work in reality.
> 
> ACTN is NOT limited to a single technology or protocol layer. The MPI 
> can be technology agnostic or technology specific and I don't 
> understand what is the problem of having an MDSC on top of that.
> Regarding the CMI I'd say that it HAS to be technology agnostic, hence 
> the technology complexity would be hidden to the parent MDSC from the child MDSCs.
> 
> BR
> Daniele
> 
> > technology-neutral. But if one of these constraints are not true, I 
> > get lost
> how recursion would work in reality.
> >
> > instance, Figure 7 is confusing in this case. I don't think that 
> > these are questions specific to solutions.
> >
> > Michael
> >
> >
> > > This is a framework document, not a solution one. To me saying 
> > > that the ACTN hierarchy should allow for recursion is enough 
> > > within the context
> > of this ID.
> > > > > since this is a WG draft since a while and since it has 
> > > > > already been reviewed by some of you, we'd like to hear more 
> > > > > opinions and know whether the suggested changes are ok with 
> > > > > everyone, don't care or someone prefers the actual version. If 
> > > > > you speak now before the WG LC we can avoid further duplications of efforts.
> > > > >
> > > > > Thanks
> > > > > Daniele
> > > > >
> > > > >
> > > > >
> > > > > > > In Section 3, we added a few words to make sure interfaces 
> > > > > > > A and D are not in scope of ACTN:
> > > > > > >
> > > > > > > NEW: The interfaces within the ACTN scope are B and C 
> > > > > > > while interfaces A and D are out of the scope of ACTN and 
> > > > > > > are only shown in Figure 5 to give a complete context of ACTN.
> > > > > > >
> > > > > > > I believe most of your concerns/comments are incorporated 
> > > > > > > in the proposed revision. Please let us know if there are 
> > > > > > > still any major issues. We look forward to hearing from you soon.
> > > > > > > We'd like to submit the revision as a sable one to the WG 
> > > > > > > so that the LC can
> > > proceed
> > > > soon.
> > > > > > >
> > > > > > > Thanks & Best regards,
> > > > > > > Young
> > > > > >

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 Jan 2017 22:21:06 +0000

So, if there is another interface "MMI", why is this not introduced in Section 3.4 and e.g. Figure 7?

Michael

> Sent: Tuesday, January 24, 2017 11:15 PM
> To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli
> Cc: [email-masked]
> Thanks for your quick reply. My hope with the figure seems to have been indeed
> helpful. Anyhow, please see inline for my comments.
> 
> Best regards,
> Young
> 
> As already noted, I do not understand the following: Which interface is used
> between the MDSC in this figure? The MPI? The CMI?
> 
> To me, this wording is better than the current text in the I-D, so perhaps
> something along this lines should be added to the document.
> 
> But, if just to cross-check whether the document really means "recursive" or
> maybe rather "hierarchical": Is my understanding correct that ACTN framework
> also foresees the following setup:
> 
> As the document states that the northbound and the southbound interface of an
> MDSC are the same, nothing prevents this use of ACTN, right? BTW, I could
> perhaps imagine this scenario for MPLS-TE if there are two IGP domains and the
> MDSCs each use TE tunnels in the respective domain controlled by the other
> MDSC.
> 
> YOUNG>> Yes, that is correct. Client-server is the very nature of recursive-
> ness in hierarchical scenarios. As you said, the lower-level MDSC is a server
> for the top-level MDSC while it is also a client to anything that is below it
> (whether another MDSC or PNC).
> 
> Thanks
> 
> Michael
> 
> 
> > Thanks.
> > Young
> >
> >
> >
> >
> 6.

---

From: Leeyoung <[email-masked]>
Date: Tue, 24 Jan 2017 22:24:17 +0000

Hi Michael,

We can indeed add this special type of interface (MMI) in Section 3.2 (Figure 4) and add the text we discussed below. 

Thanks,
Young

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 4:21 PM
To: Leeyoung <[email-masked]>; Daniele Ceccarelli <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Michael

> Thanks for your quick reply. My hope with the figure seems to have 
> been indeed helpful. Anyhow, please see inline for my comments.
> 
> Best regards,
> Young
> 
> > discussion, I think the following figure may speak better than 
> > thousand
> words.
> >
> >                                                              MDSC
> >                                                          /             \
> >                                                      MDSC         MDSC
> >                                                     /       \        /
> > \
> >                                                PNC    PNC  MDSC       MDSC
> >                                                                       /    \
> > /     \
> >                                                                  PNC 
> > PNC PNC PNC
> >
> As already noted, I do not understand the following: Which interface 
> is used between the MDSC in this figure? The MPI? The CMI?
> 
> We have discussed this in Section 3.2 near Figure 4. We have the 
> following
> paragraph:
> 
> > general topology abstraction standpoint, all interfaces are still 
> > recursive
> in nature.
> 
> To me, this wording is better than the current text in the I-D, so 
> perhaps something along this lines should be added to the document.
> 
> But, if just to cross-check whether the document really means 
> "recursive" or maybe rather "hierarchical": Is my understanding 
> correct that ACTN framework also foresees the following setup:
> 
> As the document states that the northbound and the southbound 
> interface of an MDSC are the same, nothing prevents this use of ACTN, 
> right? BTW, I could perhaps imagine this scenario for MPLS-TE if there 
> are two IGP domains and the MDSCs each use TE tunnels in the 
> respective domain controlled by the other MDSC.
> 
> YOUNG>> Yes, that is correct. Client-server is the very nature of 
> YOUNG>> recursive-
> ness in hierarchical scenarios. As you said, the lower-level MDSC is a 
> server for the top-level MDSC while it is also a client to anything 
> that is below it (whether another MDSC or PNC).
> 
> Thanks
> 
> Michael
> 
> 
> > Thanks.
> > Young
> >
> >
> >
> >
> > > As I wrote earlier in the thread: Let's assume that there is an 
> > > MDSC dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs.
> > > Would the ACTN framework foresee that the DWDM MDSC and the 
> > > MPLS-TE MDSC can be used recursively in any combination?
> >
> > Yes
> >
> > > technology-neutral. But if one of these constraints are not true, 
> > > I get lost
> > ACTN is NOT limited to a single technology or protocol layer. The 
> > MPI can be technology agnostic or technology specific and I don't 
> > Regarding the CMI I'd say that it HAS to be technology agnostic, 
> > hence the technology complexity would be hidden to the parent MDSC 
> > from the child
> MDSCs.
> >
> > BR
> > Daniele
> >
> > > As I wrote earlier in the thread: Let's assume that there is an 
> > > MDSC dealing with DWDM PNCs and another one dealing with MPLS-TE PNCs.
> > > Would the ACTN framework foresee that the DWDM MDSC and the 
> > > MPLS-TE MDSC can be used recursively in any combination?
> > >
> > > technology-neutral. But if one of these constraints are not true, 
> > > I get lost
> > > > > Specifically, I have raised the question how recursion can 
> > > > > work,
> > > > specifically for
> > > > > > The update aims at solving the major issues, once we agree 
> > > > > > on those we can easily move to the minor ones like 
> > > > > > references and
> terms.
> > > > > > everyone, don't care or someone prefers the actual version. 
> > > > > > If you speak now before the WG LC we can avoid further 
> > > > > > duplications of
> efforts.
> > > > > >
> > > > > > Thanks
> > > > > > Daniele
> > > > > >
> > > > > >
> > > > > >
> > > > > > > > We thank you for providing good comments and input in 
> > > > > > > > this
> thread.
> > > > > > > > Co-authors of this draft have discussions to make sure 
> > > > > > > > to incorporate your comments/concerns in the last week. 
> > > > > > > > And here's the summary of our proposal and the diff file 
> > > > > > > > is enclosed with a
> > > > proposed
> > > > > revision.
> > > > > > > >
> > > > > > > > In Section 3, we added a few words to make sure 
> > > > > > > > interfaces A and D are not in scope of ACTN:
> > > > > > > >
> > > > > > > > while interfaces A and D are out of the scope of ACTN 
> > > > > > > > and are only shown in Figure 5 to give a complete context of ACTN.
> > > > > > > >
> > > > > > > > I believe most of your concerns/comments are 
> > > > > > > > incorporated in the proposed revision. Please let us 
> > > > > > > > know if there are still any major issues. We look 
> > > > > > > > forward to hearing from you
> soon.
> > > > > > > > We'd like to submit the revision as a sable one to the 
> > > > > > > > WG so that the LC can
> > > > proceed
> > > > > soon.
> > > > > > > >
> > > > > > > > Thanks & Best regards,
> > > > > > > > Young
> > > > > > >

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 25 Jan 2017 11:16:18 +0000

HI Michael, all,

1. One of the sources for misunderstanding is the fact that the MMI is actually already defined, but in the wrong document, it is in (draft-zhang-teas-actn-yang-03), I'm now adding it to the fwk too. The image that Young sent on the list and that you said is clearly explaining the recursion issue is already there and it's Figure  4, I think that is enough, I'm just adding the I/F names to it.

>    interface needs to be defined both for the north and the south
You're looking at an old version of the document, the statement was removed already in v02.

3. Finally regarding:
> It is this sort of discussion that is missing in the document. But, one question
> on this specific suggestion: So, a CMI will *never* need access to technology-
> specific parameters in a ONC within what the ACTN framework standardizes?
> Is this what implementations would do?
>
I'm adding some text to each interface description saying that the MPI and MMI can be technology specific or technology agnostic while the CMI needs to technology agnostic (as there is where you see the VN concept). I'm planning to add the nice statement below (I'm copying it from one of the emails on the list:

"When technology specific information needs to be included, this info will be add-ons on top of the general abstract topology. As far as general topology abstraction standpoint, all interfaces are still recursive in nature"

Thanks
Daniele  

> Sent: martedì 24 gennaio 2017 22:49
> > > work if
> > these
> I see case where the south interface of an MDSC is technology-specific but
> possibly the north interface would be technology neutral. How can this be a
> single interface? What do I miss?
> 
> It is this sort of discussion that is missing in the document. But, one question
> on this specific suggestion: So, a CMI will *never* need access to technology-
> specific parameters in a ONC within what the ACTN framework standardizes?
> Is this what implementations would do?
> 
> Michael
> 
> 
> 
> >
> > BR
> > Daniele
> >
> > > work if
> > these

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 25 Jan 2017 14:13:46 +0000

Hi Michael,

I think I understand what you mean.

When ACTN says that MDSC speaks the same interface(s) north and south, it only means that the same interfaces it exposes to its clients it MAY use to talk to its servers. For example, an MDSC may expose to its client TE topology/tunnel NBI based on Basic TE Topology/Tunnel models and/or one or more of their technology specific augmentations, and the same interfaces (or any sub- or super-sets from the interface family) the MDSC may use to talk down to its immediate servers. The important principle is that the MDSC in question has no way of knowing whether it's all/some servers are PNCs or MDSCs with their respective servers and so forth. Likewise, the MDSC does not make the assumption that it's all/some clients are top-level controllers or MDSCs with their own clients.

In the context of your example, top-level MPLS-TP MDSC talks down to lower-level MPLS-TP MDSC via IP/MPLS augmentations of TE topology & tunnel models because these are the only models the two has agreed upon, but does not know whether IPL/MPLS layer stops there or continues over a hierarchy of MPLS-TP MDSCs. [To complicate the example a bit more, the top-level MPLS-TP MDSC could talk down IP/MPLS models to some of its providers and optical models to others]. The lower level MPLS-TP MDSC does realize that it uses optical layer providers (because optical augmentations are the only ones it agrees upon with its providers), so it uses the optical augmentations of TE tunnel/topology models for SBIs, but does not know whether it talks to optical PNCs or MDSCs.

So, the bottom line, I think I agree with you - the recursivity in its pure/clean sense is contained within a single layer.

Cheers,
Igor

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2017 5:02 PM
To: Igor Bryskin; Daniele Ceccarelli; Leeyoung
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Thanks

Michael

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 25 Jan 2017 15:30:48 +0000

HI Igor,

"The important principle is that the MDSC in question has no way of knowing whether it's all/some servers are PNCs or MDSCs with their respective servers and so forth."

Why can't we make the MDSC aware whether below him there is a PNC or and MDSC and at what layer it is working at? This would solve all the issue, wouldn't it?

Cheers
Daniele  

> Sent: mercoledì 25 gennaio 2017 15:14
> When ACTN says that MDSC speaks the same interface(s) north and south, it
> only means that the same interfaces it exposes to its clients it MAY use to talk
> to its servers. For example, an MDSC may expose to its client TE
> topology/tunnel NBI based on Basic TE Topology/Tunnel models and/or one or
> more of their technology specific augmentations, and the same interfaces (or
> any sub- or super-sets from the interface family) the MDSC may use to talk
> down to its immediate servers. The important principle is that the MDSC in
> question has no way of knowing whether it's all/some servers are PNCs or
> MDSCs with their respective servers and so forth. Likewise, the MDSC does
> not make the assumption that it's all/some clients are top-level controllers or
> MDSCs with their own clients.
> 
> In the context of your example, top-level MPLS-TP MDSC talks down to lower-
> level MPLS-TP MDSC via IP/MPLS augmentations of TE topology & tunnel
> models because these are the only models the two has agreed upon, but does
> not know whether IPL/MPLS layer stops there or continues over a hierarchy of
> MPLS-TP MDSCs. [To complicate the example a bit more, the top-level MPLS-
> TP MDSC could talk down IP/MPLS models to some of its providers and optical
> models to others]. The lower level MPLS-TP MDSC does realize that it uses
> optical layer providers (because optical augmentations are the only ones it
> agrees upon with its providers), so it uses the optical augmentations of TE
> tunnel/topology models for SBIs, but does not know whether it talks to optical
> PNCs or MDSCs.
> 
> So, the bottom line, I think I agree with you - the recursivity in its pure/clean
> sense is contained within a single layer.
> 
> Cheers,
> Igor
> 
> 
> > Why a top-level MPLS-TP controller can not use several optical
> > controllers (one per optical network supporting MPLS network), each of
> > which using several lower level optical controllers (each per one optical
> domain) ?
> 
> Now, since we discuss recursiveness, let's add a further MPLS-TE controller
> (e.g., as MDSC) to the picture, running on top of one or more MPLS-TP
> controller(s) (I assume you mean that the MPLS-TP controller acts as MDSC).
> 
> What interface would be used between the MPLS-TE controller and the MPLS-
> TP controller? And would it be identical or different to the interface used
> between the MPLS-TP controller and the lower level optical controllers?
> 
> Thanks
> 
> Michael
> 
> 
> 
> 
> >
> > Igpr
> >
> > (Nokia
> > - DE)
> > get lost how recursion would work in reality.
> >
> > > the ACTN hierarchy should allow for recursion is enough within the
> > > context of this
> > ID.
> > > > strange e.g. in a carrier-
> > carrier
> > > > scenario. And so on.
> > > >

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 25 Jan 2017 15:45:45 +0000

> "The important principle is that the MDSC in question has no way of knowing
> whether it's all/some servers are PNCs or MDSCs with their respective servers
> and so forth."
>
> Why can't we make the MDSC aware whether below him there is a PNC or and MDSC
> and at what layer it is working at? This would solve all the issue, wouldn't
> it?

Why should the controller providing the MDSC function have to care about whether the controller below it directly manages a domain ("physical network" doesn't apply well to MPLS-TE), or whether it uses further lower-layer controllers to achieve that, as long as the TE management functionality required by ACTN is completely provided?

Michael

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 25 Jan 2017 15:49:52 +0000

> Why should the controller providing the MDSC function have to care about
> whether the controller below it directly manages a domain ("physical network"
> doesn't apply well to MPLS-TE), or whether it uses further lower-layer
> controllers to achieve that, as long as the TE management functionality
> required by ACTN is completely provided?

Why not if it makes things simpler? It is a single parameter to be exchanged/configured just once...an affordable effort.

Daniele  

> Sent: mercoledì 25 gennaio 2017 16:46
> To: Daniele Ceccarelli <[email-masked]>; Igor Bryskin
> <[email-masked]>; Leeyoung <[email-masked]>
> Cc: [email-masked]
> > "The important principle is that the MDSC in question has no way of
> > knowing whether it's all/some servers are PNCs or MDSCs with their
> > respective servers and so forth."
> >
> > Why can't we make the MDSC aware whether below him there is a PNC or
> > and MDSC and at what layer it is working at? This would solve all the
> > issue, wouldn't it?
> 
> Why should the controller providing the MDSC function have to care about
> whether the controller below it directly manages a domain ("physical network"
> doesn't apply well to MPLS-TE), or whether it uses further lower-layer
> controllers to achieve that, as long as the TE management functionality
> required by ACTN is completely provided?
> 
> Michael

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 25 Jan 2017 18:41:15 +0000

Daniele,

IB>> What issue would this solve? For example, the top-level MDSC may know that it talks down not to PNC but to MDSC, but it will not know the rest of the hierarchy. Why would it care anyway? It would be advantageous that it talks the same way to PNC and MDSC to control in identical way, for example, single- and multi-domain networks. 

Cheers
Daniele

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 25 Jan 2017 19:41:06 +0000

Exactly.

Thanks,
Igor

-----Original Message-----
From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2017 10:46 AM
To: Daniele Ceccarelli; Igor Bryskin; Leeyoung
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Michael

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 26 Jan 2017 09:40:20 +0000

Actually at this time mine is more loud thinking looking for feedbacks.
If in the case of recursiveness we make the MDSC aware of the fact that below there is a PNC or another MDSC it could use an MPI in the former case and a CMI in latter and we save ourselves the effort to define also the MMI. The only drawback I see is a configuration step or the exchange of few bits...are there others?
In the end we have the same issue with the MMI since the father MDSC would use the MPI with a PNC or the MMI with a child MDSC...
Again, I don't have a strong opinion about this, just sharing my thoughts.
BR
Daniele

> Sent: mercoledì 25 gennaio 2017 20:41

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 26 Jan 2017 10:15:24 +0000

I fail to see the difference between the interface an MDSC would use to a PNC and the interface an MDSC would use to another MDSC. What is the functional difference? One doesn't need to define some new bits if it is cristal clear what the difference in the functions and data models would be. But why would they have to use different data models at all (within one technology and protocol layer)?

Or, to phrase the same question slightly differently: What is the exact functional difference between (1) a PNC and (2) an MDSC that only interfaces to one PNC?

A MDSC that only interfaces to one PNC doesn't really need multi-domain coordination. To me, at least temporarily, this can be a valid scenario in ACTN, e.g., if another PNC is temporarily in maintenance mode.

Michael

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, January 26, 2017 10:40 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); Leeyoung
Cc: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

> To: Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; Daniele
> Ceccarelli <[email-masked]<mailto:[email-masked]>>; Leeyoung
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 26 Jan 2017 10:48:02 +0000

Hello Michael,

In the top-down direction I would agree with you, but in the bottom-up direction I don't think this is any longer valid.
PNCs can be PCEs, NMSs, SDN controllers, hence a with plethora of brownfield solutions, which as of now can export data with different levels of abstraction (including technology awareness or not) and in all of the cases will for example have the knowledge of tunnels and LSPs and not of virtual networks (which will only be available on the NBI of the MDSC.

I'm trying not to look at the MDSC needs as it come in a brownfield of existing PNCs, hence I'd say it's the MDSC that must adapt itself to what lies below it and not the other way around.

Coming to your cases of MDSC that only interfaces a single PNC I would see just one reasonable use case, which is providing a mediation layer between a legacy PNC and the customer that expects to speak in terms of VNs.

BR
Daniele

From: Teas [mailto:[email-masked]] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: giovedì 26 gennaio 2017 11:15
To: Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 26 Jan 2017 11:18:47 +0000

Hi Daniele,

Do I correctly understand your statement that the virtual network concept is the key difference between PNC and MDSC?

Now, let's assume that a "brownfield" solution that fully manages a "physical" network (e.g., either a single physical network or multiple ones), and that this software also offers whatever ACTN may define as interface for virtual networks. Would that software be a PNC or an MDSC within the ACTN framework?

Thanks

Michael

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, January 26, 2017 11:48 AM
To: Scharf, Michael (Nokia - DE) <[email-masked]>; Igor Bryskin <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hello Michael,

BR
Daniele

To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>

Michael

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 26 Jan 2017 14:43:45 +0000

Finally an email with quick and simple questions and answers :)

The VN is a concept available only at the MDSC, correct.  For two reasons:

1.       The VN can span multiple domains and layers, hence a PNC, which only has visibility of his domain can only know that a given tunnel within its domain is part of a given VN but might not know where the VN starts or ends.

2.       The PNC could be a pre-ACTN entity. You might have an MDSC sitting on top of 3 PNC, two of which export a standard MPI and the third a legacy box with no ACTN capabilities. BY means of an adaptation layer on top of the third box it is possible to put the 3 of them under a single MDSC and present the network to the customer as if it was a fully ACTN compliant architecture over a standard CMI.

Regarding your example that's an implementation choice. That would be a box with PNC and MDSC capabilities with any type of SBI on the south bound side (e.g. PCEP, Netconf, outside ACTN scope) and with a CMI on the northbound. Looking at it from the north bound side it looks like an MDSC, while looking at it from outside it is a PNC+MDSC.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: giovedì 26 gennaio 2017 12:19
To: Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Daniele,

Thanks

Michael

To: Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>

Hello Michael,

BR
Daniele

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 26 Jan 2017 16:27:56 +0000

If there is recursion, your 1. argument applies in the same way to lower-layer MDSC's. Any MDSC below the top one only has visibility into its domain(s) and may not know where the VN starts or ends. So, is the conclusion of this reasoning that in a recursion of MDSC's the VN concept is only applicable in the top layer? In other words, is the conclusion that the VN concept is not part of the MMI?

If there is recursion, your argument 2 is a slippery slope. In a hierarchy of recursive MDSC's, one could use a hierarchy of "pre-ACTN MDSCs" and an adaption layer to a top-level MDSC. So, to the customer the whole network would look like a fully standard-compliant ACTN architecture. In that sense, MMI could be pre-ACTN interfaces, too.

Anyway, I now understand that Figure 5 in draft-ietf-teas-actn-framework-02 needs to be updated, as it is now clear that interface C may actually not exist in reality, since PNC and MDSC may not be distinguishable from the outside, while instead there may be e.g. one or many MMI(s) due to the inherently possible recursion.

Thanks

Michael

From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Thursday, January 26, 2017 3:44 PM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; Leeyoung
Cc: [email-masked]
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

BR
Daniele

Hi Daniele,

Thanks

Michael

Hello Michael,

BR
Daniele

Michael

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 26 Jan 2017 17:03:49 +0000

Michael,

In my mind VNs are no different from abstract TE topologies configured by the client, which are hierarchical and recursive in nature. In other words, when a client uses VN, it in fact uses the top level abstract TE topology associated with the VN and is (should be) oblivious whether  said topology is directly supported by physical nodes/links or each topology node/link has its individual stack of supporting topologies. I am not sure if this answers your question, but what I am trying to say is that VNs, abstract TE topologies and TE tunnels rely on the same MDSC recursivity principle.

Cheers,
Igor

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, January 26, 2017 11:28 AM
To: Daniele Ceccarelli; Igor Bryskin; Leeyoung
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Thanks

Michael

BR
Daniele

Hi Daniele,

Thanks

Michael

Hello Michael,

BR
Daniele

Michael

---

From: Leeyoung <[email-masked]>
Date: Thu, 26 Jan 2017 17:08:30 +0000

Hi Michael,

I think there is misunderstanding in this thread. At the top level MDSC, the original VN is decomposed to a set of sub-VNs related to each low-level MDSCs  and communicated to the lower level MDSCs.  So the recursion still works in the MMI for VN concept.

When there is no MDSC hierarchy (which is depicted in Figure 5), there is a clear distinction of MDSC and PNC (from the point of view of their functions discussed in Sections 3.2 and 3.3 ), so interface C (MPI) is clearly needed to distinguish from CMI. MPI is not the same as CMI. That is what Figure 5 shows.

In case where there is MDSC hierarchy, the MMI can be viewed as a special case of MPI from a recursion standpoint. So your point that the interface C (MPI) may not exist in reality is not correct because you are mixing up two different cases.

Hope this conversation would lead to convergence.

Thanks.
Young

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Thursday, January 26, 2017 10:28 AM
To: Daniele Ceccarelli <[email-masked]>; Igor Bryskin <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Thanks

Michael

BR
Daniele

Hi Daniele,

Thanks

Michael

Hello Michael,

BR
Daniele

Michael

---

From: Leeyoung <[email-masked]>
Date: Thu, 26 Jan 2017 17:09:43 +0000

Hi Igor,

Thanks for your version of this explanation. I agree with you.

Thanks,
Young

From: Igor Bryskin
Sent: Thursday, January 26, 2017 11:04 AM
To: Scharf, Michael (Nokia - DE) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Leeyoung <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Michael,

Cheers,
Igor

Thanks

Michael

BR
Daniele

Hi Daniele,

Thanks

Michael

Hello Michael,

BR
Daniele

Michael

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 26 Jan 2017 17:46:18 +0000

Hi,

I somehow get lost here as the different statements on VNs seem contradicting. For -03, I look forward to a precise definition of the differences between CMI, MPI, and MMI and the exact differences between PNC and the different types of MDSCs when recursion is used. I think for each interface in scope of the ACTN framework a precise statement is needed what is in scope and what is not in scope, e.g., whether the VN concept applies or not.

Regarding the interface C / MPI, if the controller performing the MDSC function directly talks to the physical network elements, what would interface C / MPI be in this case?

Note that a direct interface between the controller realizing the MDSC functionality and physical network elements can happen in reality. As a random example, I suggest to have a look at Figure 2 in draft-fu-pce-ip-link-transport-service-mapping-01. How would that figure map to the ACTN framework? Specifically, where is the interface C / MPI for the IP network in Figure 2 of this draft? I assume here that the "super-controller" realizes the MDSC function defined by ACTN. Or is the ACTN framework is not applicable to this sort of architecture?

Thanks

Michael

From: Leeyoung [mailto:[email-masked]]
Sent: Thursday, January 26, 2017 6:09 PM
To: Scharf, Michael (Nokia - DE); Daniele Ceccarelli; Igor Bryskin
Cc: [email-masked]
Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt

Hi Michael,

Thanks.
Young

Thanks

Michael

BR
Daniele

Hi Daniele,

Thanks

Michael

Hello Michael,

BR
Daniele

Michael