A Framework for Network Slices in Networks Built from IETF Technologies
draft-ietf-teas-ietf-network-slices-25

I have (reluctantly) cleared by DISCUSS about the use of the "IETF" prefix for "IETF Network Slices". I do hope the responsible AD will do as much as they can to help reduce the use of IETF prefixed terms for WG specific purposes.

Thank you for improving the Security Considerations based on my DISCUSS and refining the language naming this framework.

===

** Section 4.
  IETF Network Slices are created to meet specific requirements,
   typically expressed as bandwidth, latency, latency variation, and
   other desired or required characteristics.

Given that Section 5.1.* mentions security properties as a characteristic of a slice, should security be mentioned here?

** Section 6.2 and 6.3.  This is not my area so I had trouble understanding the framing suggested in this section.  

-- I was under the impression that this text would describe how to manifest _IETF_ network slices using _IETF_ technology.  The text says “There are several IETF-defined mechanisms for expressing the need for a desired logical network.”  However, all of these examples seem hypothetical – NETCONF/RESTCONF are cited but there are no associated models; openconfig-rtgwg-gnmi-spec is an expired, un-adopted document whose details don’t seem to provide a means to express “connectivity intents” (and also not an IETF-defined mechanism); and PCEP is tangible, but I didn’t follow how the TLVs were supposed to be reused in the network slice interface?

-- How are these technologies any different than provisioning a network that isn’t a slice?  Where are the “slice-specific” requirements and needs?

-- What makes this described architecture different than a generic SDN/NVF architecture?

** Section 7.6.
   A customer may request an IETF Network Slice Service that involves a
   set of service functions (SFs)

I might be misunderstanding the level of abstraction at which the SLA/SLI/etc will describe the slice.  I thought SFC would be an implementation detail.  I didn’t see a discussion of SFC in the SLI/SLO/SLE discussion in Section 5.1.  

** Section 10.
      The nature of conformance to isolation
      requests means that it should not be possible to attack an IETF
      Network Slice Service by varying the traffic on other services or
      slices carried by the same underlay network.

I’m not able to understand the security property described by the text.  Is this text trying to say that traffic in one slice is isolated from the other and attack traffic can't move from one slice from one to the other?  That a volumetric attack in one slice can’t affect another?

Thanks to the authors and WG for attempting to address the naming concern.

# Éric Vyncke, INT AD, comments for draft-ietf-teas-ietf-network-slices-22

Thank you for the work put into this document. It is clearly written and easy to read, even if it is unclear on which layer (2 or 3) the slice is, until deep in the text. I also wonder why this is called "IETF Network Slice" as if it was blessed by the IETF community beyond the consensus on this I-D; should it rather be "IETF considerations on network slices" ? 

Please find below some non-blocking COMMENT points.

Special thanks to Vishnu Pavan Beeram for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. 

Other thanks to Dirk Von Hugo, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-teas-ietf-network-slices-21-intdir-telechat-von-hugo-2023-07-21/ (and I have read the email thread with the WG/authors)

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS

## Authors count

This is mainly a note for the IESG as I wonder why for some WG/authors it is OK to have 7 authors and for some other WG/authors 6 is too many. IMHO, it is up to the WG to decide, hence I can only support having 7 authors on this one. I.e., no need for the authors/WG to reply.

## Section 2.3

"Customers" request a service slice but do customers also use this slice ?

Is it a common and accepted use of curled brackets in `{IETF Network Slice Service, connectivity construct, and SLOs/SLEs}` ? Honestly, I cannot understand the difference with normal parenthesis.

## Section 5.1.1.1.

Should security also be part of SLO ? It is only mentioned in section 5.1.2.1.

Is there a difference between the commonly used term of 'jitter' and the 'delay variation' ?

## Section 5.1.2.1.

Is security only limited to 'encryption' (assuming that the end-goal is actually confidentiality with encryption being one means and not then end). Should also be authentication be part of the security ?

## Section 6.1

Does an IETF network slice always require a centralised controller ? AFAICT, MPLS-VPN or EVPN are instances of IETF network slices and they usually do not require any controller.

## RFC 8799

Should RFC 8799 be mentioned in this document ?