Re: [Teas] ACTN and Network Slicing in draft-ietf-teas-ietf-network-slice-framework

[John E Drake <[e-mail]>]

Adrian,

I think this is reasonable.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Tuesday, March 30, 2021 4:32 AM
> To: 'TEAS WG' <[e-mail]>
> Cc: [e-mail]
> Subject: ACTN and Network Slicing in draft-ietf-teas-ietf-network-slice-
> framework
> 
> [External Email. Be cautious of content]
> 
> 
> Hi authors of draft-ietf-teas-ietf-network-slice-framework and TEAS WG,
> 
> I've been looking at the ACTN section in this draft. I think it is good that this
> draft makes it clear that ACTN is an applicable technology for creating and
> managing network slices: ACTN is core TEAS mechanism and we should make it
> available for re-use where possible.
> 
> However, I think that applying ACTN to network slicing needs more text than it is
> appropriate to place in this document. You currently have 2 pages out of about
> 11 pages of text. While I expect the total will grow as more material is added
> across the document, I also think that adding more substance to the ACTN
> section would put it completely out of balance.
> 
> My suggestion is that we:
> - revise down the ACTN text in this document
> - make a reference to a separate document to describe the applicability
>   of ACTN
> I would (obviously?) suggest draft-king-teas-applicability-actn-slicing
> as the document to be referenced although it will need some work to bring it
> into line with the terminology work that has been done in TEAS.
> 
> My suggested edits to this document are:
> 
> 
> 3.2
> OLD
>    Layered virtual connections are comprehensively discussed in IETF
>    documents and are widely supported.  See, for instance, GMPLS-based
>    networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and
>    [RFC8454]).  The principles and mechanisms associated with layered
>    networking are applicable to IETF network slices.
> NEW
>    Layered virtual connections are comprehensively discussed in IETF
>    documents and are widely supported.  See, for instance, GMPLS-based
>    networks [RFC5212] and [RFC4397], or Abstraction and Control of TE
>    Networks (ACTN) [RFC8453] and [RFC8454].  The principles and
>    mechanisms associated with layered networking are applicable to IETF
>    network slices.
> END
> 
> ---
> 
> 3.5
> 
> OLD
>    Also, as outlined in "applicability of ACTN to IETF Network Slices"
>    below, ACTN ([RFC8453]) offers a framework that is used elsewhere in
>    IETF specifications to create virtual network (VN) services similar
>    to IETF network slices.
> NEW
>    Also, as described in Section 4, below, ACTN offers a framework that
>    is used elsewhere in IETF specifications to create virtual network
>    (VN) services similar to IETF network slices.
> END
> 
> ---
> 
> 4. COMPLETE REPLACEMENT
> 
> 4.  Applicability of ACTN to IETF Network Slices
> 
>    Abstraction and Control of TE Networks (ACTN - [RFC8453]) is a
>    management architecture and toolkit used to create virtual networks
>    (VNs) on top of a traffic engineering (TE) underlay network.  The VNs
>    can be presented to customers for them to operate as private
>    networks.
> 
>    In many ways, the function of ACTN is similar to IETF network
>    slicing.  Customer requests for connectivity-based overlay services
>    are mapped to dedicated or shared resources in the underlay network
>    in a way that meets customer guarantees for service level objectives
>    and for separation from other customers' traffic.  [RFC8453] the
>    function of ACTN as collecting resources to establish a logically
>    dedicated virtual network over one or more TE networks.  Thus, in the
>    case of a TE-enabled underlying network, the ACTN VN can be used as a
>    basis to realize an IETF network slicing.
> 
>    While the ACTN framework is a generic VN framework that can be used
>    for VN services beyond the IETF network slice, it also a suitable
>    basis for delivering and realizing IETF network slices.
> 
>    Figure 1 illustrates the mapping between IETF network slice
>    management and interfaces, and the ACTN management components and
>    interfaces.  For reference, the ACTN abbreviations are as follows:
>      CNC  : Customer Network Controller
>      MDSC : Multi-Domain Service Coordinator
>      PNC  : Provisioning Network Controller
>      CMI  : CNC-MDSC Interface
>      MPI  : MDSC-PNC Interface
> 
> 
>                 IETF Network Slice                |   ACTN analogous
>               Terminology / Concepts                  Terminology
>                                                   |    and Concepts
>        +--------------------------------------+
>        |Consumer higher level operation system|   |    +-----+
>        | (e.g E2E network slice orchestrator) | =====> | CNC |
>        +--------------------------------------+   |    +-----+
>                          ^                                ^
>                          | NSC NBI                |       | CMI
>                          v                                v
>        +-------------------------------------+    |    +------+
>        | IETF Network Slice Controller (NSC) |  =====> | MDSC |
>        +-------------------------------------+    |    +------+
>                          ^                                ^
>                          | NSC SBI                |       | MPI
>                          v                                v
>        +-------------------------------------+    |    +-----+
>        |        Network Controller(s)        |  =====> | PNC |
>        +-------------------------------------+    |    +-----+
> 
>    Figure 1 : Mapping Between IETF Network Slice and ACTN Components
> 
> 
>    Note that the details of all function below the NSC SBI are out of
>    scope of this document.
> 
>    Further discussion of the applicability of ACTN to IETF network
>    slices including a discussion of the relevant YANG models can be
>    found in [I-D.king-teas-applicability-actn-slicing].
> 
> ---
> 
> Hope this helps.
> 
> Best,
> Adrian