[Teas] AD review of draft-ietf-teas-ietf-network-slices-19

[John Scudder <[e-mail]>]

Hi Authors, WG,

Thanks for this well-written document.

I’ve supplied my questions and comments in the form of an edited copy of the draft. Minor editorial suggestions I’ve made in place without further comment, more substantive questions and comments are done in-line and prefixed with “jgs:”. You can use your favorite diff tool to review them; I’ve attached the iddiff output for your convenience if you’d like to use it. I’ve also pasted a traditional diff below in case you want to use it for in-line reply. 

Thanks,

—John

--- draft-ietf-teas-ietf-network-slices-19.txt	2023-05-30 16:23:10.000000000 -0400
+++ draft-ietf-teas-ietf-network-slices-19-jgs-comments.txt	2023-05-30 17:43:02.000000000 -0400
@@ -175,6 +175,9 @@
    *  Network infrastructure sharing among operators
 
    *  NFV connectivity and Data Center Interconnect
+--
+jgs: please expand "NFV" on first use
+--
 
    Further analysis of the needs of IETF Network Slice service customers
    is provided in [I-D.ietf-teas-ietf-network-slice-use-cases].
@@ -193,6 +196,9 @@
    interfaces and technologies.
 
    For example, virtual private networks (VPNs) have served the industry
+--
+jgs: example of what? 
+--
    well as a means of providing different groups of users with logically
    isolated access to a common network.  The common or base network that
    is used to support the VPNs is often referred to as an underlay
@@ -292,7 +298,7 @@
 
    *  SLO: Service Level Objective
 
-   The meaning of these abbreviations is defined in greater details in
+   The meaning of these abbreviations is defined in greater detail in
    the remainder of this document.
 
 3.2.  Core Terminology
@@ -315,7 +321,7 @@
       Network Slice service.  A provider is the network operator that
       controls the network resources used to construct the network slice
       (that is, the network that is sliced).  The provider's network
-      maybe a physical network, or may be a virtual network created
+      may be a physical network, or may be a virtual network created
       within the operator's network or supplied by another service
       provider.
 
@@ -326,6 +332,10 @@
       functions, and PEPs (Performance Enhancing Proxy).  In some
       circumstances CEs are provided to the customer and managed by the
       provider.
+--
+jgs: maybe it's just me but I would have benefited from a reference for
+HTTP header enrichment
+--
 
    Provider Edge (PE):  The device within the provider network to which
       a CE is attached.  A CE may be attached to multiple PEs, and
@@ -343,6 +353,12 @@
       exchanged.  An AC is, by definition, technology specific: that is,
       the AC defines how customer traffic is presented to the provider
       network.  The customer and provider agree (through configuration)
+--
+jgs: Is "through configuration" meant to be limiting? The way you've 
+written it, it is, that is to say you've ruled out the customer and
+provider agreeing through some other means, such as a protocol. Maybe
+"for example, through configuration"?
+--
       on which values in which combination of layer 2 and layer 3 header
       and payload fields within a packet identify to which {IETF Network
       Slice service, connectivity construct, and SLOs/SLEs} that packet
@@ -513,7 +529,7 @@
 4.2.1.  Connectivity Constructs
 
    The approach of specifying a Network Slice service as a set of SDPs
-   with connectiviy constructs, results in the following possible
+   with connectivity constructs, results in the following possible
    connectivity constructs:
 
    *  For a P2P connectivity construct, there is one sending SDP and one
@@ -662,9 +678,22 @@
    address, or it may be a placeholder, e.g., IPTV or DNS server, which
    is resolved within the provider's network when the IETF Network Slice
    service is instantiated.
+--
+jgs: I found this paragraph hard to follow, especially the first 
+sentence. AFAICT the ancillary CE construct is introduced as a way 
+of allowing the SP to include application-layer things as part of
+their offering. I wonder if there is some more straightforward way
+of saying this.
+--
 
    Thus, an ancillary CE may be a node within the provider network
    (i.e., not a CE).  An example is a node that provides a service
+--
+jgs: "an ancillary CE" is "not a CE". Unless you're deliberately 
+trying to wake the reader up by making them resolve a quick paradox,
+it would probably be better to add an adjective, as in "not a conventional
+CE".
+--
    function.  Another example is a node that acts as a hub.  There will
 
 
@@ -808,10 +837,10 @@
    the IETF Network Slice service that a customer requests.  These would
    be specified in further documents.
 
-   If the IETF Network Slice service is traffic aware, other traffic
-   specific characteristics may be valuable including MTU, traffic-type
-   (e.g., IPv4, IPv6, Ethernet or unstructured), or a higher-level
-   behavior to process traffic according to user-application (which may
+   If the IETF Network Slice service is traffic-aware, other traffic
+   specific characteristics may be valuable including MTU, traffic type
+   (e.g., IPv4, IPv6, Ethernet, or unstructured), or a higher-level
+   behavior to process traffic according to user application (which may
    be realized using network functions).
 
 5.1.2.  Service Level Expectations
@@ -1130,7 +1159,7 @@
    dedicated network resources and/or functions allocated in a shared
    underlay network to satisfy the needs of the IETF Network Slice
    service customer.  In at least some examples of underlay network
-   technologies, the integration between the overlay and various
+   technologies, integration between the overlay and various
    underlay resources is needed to ensure the guaranteed performance
    requested for different IETF Network Slices.
 
@@ -1241,6 +1270,9 @@
       exposed to the customer.  (Note - a customer should not use
       network information not exposed via the IETF Network Slice Service
       Interface, even if that information is available.)
+--
+jgs: Instead of "should not use" perhaps "should not rely on"?
+--
 
    *  Scalability: Customers do not need to know any information
       concerning network topology, capabilities, or state beyond that
@@ -1251,7 +1283,7 @@
 
    This framework document does not assume any particular technology
    layer at which IETF Network Slices operate.  A number of layers
-   (including virtual L2, Ethernet or, IP connectivity) could be
+   (including virtual L2, Ethernet, or IP connectivity) could be
    employed.
 
    Data models and interfaces are needed to set up IETF Network Slices,
@@ -1306,8 +1338,8 @@
    implements them using a suitable underlay technology.  An IETF NSC is
    the key component for control and management of the IETF Network
    Slice.  It provides the creation/modification/deletion, monitoring
-   and optimization of IETF Network Slices in a multi-domain, a multi-
-   technology and multi-vendor environment.
+   and optimization of IETF Network Slices in a multi-domain, multi-
+   technology, and multi-vendor environment.
 
    The main task of an IETF NSC is to map abstract IETF Network Slice
    service requirements to concrete technologies and establish required
@@ -1330,6 +1362,15 @@
       exposed by this interface communicates the Service Demarcation
       Points of the IETF Network Slice, IETF Network Slice SLO/SLE
       parameters (and possibly monitoring thresholds), applicable input
+--
+jgs: Here and in at least one place following you talk about SLE parameters
+as being something that can be exposed in a programmatic interface. Is it
+then intended that all SLEs although not directly measurable, must be 
+expressible in this fashion? I guess this might be worth saying, because
+I had read Section 5.1.2 as meaning that an SLE is more or less, anything
+I can write into a contract -- and as anyone who has reviewed a contract
+knows, that doesn't rule out very much.
+--
       selection (filtering) and various policies, and provides a way to
       monitor the slice.
 
@@ -1366,6 +1407,11 @@
          construct and IETF network slice and necessary according to the
          realization solution, and how traffic should be treated to meet
          the SLOs and SLEs of the connectivity construct.
+--
+jgs: I found the above sub-bullet hard to understand. At minimum it needs
+some repair around "and necessary according", but while you're at it,
+please consider overall readability of the paragraph.
+--
 
    *  Collects telemetry data (e.g., OAM results, statistics, states,
       etc.) via a network configuration interface for all elements in
@@ -1375,6 +1421,11 @@
       parameters using the telemetry data from the underlying
       realization of an IETF Network Slice (i.e., services/paths/
       tunnels).  Exposes this performance to the IETF Network Slice
+--
+jgs: is the forgoing really an "i.e." or is it an "e.g."? I would have  
+thought the latter since otherwise you're prescribing the acceptable
+realization mechanisms.
+--
       service customer via the IETF Network Slice Service Interface.
       The IETF Network Slice Service Interface may also include the
       capability to provide notifications if the IETF Network Slice
@@ -1421,7 +1472,7 @@
 
           +------------------------------------------+
           | Customer higher level operation system   |
-          |   (e.g E2E network slice orchestrator,   |
+          |  (e.g. E2E network slice orchestrator,   |
           |      customer network management system) |
           +------------------------------------------+
                                A
@@ -1686,6 +1737,15 @@
    underlay network.  This could be a physical network, but may be a
    virtual network.  The underlay network is provisioned through network
    controllers that may utilize device controllers [RFC8309].
+--
+jgs: Although RFC 8309 mentions "device controllers" in one place,[*] it
+doesn't define the term anywhere. Possibly a careful read of RFC 8309 would 
+leave me with an understanding of what a "device controller" is, but I 
+don't think it's a clean cite as written.
+
+[*] Third paragraph of Section 1, inconveniently line-broken so a search
+for "device controller" won't find it.
+--
 
    The underlay network may optionally be filtered or customized by the
    network operator to produce a number of network topologies that we
@@ -1693,8 +1753,12 @@
    specific resources (e.g., nodes and links) from the underlay network
    according to their capabilities and connectivity in the underlay
    network.  These actions are configuration options or operator
+--
+jgs: What are "these actions"? Filtering and customization? If so I'd
+suggest writing that instead of "these actions".
+--
    policies that preselect links and nodes with certain performance
-   characteristics to enable more easy construction of NRPs (see below)
+   characteristics to enable easier construction of NRPs (see below)
    that can reliably support specific IETF Network Slice SLAs: for
    example, preselection of links with certain security characteristics,
    preselection of links with specific geographic properties, or mapping
@@ -1742,6 +1806,9 @@
    Realizations of an NRP may be built on a range of existing or new
    technologies, and this document explicitly does not constrain
    solution technologies.
+--
+jgs: You don't really need "explicitly" above, though you do you.
+--
 
    One or more connectivity constructs from one or more IETF Network
    Slices are mapped to an NRP.  A single connectivity construct is
@@ -1818,14 +1885,23 @@
       respond that the slice has or has not been created, and may
       supplement a negative response with information about what it
       could support were the customer to change some requirements.
+--
+jgs: I found the "and supplement a negative response" in the two bullets
+above to be curious. It seems rather open-ended, after all, "change some
+requirements" doesn't leave much out, and the universe of what it
+*could* support might be large. Further, it's a little weird to think
+about how to represent this in a programmatic interface. I would have
+imagined it more straightforward both in representation, and execution,
+to indicate what requirement(s) caused the request to fail.
+--
 
    *  When processing a customer request for an IETF Network Slice
       service, an NSC maps the request to the network capabilities and
       applies provider policies before creating or supplementing the
       NRP.
 
-   Regardless of how IETF Network Slice is realized in the network
-   (i.e., using tunnels of different types), the definition of the IETF
+   Regardless of how a IETF Network Slice is realized in the network
+   (e.g., using tunnels of different types), the definition of the IETF
    Network Slice service does not change at all.  The only difference is
    how the slice is realized.  The following sections briefly introduce
    how some existing architectural approaches can be applied to realize
@@ -1871,6 +1947,13 @@
    services, by utilizing an approach that is based on existing VPN and
    TE technologies and adds characteristics that specific services
    require over and above VPNs as they have previously been specified.
+--
+jgs: depending on what you mean, either "adds" should be "adding", or
+you should make it clear that the final clause is not associated with
+the "by utilizing" part. The latter would most straightforwardly be
+accomplished by putting a period after "TE technologies" and starting
+the resulting new sentence like "It adds..."
+--
 
    An enhanced VPN can be used to provide enhanced connectivity services
    between customer sites and can be used to create the infrastructure
@@ -1926,6 +2009,9 @@
    At this stage, it is inappropriate to mention any of these proposed
    solutions that are currently work in progress and not yet adopted as
    IETF work.
+--
+jgs: I might have said "cite" instead of "mention".
+--
 
 7.6.  Network Slicing and Service Function Chaining (SFC)
 
@@ -2020,6 +2106,12 @@
 
    paths for critical traffic, dedicating specific network resources for
    a selected number of IETF Network Slices.
+--
+jgs: The way that last sentence is written, I *think* what you mean is
+"... reserving backup paths for critical traffic, in other words, dedicating
+specific network resources...". On first reading, it seemed like two 
+unrelated things.
+--
 
 9.  Management Considerations
 
@@ -2044,9 +2136,9 @@
       some aspects of security may be expressed in SLEs.
 
    IETF NSC authentication:  Underlay networks need to be protected
-      against the attacks from an adversary NSC as this could
+      against attacks from an adversary NSC as these could
       destabilize overall network operations.  An IETF Network Slice may
-      span across different networks, therefore, an NSC should have
+      span different networks, therefore, an NSC should have
       strong authentication with each of these networks.  Furthermore,
       both the IETF Network Slice Service Interface and the Network
       Configuration Interface need to be secured.
@@ -2055,7 +2147,7 @@
       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.  In general,
-      isolation is expected to strengthen the IETF Network Slice
+      isolation is expected to strengthen IETF Network Slice
       security.
 
    Data Integrity of an IETF Network Slice:  A customer wanting to
@@ -2094,15 +2186,31 @@
    underlay network (and other) resources from other virtual networks
    sharing those resources.
 
-   For example, if a service requires a specific upper bound of latency,
+   For example, if a service requires a specific upper bound on latency,
    then that service can be degraded by added delay in transmission of
    service packets caused by the activities of another service or
    application using the same resources.
+--
+jgs: my proofreading correction notwithstanding, I don't understand the
+above paragraph.
+--
 
    Similarly, in a network with virtual functions, noticeably impeding
    access to a function used by another IETF Network Slice (for
    instance, compute resources) can be just as service-degrading as
    delaying physical transmission of associated packet in the network.
+--
+jgs: I found this one difficult too. I guess taking the last three 
+paragraphs together, you're saying (paragraph one) virtualization is
+hard, (paragraph two) if you get it wrong you can blow your latency
+SLO, (paragraph three) virtualized upper-layer functions matter too?
+
+To some extent I think none of this needs to be in the SecCons; after
+all, much of the document is *about* providing isolation between 
+different slices. So I for one would be OK with fixing it by reducing
+or cutting the text. But if not, I encourage you to consider whether
+there's some clearer way to put it.
+--
 
 11.  Privacy Considerations
 
@@ -2473,13 +2581,13 @@
 
 Appendix A.  Examples
 
-   This appendix contains realisation examples.  This is mot intended to
-   be a complete set of possible deployments.  Nor does it provide
+   This appendix contains realisation examples.  This is not intended to
+   be a complete set of possible deployments, nor does it provide
    definitive ways to realise these deployments.
 
    The examples shown here must not be considered to be normative.  The
    descriptions of terms and concepts in the body of the document take
-   precedence.  The examples
+   precedence.  
 
 A.1.  Multi-Point to Point Service
 
@@ -2554,7 +2662,7 @@
    constructs (CE1-CE2 and CE2-CE3 represented as *** in the figure).
 
    Alternatively, the service function for the same CE1 to CE3 flow may
-   be hosted at a node within the network operator's.  This is an
+   be hosted at a node within the network operator's infrastructure.  This is an
    ancillary CE in the IETF Network Slice service that the customer
    requests.  This service contains two P2P connectivity constructs
    (CE1-ACE1 and ACE1-CE3 represented as ooo in the figure).  How the
@@ -2566,7 +2674,7 @@
    is able to provide the service function, but not know the location of
    the ancillary CE at which the service function is hosted.  Indeed, it
    may be that the service function is hosted at a number of ancillary
-   CEs (ACE2, ACE3, and ACE4 in the figure): the customer may or know
+   CEs (ACE2, ACE3, and ACE4 in the figure): the customer may know
    the identities of the ancillary CEs, but be unwilling or unable to
    choose one; or the customer may not know about the ancillary CEs.  In
    this case, the IETF Network Slice Service request contains two P2P
@@ -2608,6 +2716,9 @@
    connectivity constructs.
 
    For the P2MP case, does nor specify a single P2MP connectivity
+--
+jgs: Possibly "does nor" was supposed to say "the customer does not"?
+--
    construct (in this case, CE3-{CE1+CE2}), but requests three P2P
    connectivity constructs (as CE3-Hub, Hub-CE1, and Hub-CE2).  It is
    the hub's responsibility to replicate the traffic from CE3 and send
@@ -2776,7 +2887,7 @@
 
    It may be that end-to-end connectivity is achieved using a set of
    cooperating networks as described in Section 5.3.  For example, there
-   may be multiple inter-connected networks that provide the required
+   may be multiple interconnected networks that provide the required
    connectivity as shown in Figure 11.  The networks may utilize
    different technologies and may be under separate administrative
    control.
@@ -2813,7 +2924,7 @@
    are sliced individually and coordination is necessary to deliver the
    desired connectivity.  The network to network interfaces (NNIs) are
    present as SDPs for the IETF Network Slices in each network so that
-   each network is individually sliced.  In the example in Figure 11,
+   each network is individually sliced.  In the example in Figure 12,
    this is illustrated as network 1 (N/w1) being sliced between SDP1 and
    SDPX, N/w2 being sliced between SDPY and SDPU, etc.  The coordination
    activity involves binding the SDPs, and hence the connectivity
@@ -2837,6 +2948,11 @@
                        with Inter- connected Networks
 
    The controller/coordinator relationship is shown in Figure 13.
+--
+jgs: It seems as though the "coordinator" construct introduced here
+deserved to get a paragraph in the main body text, instead of being
+relegated to a casual mention in a sub-appendix.
+--