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

From: [email-masked]
Date: Wed, 04 Oct 2017 08:15:19 -0700

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

        Title           : Framework for Abstraction and Control of Traffic Engineered Networks
        Authors         : Daniele Ceccarelli
                          Young Lee
	Filename        : draft-ietf-teas-actn-framework-08.txt
	Pages           : 37
	Date            : 2017-10-04

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

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

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

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-actn-framework-08
https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-08

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

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

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 4 Oct 2017 15:29:45 +0000

Dear WG, 

we submitted a new version of the ACTN framework draft which does not introduce or modify any concept but that is the result of a heavy text re-adjustment (thanks a lot Adrian for the huge effort) to improve readability and get rid of duplicated and redundant text. 

The authors and contributors think this is ready for WG LC and would appreciate your comments to the list.

BR
Daniele (for the co-authors)

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: mercoledì 4 ottobre 2017 17:15
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Teas] I-D Action: draft-ietf-teas-actn-framework-08.txt
> 
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 4 Oct 2017 17:21:31 +0000

Wouldn't it make sense to add a better explanation on what the ACTN framework as described in this document does _not_ try to provide?

For instance, the document apparently doesn't cover service assurance functions such as fault management. I am not sure how e.g. alarm correlation between multiple PNCs (possibly at different layers) would work in the ACTN framework as described in the document. But probably fault management and mechanisms such as alarm correlation and root-cause analysis are not in scope of ACTN?

Also, as far as I can see, except for Appendix B there is no network topology example that shows how ACTN would indeed apply to a multi-layer network (e.g., IP/MPLS over OTN). And IMHO the example in Appendix B is too simple as it shows only *one* IP/MPLS PNC and *one* Optical PNC, which may not be a realistic deployment in a larger network operators. As a result, I suggest to either remove Appendix B or to replace it by a more realistic topology example with multiple PNCs (both at IP/MPLS and Optical layer) as well as an actual explanation how ACTN would deal with multiple PNCs and multiple layers, i.e., an actual example what topology would be seen by which MDSC. To me, the current content in Appendix B doesn't really prove that the ACTN concepts indeed work for larger multi-layer scenarios. I'd also be fine with an explicit statement that the applicability of ACTN to multi-layer network deployments is not in scope of the document.

Michael

> From: Teas [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
> Sent: Wednesday, October 04, 2017 5:30 PM
> To: [email-masked]
> Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-08.txt
> 
> Dear WG,
> 
> we submitted a new version of the ACTN framework draft which does not
> introduce or modify any concept but that is the result of a heavy text re-
> adjustment (thanks a lot Adrian for the huge effort) to improve readability
> and get rid of duplicated and redundant text.
> 
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >

---

From: Lou Berger <[email-masked]>
Date: Fri, 6 Oct 2017 15:17:04 -0400

Daniele, Authors,

    Thank you for this substantive update.

All,

There has been a reasonable pass at cleaning up much of the text - and a
fair bit has changed, so please review and comment -- even if it's just
to say that you've read it and thing the changes are beneficial.

Thanks,

Lou (and Pavan)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 9 Oct 2017 17:05:35 -0400

Lou,

I’ve read the updated draft, and it’s a good overall cleanup of the text to
make the concepts easier to understand. My only major comment is that
section 4 could become another subsection of section 3, but that’s minor.

Cheers,
Andy

On Fri, Oct 6, 2017 at 3:17 PM, Lou Berger <[email-masked]> wrote:

> introduce or modify any concept but that is the result of a heavy text
> re-adjustment (thanks a lot Adrian for the huge effort) to improve
> readability and get rid of duplicated and redundant text.
> >
> >> This draft is a work item of the Traffic Engineering Architecture and
> Signaling
> >> WG of the IETF.
> >>
> >>         Title           : Framework for Abstraction and Control of
> Traffic Engineered
> >> Networks
> submission

---

From: Ricard Vilalta <[email-masked]>
Date: Tue, 10 Oct 2017 10:41:43 +0200

All,

I have read the new version and the changes have clearly improved it.

Best,

Ricard

El 09/10/2017 a les 23:05, Andrew G. Malis ha escrit:
> Lou,
>
> I’ve read the updated draft, and it’s a good overall cleanup of the 
> text to make the concepts easier to understand. My only major comment 
> is that section 4 could become another subsection of section 3, but 
> that’s minor.
>
> Cheers,
> Andy
>
>
> On Fri, Oct 6, 2017 at 3:17 PM, Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Daniele, Authors,
>
>     > we submitted a new version of the ACTN framework draft which
>     does not introduce or modify any concept but that is the result of
>     a heavy text re-adjustment (thanks a lot Adrian for the huge
>     effort) to improve readability and get rid of duplicated and
>     redundant text.
>     >
>     > The authors and contributors think this is ready for WG LC and
>     would appreciate your comments to the list.
>     >
>     > BR
>     >> From: Teas [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of internet-
>     >> [email-masked] <mailto:[email-masked]>
>     >> To: [email-masked] <mailto:[email-masked]>
>     >> Cc: [email-masked] <mailto:[email-masked]>
>     >> This draft is a work item of the Traffic Engineering
>     Architecture and Signaling
>     >> WG of the IETF.
>     >>
>     >>         Title           : Framework for Abstraction and Control
>     of Traffic Engineered
>     >> Networks
>     <https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/>
>     >>
>     <https://tools.ietf.org/html/draft-ietf-teas-actn-framework-08>
>     >>
>     <https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework-08>
>     >>
>     <https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework-08>
>     >>
>     >>
>     >> until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >>
>     <ftp://ftp.ietf.org/internet-drafts/>
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>     >
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>
>
>
>

-- 

Dr. Ricard Vilalta
Senior Researcher
Optical Networks and Systems Department
Communication Networks Division
Centre Tecnològic de Telecomunicacions de Catalunya (CTTC/CERCA).

---

From: Zhenghaomian <[email-masked]>
Date: Wed, 11 Oct 2017 01:55:05 +0000

Dear WG, 

I reviewed the updated version of actn framework draft. The new version (-08) restructured the content and clarified the relationship with other work in IETF while keeping the technical part promising. I believe this update can be helpful to promote this work to next step. 

Thank you. 

Best wishes,
Haomian

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2017年10月7日 3:17
收件人: Daniele Ceccarelli; [email-masked]
主题: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-08.txt

Daniele, Authors,

All,

There has been a reasonable pass at cleaning up much of the text - and a fair bit has changed, so please review and comment -- even if it's just to say that you've read it and thing the changes are beneficial.

Thanks,

Lou (and Pavan)

On 10/4/2017 11:29 AM, Daniele Ceccarelli wrote:
>> Signaling WG of the IETF.
>>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 13 Oct 2017 08:34:53 +0000

Hi Michael,

sorry for the delay in answering.
Thanks for the review and comments that can help improving the document.  
Please see in line.

BR
Daniele (for the authors)

> From: Scharf, Michael (Nokia - DE/Stuttgart)
> [mailto:[email-masked]]
> Sent: mercoledì 4 ottobre 2017 19:22
> To: Daniele Ceccarelli <[email-masked]>; [email-masked]
> Subject: RE: [Teas] I-D Action: draft-ietf-teas-actn-framework-08.txt
> 
> Wouldn't it make sense to add a better explanation on what the ACTN
> framework as described in this document does _not_ try to provide?
> 
> For instance, the document apparently doesn't cover service assurance
> functions such as fault management. I am not sure how e.g. alarm correlation
> between multiple PNCs (possibly at different layers) would work in the ACTN
> framework as described in the document. But probably fault management
> and mechanisms such as alarm correlation and root-cause analysis are not in
> scope of ACTN?

[>DC] We have Section 8 (Manageability Consideration) where a high-level management issue related to ACTN is discussed.  We can surely add a couple of sentences to make more clear that ACTN would not reinvent Network Management System (NMS) or can act on behalf of  but it indeed can complement NMS in controlling a TE network. We do not foresee to add specific tool regarding fault management as part of ACTN scope but ,if anything, exploiting IETF tools that have already been defined or are work in progress will be evaluated to support ACTN requirements such as performance monitoring, etc.

> Also, as far as I can see, except for Appendix B there is no network topology
> example that shows how ACTN would indeed apply to a multi-layer network
> (e.g., IP/MPLS over OTN). And IMHO the example in Appendix B is too simple
> as it shows only *one* IP/MPLS PNC and *one* Optical PNC, which may not
> be a realistic deployment in a larger network operators. As a result, I suggest
> to either remove Appendix B or to replace it by a more realistic topology
> example with multiple PNCs (both at IP/MPLS and Optical layer) as well as an
> actual explanation how ACTN would deal with multiple PNCs and multiple
> layers, i.e., an actual example what topology would be seen by which MDSC.
> To me, the current content in Appendix B doesn't really prove that the ACTN
> concepts indeed work for larger multi-layer scenarios. I'd also be fine with an
> explicit statement that the applicability of ACTN to multi-layer network
> deployments is not in scope of the document.

[>DC] Multi-layer is in scope of ACTN (as discussed in Section 4.1.). If you feel Appendix B does not provide sufficient details for multi-layer network implementation scenario (e.g., IP/MPLS over optical), we can remove Appendix B. A framework document should in principle highlight architectural aspects so applicability part would be not essential. On the other end your question and comment makes clear the need to develop a new draft where detailed implementation of multi-layer scenarios can be discussed and this document should become the reference as specific implementation/applicability questions arise .

> > re- adjustment (thanks a lot Adrian for the huge effort) to improve
> > >         Title           : Framework for Abstraction and Control of Traffic
> Engineered
> > > Networks
> > > https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-framework
> > > -0
> > > 8
> > >

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Fri, 13 Oct 2017 23:33:39 +0000

Hi Daniele,

Inline...

> > functions such as fault management. I am not sure how e.g. alarm
> > correlation between multiple PNCs (possibly at different layers) would
> > work in the ACTN framework as described in the document. But probably
> > fault management and mechanisms such as alarm correlation and
> > root-cause analysis are not in scope of ACTN?
> 
> [>DC] We have Section 8 (Manageability Consideration) where a high-level
> management issue related to ACTN is discussed.  We can surely add a couple
> of sentences to make more clear that ACTN would not reinvent Network
> Management System (NMS) or can act on behalf of  but it indeed can
> complement NMS in controlling a TE network. We do not foresee to add
> specific tool regarding fault management as part of ACTN scope but ,if
> anything, exploiting IETF tools that have already been defined or are work in
> progress will be evaluated to support ACTN requirements such as
> performance monitoring, etc.

I agree that fault management is outside the scope of ACTN. 

Yet, I believe that the document has to clearly spell out that the ACTN interfaces focus on the traffic engineering for virtual networks. A network operator may have many other operational tasks for service fulfillment, optimization, and assurance that are not considered in the ACTN framework. Given the focus of ACTN on TE, the interfaces of ACTN may not be sufficient to realize these other tasks.

The challenge can e.g. be seen in Figure 5: A network orchestrator may e.g. be used for alarm collection and alarm correlation, even if this network management function is not in scope of ACTN. Such a network orchestrator may require quite some topology details from the domain controller that implements PNC functions. As a result, while e.g. for the MDSC function in the network orchestrator a black topology abstraction might work, the network orchestrator may need white topology details for non-ACTN OAM functions.

The easiest solution to deal with this issue is IMHO to add some wording like the following one:

NEW: 
The ACTN framework and interfaces are defined to enable traffic engineering for virtual networks. Network operators may have other 
Operations, Administration, and Maintenance (OAM) tasks for service fulfillment, optimization, and assurance beyond traffic engineering. The realization of OAM beyond abstraction and control of traffic engineered networks is not considered in this document. 

 > > Also, as far as I can see, except for Appendix B there is no network
> > topology example that shows how ACTN would indeed apply to a
> > multi-layer network (e.g., IP/MPLS over OTN). And IMHO the example in
> > Appendix B is too simple as it shows only *one* IP/MPLS PNC and *one*
> > Optical PNC, which may not be a realistic deployment in a larger
> > network operators. As a result, I suggest to either remove Appendix B
> > or to replace it by a more realistic topology example with multiple
> > PNCs (both at IP/MPLS and Optical layer) as well as an actual
> > explanation how ACTN would deal with multiple PNCs and multiple layers,
> i.e., an actual example what topology would be seen by which MDSC.
> > To me, the current content in Appendix B doesn't really prove that the
> > ACTN concepts indeed work for larger multi-layer scenarios. I'd also
> > be fine with an explicit statement that the applicability of ACTN to
> > multi-layer network deployments is not in scope of the document.
> 
> [>DC] Multi-layer is in scope of ACTN (as discussed in Section 4.1.). If you feel

There is no example for application of ACTN to an actual "multi-layer" use case in the document. And the term "layer" is used inconsistently in the document, which I find confusing. For instance, the example in Section 5.4 can be realized with different technologies in each domain, but this only shows that ACTN can apply to different technologies that provide end-to-end connectivity. At least in my understanding "multi-layer" has a broader scope.

I think this confusion could be avoided in Section 4.1 as follows:

OLD:
   Another implementation choice could foresee the usage of an MDSC-L
   for all the PNCs related to a given network layer or technology
   (e.g. IP/MPLS) a different MDSC-L for the PNCs related to another
   layer/technology (e.g. OTN/WDM) and an MDSC-H to coordinate them.

NEW:
   Another implementation choice could foresee the usage of an MDSC-L
   for all the PNCs related to a given technology (e.g. IP/MPLS) and a
   different MDSC-L for the PNCs related to another
   technology (e.g. OTN/WDM) and an MDSC-H to coordinate them.

An alternative solution would be to entirely remove this paragraph, as there is no network topology example for this "implementation choice", which would be needed to explain how such an implementation would work and e.g. what abstraction would be used by the MDSC-L and MDSC-H in that case. Without backing by an actual topology example, I don't think that such handwaving adds value to the document.

Non-trivial examples IMHO belong to another document with a more detailed analysis and actual examples.

> Appendix B does not provide sufficient details for multi-layer network
> implementation scenario (e.g., IP/MPLS over optical), we can remove
> Appendix B. A framework document should in principle highlight architectural
> aspects so applicability part would be not essential. On the other end your
> question and comment makes clear the need to develop a new draft where
> detailed implementation of multi-layer scenarios can be discussed and this
> document should become the reference as specific
> implementation/applicability questions arise .

Removing appendix B seems appropriate.

I believe that the applicability of ACTN to multi-layer use cases requires further discussion and an analysis of actual multi-layer topology examples. Multi-layer use cases can become pretty complex. For instance, if multiple layers are considered, this could imply that the connectivity is achieved by composite services (see draft-chen-opsawg-composite-vpn-dm-00 for some example). I have some doubts whether the ACTN framework document is the best place to discuss all the implications of complex "multi-layer" cases.

Michael

> > > we submitted a new version of the ACTN framework draft which does
> > > not introduce or modify any concept but that is the result of a
> > > heavy text

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 16 Oct 2017 14:37:54 +0000

Hi Michael,

We're fine with your proposed changes. There is a new version coming out soon, they will be implemented. 

Thanks
Daniele  

> Sent: sabato 14 ottobre 2017 01:34
> > > For instance, the document apparently doesn't cover service
> > > assurance functions such as fault management. I am not sure how e.g.
> > > alarm correlation between multiple PNCs (possibly at different
> > > layers) would work in the ACTN framework as described in the
> > > document. But probably fault management and mechanisms such as
> alarm
> > > correlation and root-cause analysis are not in scope of ACTN?
> >
> > [>DC] We have Section 8 (Manageability Consideration) where a
> > high-level management issue related to ACTN is discussed.  We can
> > surely add a couple of sentences to make more clear that ACTN would
> > not reinvent Network Management System (NMS) or can act on behalf of
> > but it indeed can complement NMS in controlling a TE network. We do
> > not foresee to add specific tool regarding fault management as part of
> > ACTN scope but ,if anything, exploiting IETF tools that have already
> > been defined or are work in progress will be evaluated to support ACTN
> > requirements such as performance monitoring, etc.
> 
> Yet, I believe that the document has to clearly spell out that the ACTN
> interfaces focus on the traffic engineering for virtual networks. A network
> operator may have many other operational tasks for service fulfillment,
> optimization, and assurance that are not considered in the ACTN framework.
> Given the focus of ACTN on TE, the interfaces of ACTN may not be sufficient
> to realize these other tasks.
> 
> The challenge can e.g. be seen in Figure 5: A network orchestrator may e.g.
> be used for alarm collection and alarm correlation, even if this network
> management function is not in scope of ACTN. Such a network orchestrator
> may require quite some topology details from the domain controller that
> implements PNC functions. As a result, while e.g. for the MDSC function in
> the network orchestrator a black topology abstraction might work, the
> network orchestrator may need white topology details for non-ACTN OAM
> functions.
> 
> The ACTN framework and interfaces are defined to enable traffic
> engineering for virtual networks. Network operators may have other
> Operations, Administration, and Maintenance (OAM) tasks for service
> fulfillment, optimization, and assurance beyond traffic engineering. The
> realization of OAM beyond abstraction and control of traffic engineered
> networks is not considered in this document.
> 
> > > multi-layer network (e.g., IP/MPLS over OTN). And IMHO the example
> > > in Appendix B is too simple as it shows only *one* IP/MPLS PNC and
> > > *one* Optical PNC, which may not be a realistic deployment in a
> > > larger network operators. As a result, I suggest to either remove
> > > Appendix B or to replace it by a more realistic topology example
> > > with multiple PNCs (both at IP/MPLS and Optical layer) as well as an
> > > actual explanation how ACTN would deal with multiple PNCs and
> > > multiple layers,
> > > To me, the current content in Appendix B doesn't really prove that
> > > the ACTN concepts indeed work for larger multi-layer scenarios. I'd
> > > also be fine with an explicit statement that the applicability of
> > > ACTN to multi-layer network deployments is not in scope of the
> document.
> >
> There is no example for application of ACTN to an actual "multi-layer" use
> case in the document. And the term "layer" is used inconsistently in the
> document, which I find confusing. For instance, the example in Section 5.4
> can be realized with different technologies in each domain, but this only
> shows that ACTN can apply to different technologies that provide end-to-
> end connectivity. At least in my understanding "multi-layer" has a broader
> scope.
> 
> An alternative solution would be to entirely remove this paragraph, as there
> is no network topology example for this "implementation choice", which
> would be needed to explain how such an implementation would work and
> e.g. what abstraction would be used by the MDSC-L and MDSC-H in that case.
> Without backing by an actual topology example, I don't think that such
> handwaving adds value to the document.
> 
> > Appendix B. A framework document should in principle highlight
> > architectural aspects so applicability part would be not essential. On
> > the other end your question and comment makes clear the need to
> > develop a new draft where detailed implementation of multi-layer
> > scenarios can be discussed and this document should become the
> > reference as specific implementation/applicability questions arise .
> 
> I believe that the applicability of ACTN to multi-layer use cases requires
> further discussion and an analysis of actual multi-layer topology examples.
> Multi-layer use cases can become pretty complex. For instance, if multiple
> layers are considered, this could imply that the connectivity is achieved by
> composite services (see draft-chen-opsawg-composite-vpn-dm-00 for some
> example). I have some doubts whether the ACTN framework document is
> the best place to discuss all the implications of complex "multi-layer" cases.
> 
> Michael
> 
> 
> > > > re- adjustment (thanks a lot Adrian for the huge effort) to
> > > > improve readability and get rid of duplicated and redundant text.
> > > >
> > > > > A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts
> > > > directories.
> > > > > Architecture and Signaling WG of the IETF.
> > > > >
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-frame
> > > > > wo
> > > > > rk
> > > > > -0
> > > > > 8
> > > > >
> > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-actn-framework
> > > > > -0
> > > > > 8
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time
> > > > > of submission until the htmlized version and diff are available
> > > > > at
> > > tools.ietf.org.
> > > > >

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 16 Oct 2017 18:02:12 +0000

Thanks

Michael

> Sent: Monday, October 16, 2017 4:38 PM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>;
> [email-masked]
> > > > Wouldn't it make sense to add a better explanation on what the
> > > > ACTN framework as described in this document does _not_ try to
> provide?
> > > >
> > > not foresee to add specific tool regarding fault management as part
> > > of ACTN scope but ,if anything, exploiting IETF tools that have
> > > already been defined or are work in progress will be evaluated to
> > > support ACTN requirements such as performance monitoring, etc.
> >
> > Yet, I believe that the document has to clearly spell out that the
> > ACTN interfaces focus on the traffic engineering for virtual networks.
> > A network operator may have many other operational tasks for service
> > fulfillment, optimization, and assurance that are not considered in the
> ACTN framework.
> > Given the focus of ACTN on TE, the interfaces of ACTN may not be
> > sufficient to realize these other tasks.
> >
> > be used for alarm collection and alarm correlation, even if this
> > network management function is not in scope of ACTN. Such a network
> > orchestrator may require quite some topology details from the domain
> > controller that implements PNC functions. As a result, while e.g. for
> > the MDSC function in the network orchestrator a black topology
> > abstraction might work, the network orchestrator may need white
> > topology details for non-ACTN OAM functions.
> >
> > fulfillment, optimization, and assurance beyond traffic engineering.
> > The realization of OAM beyond abstraction and control of traffic
> > engineered networks is not considered in this document.
> >
> > > > with multiple PNCs (both at IP/MPLS and Optical layer) as well as
> > > > an actual explanation how ACTN would deal with multiple PNCs and
> > > > multiple layers,
> > > > the ACTN concepts indeed work for larger multi-layer scenarios.
> > > > I'd also be fine with an explicit statement that the applicability
> > > > of ACTN to multi-layer network deployments is not in scope of the
> > document.
> > >
> > There is no example for application of ACTN to an actual "multi-layer"
> > use case in the document. And the term "layer" is used inconsistently
> > in the document, which I find confusing. For instance, the example in
> > Section 5.4 can be realized with different technologies in each
> > domain, but this only shows that ACTN can apply to different
> > technologies that provide end-to- end connectivity. At least in my
> > understanding "multi-layer" has a broader scope.
> >
> > An alternative solution would be to entirely remove this paragraph, as
> > there is no network topology example for this "implementation choice",
> > which would be needed to explain how such an implementation would
> work
> > and e.g. what abstraction would be used by the MDSC-L and MDSC-H in
> that case.
> > > Appendix B does not provide sufficient details for multi-layer
> > > network implementation scenario (e.g., IP/MPLS over optical), we can
> > > remove Appendix B. A framework document should in principle
> > > highlight architectural aspects so applicability part would be not
> > > essential. On the other end your question and comment makes clear
> > > the need to develop a new draft where detailed implementation of
> > > multi-layer scenarios can be discussed and this document should
> > > become the reference as specific implementation/applicability questions
> arise .
> >
> > I believe that the applicability of ACTN to multi-layer use cases
> > requires further discussion and an analysis of actual multi-layer topology
> examples.
> > Multi-layer use cases can become pretty complex. For instance, if
> > multiple layers are considered, this could imply that the connectivity
> > is achieved by composite services (see
> > draft-chen-opsawg-composite-vpn-dm-00 for some example). I have some
> > doubts whether the ACTN framework document is the best place to
> discuss all the implications of complex "multi-layer" cases.
> >
> > Michael
> >
> >
> > > > > does not introduce or modify any concept but that is the result
> > > > > of a heavy text
> > > > > > From: Teas [mailto:[email-masked]] On Behalf Of
> > > > > > internet- [email-masked]
> > > > > > of submission until the htmlized version and diff are
> > > > > > available at
> > > > tools.ietf.org.
> > > > > >