Re: [auth48] AUTH48: RFC-to-be 9543 <draft-ietf-teas-ietf-network-slices-25> for your review

[Adrian Farrel <[e-mail]>]

Thanks Shunsuke,

 

I’ll take advice from the RFC Editor on both these points.

 

3GPP: I think we can point to a specific version, and we should use those that are in force at the time the RFC is published

 

ORAN: The “show latest” didn’t work on my browser (cookies?), but if it works for Shunsuke it probably works for others. If this is the case, we should:

*	Point to the version in force at the time the RFC is published
*	Include the link to the page with the box checked

 

Cheers,

Adrian

 

From: Shunsuke Homma <[e-mail]> 
Sent: 18 February 2024 04:28
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9543 <draft-ietf-teas-ietf-network-slices-25> for your review

 

Hi Adrian,

Thank you for your work on this. All of your replies make sense to me. 

I have a question on references of 3GPP documents. They have several major versions and they seem to be continuously updated. So, should it be indicated which version is referred to in this RFC?


By the way, regarding ORAN documents, you can find past documents by clearing the check box for  "show latest". (But I'm OK to remove the version number and date because it is updated frequently.)

 

Regards,

 

Shunsuke

 

On Sun, Feb 18, 2024 at 6:19 AM Adrian Farrel <[e-mail] <mailto:[e-mail]> > wrote:

Hey!

Thanks for this work. I'm responding here without having read Shunsuke's email.

I'll get to that "soon".

In line...

Cheers,
Adrian

1) <!-- [rfced] FYI - In this sentence, we updated the last item in the series
(i.e., "how abstract requests...") to create parallel structure. Please
review and let us know any objections.

Original:
   The document discusses the general framework for requesting and
   operating IETF Network Slices, the characteristics of an IETF Network
   Slice, the necessary system components and interfaces, and how
   abstract requests can be mapped to more specific technologies.

Current:
   The document discusses the general framework for requesting and
   operating IETF Network Slices, the characteristics of an IETF Network
   Slice, the necessary system components and interfaces, and the
   mapping of abstract requests to more specific technologies.   
-->

Sure.

2) <!-- [rfced] Please review "described...described". Would you like to replace
one of these with another word?

Original:
   ...the qualifying term "IETF" is used in this document to limit the scope of
   the network slices described to network technologies described and
   standardized by the IETF.

Perhaps (change one instance of "described" to "defined"): 
   ...the qualifying term "IETF" is used in this document to limit the scope of
   the network slices described to network technologies defined and standardized
   by the IETF.

Or (remove first "described"):
   ...the qualifying term "IETF" is used in this document to limit the scope of
   network slices to network technologies described and standardized
   by the IETF.
-->

Yeah, I prefer the 2nd 'described' over 'defined' for various reasons of fact.
So the second option (remove the first 'described') is better.

3) <!-- [rfced] May we update "per {IETF Network Slice Service, connectivity
construct, and SLOs/SLEs} basis" as follows?

Original:
   The customer and provider may
   agree on a per {IETF Network Slice Service, connectivity
   construct, and SLOs/SLEs} basis to police or shape traffic on the
   AC in both the ingress (CE to PE) direction and egress (PE to CE)
   direction. 

Perhaps: 
   The customer and provider may agree to police or shape traffic (based on
   the specific IETF Network Slice Service, connectivity construct, and
   SLOs/SLEs) on the AC in both the ingress (CE to PE) direction and egress
   (PE to CE) direction.
-->

Yours is better, but still splits 'police or shape' from 'on the AC' which is lumpy.
How about...
   The customer and provider may agree to police or shape traffic on the AC
   in both the ingress (CE to PE) direction and egress (PE to CE) direction. This
   policing and shaping is based on the specific IETF Network Slice Service,
   connectivity construct, and SLOs/SLEs)

4) <!-- [rfced] Would updating as follows improve readability of this long
sentence?

Original:
   A clear distinction should be made between the "IETF Network Slice
   Service" which is the function delivered to the customer (see
   Section 4.2) and which is agnostic to the technologies and mechanisms
   used by the service provider, and the "IETF Network Slice" which is
   the realization of the service in the provider's network achieved by
   partitioning network resources and by applying certain tools and
   techniques within the network (see Section 4.1 and Section 7).

Perhaps:
  A clear distinction should be made between the IETF Network Slice
  Service and the IETF Network Slice:

  IETF Network Slice Service: The function delivered to the customer 
     (see Section 4.2). It is agnostic to the technologies and 
     mechanisms used by the service provider.

  IETF Network Slice: The realization of the service in the provider's 
     network achieved by partitioning network resources and by applying 
     certain tools and techniques within the network (see Sections 4.1 
     and 7).
-->

Yes

5) <!-- [rfced] Would using bullets make this text easier to read? Or do you
prefer the current?

Original:
   That is, in a given IETF
   Network Slice Service there may be one or more connectivity
   constructs of the same or different type, each connectivity construct
   may be between a different subset of SDPs, for a given connectivity
   construct each sending SDP has its own set of SLOs and SLEs, and the
   SLOs and SLEs in each set may be different. 

Perhaps:
   That is, in a given IETF Network Slice Service:

   *  There may be one or more connectivity constructs of the same
      or different type.

   *  Each connectivity construct may be between a different subset of
      SDPs

   *  For a given connectivity construct, each sending SDP has its own
      set of SLOs and SLEs.

   *  The SLOs and SLEs in each set may be different. 
-->

Almost.
I think the 'set' in the last bullet has lost context. So make it:
    * The SLOs and SLEs in each set of SDPs may be different.

6) <!-- [rfced] Please review "That is, and in particular" in the second sentence
below (first sentence is included for context). Should this read simply
"That is" or "In particular"?

Original:
   From the above, it can be seen that the SLOs of the senders define
   the SLOs for the receivers on any connectivity construct.  That is,
   and in particular, the network may be expected to handle the traffic
   volume from a sender to all destinations.  This extends to all
   connectivity constructs in an IETF Network Slice Service.

Perhaps: 
   From the above, it can be seen that the SLOs of the senders define
   the SLOs for the receivers on any connectivity construct.  That is,
   the network may be expected to handle the traffic
   volume from a sender to all destinations.  This extends to all
   connectivity constructs in an IETF Network Slice Service.

Or:
   From the above, it can be seen that the SLOs of the senders define
   the SLOs for the receivers on any connectivity construct.  
   In particular, the network may be expected to handle the traffic
   volume from a sender to all destinations.  This extends to all
   connectivity constructs in an IETF Network Slice Service.
-->

Mutter, mutter. Authors who want to stress things when it is enough to just say them :-)

Your first option ('That is')

7) <!-- [rfced] Please clarify the text starting with "and commercial
terms...". Also, may we split up this long sentence to improve
readability?

Original:
      The SLA is expressed in terms of a set
      of SLOs and SLEs that are to be applied for a given connectivity
      construct between a sending SDP and the set of receiving SDPs, and
      may describe the extent to which divergence from individual SLOs
      and SLEs can be tolerated, and commercial terms as well as any
      consequences for violating these SLOs and SLEs.

Perhaps:
      The SLA is expressed in terms of a set
      of SLOs and SLEs that are to be applied for a given connectivity
      construct between a sending SDP and the set of receiving SDPs.
      The SLA may describe the extent to which divergence from individual SLOs
      and SLEs can be tolerated, commercial terms, and any
      consequences for violating these SLOs and SLEs.
-->

New...
      The SLA is expressed in terms of a set
      of SLOs and SLEs that are to be applied for a given connectivity
      construct between a sending SDP and the set of receiving SDPs.
      The SLA may also describe the extent to which divergence from individual
      SLOs and SLEs can be tolerated, the commercial terms, and any
      consequences for violating these SLOs and SLEs.

8) <!-- [rfced] Please clarify how the phrase "and specifying..." connects to the
rest of the sentence.

Original:
      Availability will often be expressed along with the time period
      over which the availability is measured, and specifying the
      maximum allowed single period of downtime.

Perhaps: 
      Availability will often be expressed along with the time period
      over which the availability is measured and the
      maximum allowed single period of downtime.

Or:
      Availability will often be expressed along with the time period
      over which the availability is measured and will specify the
      maximum allowed single period of downtime.
-->

New...
      Availability will often be expressed along with the time period
      over which the availability is measured. The expression of
      availability may also include the specification of the
      maximum allowed single period of downtime.

9) <!-- [rfced] Would it be helpful to clarify "e.g., [RFC4303]" by including the
name of the mechanism in RFC 4303 as shown below? Similarly, would it
helpful to also clarify "for compliance with [HIPAA] or [PCI]" as shown below?

Original:
   This SLE may include a request for encryption (e.g., [RFC4303])
   between the two SDPs explicitly to meet the architectural
   recommendations in [TS33.210] or for compliance with [HIPAA] or
   [PCI].

Perhaps:
   This SLE may include a request for encryption (e.g., the Encapsulating
   Security Payload (ESP) protocol [RFC4303])
   between the two SDPs explicitly to meet the architectural
   recommendations in [TS33.210] or for compliance with the HIPAA Security Rule [HIPAA] or
   the PCI Data Security Standard (PCI DSS) [PCI].
-->

Sure

10) <!-- [rfced] We updated "gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses" in
the first sentence below as follows.  Please review to ensure
correctness.

Also, would it be helpful to update "ProtoBufs" to "Protocol Buffers" in the
second sentence? Or do you prefer the current?

Original:
   *  gRPC/GNMI [I-D.openconfig-rtgwg-gnmi-spec] uses a binary encoded
      programmable interface.  ProtoBufs can be used to model gRPC and
      GNMI data.

Current:
   *  gRPC and gRPC Network Management Interface (gNMI) [GNMI] use a
      binary encoded programmable interface.  ProtoBufs can be used to
      model gRPC and gNMI data.      
-->

Hmmm, I think most people say protobuf even if the formal name is still Protocol Buffer.
Apparently, it is a small 'b'
So (note additional definite article)...

   *  gRPC and the gRPC Network Management Interface (gNMI) [GNMI] use a
      binary encoded programmable interface.  Protobufs can be used to
      model gRPC and gNMI data.

11) <!-- [rfced] We do not see "Network Model" in RFC 8309, though we do see
"Service Model", "Network Service Model", and "Network Element Model".
Please review and let us know if any updates are needed.

Original:
   These interfaces can be considered in the context of the Service
   Model and Network Model described in [RFC8309] and, together with the
   Device Configuration Interface used by the Network Controllers,
   provides a consistent view of service delivery and realization.
-->

<Red face>
s/Network Model/Network Configuration Model/

12) <!-- [rfced] How may we update the "/" here? 

Original:
   Recall that an IETF Network Slice is a service requested by /
   provided for the customer.

Perhaps: 
   Recall that an IETF Network Slice is a service requested by and/or
   provided for the customer.
-->

Hmm. OK, if it must be replaced, please use a simple 'and', as...

   Recall that an IETF Network Slice is a service requested by and
   provided for the customer.

13) <!-- [rfced] FYI - We see that draft-ietf-teas-enhanced-vpn no longer uses the
abbreviation "VPN+" (looks like it was removed in version -16). We have
thus removed "VPN+" in the following sentences.

See https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/.

Original:
   An enhanced VPN (VPN+) is designed to support the needs of new
   applications, particularly applications that are associated with 5G
   services.
   . . . . . . . 
   [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced
   Virtual Private Network (VPN+) services.

Current:
   An enhanced VPN is designed to support the needs of new
   applications, particularly applications that are associated with 5G
   services. 
   . . . . . . . 
   [ENHANCED-VPN] describes the framework for Enhanced Virtual Private
   Network services.
-->

Good catch, thanks. This was supposed to reach you as an RFC Editor Note, but the poor baby got lost in the woods.

Your change is good.

14) <!-- [rfced] Please review the parentheses in "(part of)". Should the
parentheses be removed, or should the phrase be moved and revised as
shown below?

Current:
      Generate SFC classification rules to identify (part of) the slice
      traffic that will be bound to an SFC.

Perhaps (remove parentheses):
     Generate SFC classification rules to identify part of the slice
     traffic that will be bound to an SFC.

Or (move and revise parenthetical):
     Generate SFC classification rules to identify the slice
     traffic (or part of it) that will be bound to an SFC.
-->

I prefer the current, but I can live with your second option (move and revise)

15) <!-- [rfced] May we update the text starting with "a robust..." as follows?

Current:
      Furthermore, both the
      IETF Network Slice Service Interface and the Network Configuration
      Interface need to be secured with a robust authentication and
      authorization; and associated auditing mechanism.

Perhaps:
     Furthermore, both the
     IETF Network Slice Service Interface and the Network Configuration
     Interface need to be secured with a robust authentication and
     authorizations mechanism and an associated auditing mechanism.
-->

Hmmm,
New...
     Furthermore, both the
     IETF Network Slice Service Interface and the Network Configuration
     Interface need to be secured with robust authentication and
     authorization mechanisms, and with an associated auditing mechanism.

16) <!-- [rfced] Please review whether this "Note:" should be in the <aside>
element. It is defined as "a container for content that is semantically
less important or tangential to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).

Current:
   Note: See [NGMN_SEC] on 5G network slice security for discussion
   relevant to this section.
-->

Sure, I am still reading the XML2RFC v3 manual :-)

17) <!-- [rfced] Please review the URL for the following reference. It returns the
error: "Sorry, the post you are looking for is not available". May we
update to use one of these URLs below instead?

https://www.ngmn.org/publications/description-of-network-slicing-concept.html
https://ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf

Original:
   [NGMN-NS-Concept]
              NGMN Alliance, "Description of Network Slicing Concept",
              https://www.ngmn.org/uploads/
              media/161010_NGMN_Network_Slicing_framework_v1.0.8.pdf ,
              2016.
-->

I'll take https://ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf

18) <!-- [rfced] New versions are available for the following 3GPP
references. Would you like to cite the latest version, or would do you
prefer the current?

a) Latest version is 18.4.0 with date of 2023:
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144

Original:
   [TS23501]  3GPP, "System architecture for the 5G System (5GS)", 3GPP
              TS 23.501, 2019.

Perhaps:
   [TS23.501]  3GPP, "System architecture for the 5G System (5GS)", 3GPP
               TS 23.501, 2023.

b) Latest version is 18.0.0 with date of 2024:
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3273

Original:
   [TS28530]   3GPP, "Management and orchestration; Concepts, use cases
               and requirements", 3GPP TS 28.530, 2019.

Perhaps:
   [TS28.530]  3GPP, "Management and orchestration; Concepts, use cases
               and requirements", 3GPP TS 28.530, 2024.
-->

Take the latest in both cases

19) <!-- [rfced] The URL below does not go directly to PCI DSS, though readers can
use the search feature to find it. Would it be helpful to include the
following link instead? Also, we see that the latest version of PCI DSS is
dated March 2022. Would you like to update the date accordingly?

Original:
   [PCI]      PCI Security Standards Council, "PCI DSS", May 2018,
              <https://www.pcisecuritystandards.org>.

Perhaps:
   [PCI]      PCI Security Standards Council, "PCI DSS", March 2022,
              <https://www.pcisecuritystandards.org/document_library/>.
-->

We should go all the way to...
https://www.pcisecuritystandards.org/document_library/?document=pci_dss
(but no further because the documents all require a license agreement)

20) <!-- [rfced] We see that the O-RAN Slicing Architecture has a newer version
than the one listed in the following reference entry. Would you like to
cite the more recent version (version 11.0 with date of October 2023)?

Also, we're having trouble determining what title is correct here. Would the
following be better, or do you prefer the current?

Current:
   [ORAN]     O-RAN, "O-RAN Working Group 1 Slicing Architecture",
              O-RAN.WG1 v06.00, 2022,
              <https://orandownloadsweb.azurewebsites.net/
              specifications>.

Perhaps:
   [ORAN]     O-RAN, "O-RAN Work Group 1 (Use Cases and Overall 
              Architecture): Slicing Architecture",
              O-RAN.WG1.Slicing-Architecture-R003-v11.00, October 2023, 
              <https://orandownloadsweb.azurewebsites.net/
              specifications>.
-->

Ah, the document title is "Slicing Architecture" the source is "O-RAN Work Group 1 (Use Cases and Overall Architecture)"
And we just can't keep up! I find v12.0 came out earlier this month. 
The trouble with the ORAN site is that it will keep updating to the latest revision and the old ones will go away.
That is highly annoying because it means they can change the content under our feet, and we cannot safely reference a version of the document.
The use we make of the document, however, and the content of their architecture suggest that we should simply leave out the version number *and* date, as...

   [ORAN]     O-RAN Working Group 1 (Use Cases and Overall Architecture), 
              "Slicing Architecture", O-RAN.WG1.Slicing-Architecture-R003
              <https://orandownloadsweb.azurewebsites.net/
              specifications>.

21) <!-- [rfced] Would it be helpful to add a colon after "constructs" and move
the open parentheses to appear before "represented"?

Original:
   To achieve this, the customer may request
   an IETF Network Slice Service comprising two P2P connectivity
   constructs (CE1-CE2 and CE2-CE3 represented as *** in the figure).
   ...
   This service contains two P2P connectivity
   constructs (CE1-ACE1 and ACE1-CE3 represented as ooo in the figure).
   ...
   In this
   case, the IETF Network Slice Service request contains two P2P
   connectivity constructs (CE1-ServiceFunction and ServiceFunction-CE3
   represented as xxx in the figure).  

Perhaps:
   To achieve this, the customer may request
   an IETF Network Slice Service comprising two P2P connectivity
   constructs: CE1-CE2 and CE2-CE3 (represented with "*" in
   Figure 6).
   ...
   This service contains two P2P connectivity
   constructs: CE1-ACE1 and ACE1-CE3 (represented with "o" in
   Figure 6).
   ...
   In this case, the IETF Network Slice Service request contains two P2P
   connectivity constructs: CE1-ServiceFunction and ServiceFunction-CE3
   (represented with "x" in Figure 6).  
-->

Don't mind the colon and parentheses. Slightly prefer using the multiple symbols (xxx etc.) in particular because the character 'o' has a habit of turning up in text and so causing confusion.

22) <!-- [rfced] Please review the quotation marks with "stacking" here. Are the
quotation marks necessary?

Original:
   This "stacking" of IETF Network Slice constructs is not different to
   the way virtual networks may be arranged.
-->

Not absolutely necessary. 

23) <!-- [rfced] In the Contributors section, we updated <artwork> to
<contact>. The parenthetical with Eric Gray's entry looks odd in the txt
output because it appears closer to Jari's name than to Eric's name. The
html and pdf outputs look better. To avoid any possible confusion, we
suggest moving the parenthetical to the introductory text as
follows. Please review and let us know your thoughts.

Current:
   The following authors contributed significantly to this document:

   Eric Gray
   Retired


   (The original editor of the foundation documents)

   Jari Arkko
   Ericsson
   Email: [e-mail] <mailto:[e-mail]> 

Perhaps:
   The following people contributed substantially to the content of this
   document and should be considered coauthors. Eric Gray was the original
   editor of the foundation documents.

   Eric Gray
   Retired

   Jari Arkko
   Ericsson
   Email: [e-mail] <mailto:[e-mail]> 
-->

Yes, if the tools won't let you do it, and if artwork is not allowed, you have the right solution.

24) <!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

   IETF network slicing vs. IETF Network Slicing
IETF network slicing
   network controller vs. Network Controller
network controller (except, of course, in the hangText in 6.1)
   orchestrator vs. Orchestrator
orchestrator
   "Mapping Functions" vs. mapping functions
I believe the current text is fine
   "stitched together" vs. stitched together
I think you are asking:
   "stitched" together vs. stitched together
stitched together

b) Please review "hub and spoke" and "hub-and-spoke" in the following. May we
update these to "hub-and-spoke topology"? Other options include "hub-and-spoke
configuration" (one instance in document) and "hub-and-spoke
architecture" (one instance in document).

Original:
   A.3.  Hub and Spoke
   ...
   Hub and spoke is a popular way to realize any-to-any connectivity in
   support of multiple P2P traffic flows ...
   ...
   In many cases, it is the network operator's choice
   whether to use hub and spoke to realize a mesh of P2P connectivity
   constructs or P2MP connectivity constructs:
   ...
   Figure 7: Example Hub and Spoke Under Customer Control
   ...
      With a P2MP or A2A connectivity construct, it is the operator's
      choice whether to realize the construct with ingress replication,
      multicast in the core, P2MP tunnels, or hub-and-spoke.

Perhaps:
   A.3.  Hub-and-Spoke Topology
   ...
   A hub-and-spoke topology is a popular way to realize any-to-any connectivity in
   support of multiple P2P traffic flows ...
   ...
   In many cases, it is the network operator's choice
   whether to use a hub-and-spoke topology to realize a mesh of P2P connectivity
   constructs or P2MP connectivity constructs:
   ...
   Figure 7: Example Hub-and-Spoke Topology under Customer Control
   ...
      With a P2MP or A2A connectivity construct, it is the operator's
      choice whether to realize the construct with ingress replication,
      multicast in the core, P2MP tunnels, or a hub-and-spoke topology.

Yes, that's good

c) FYI - We capitalized a few instances of "IETF network slice" based on the
definition in the abstract.

Oh wow, thank you. Notwithstanding me having checked for this specific issue twice!

d) FYI - We added expansions for the following abbreviations. Please review and
let us know if there are any objections.

   eMBB - enhanced Mobile Broadband 
   gNMI - gRPC Network Management Interface
   mMTC - massive Machine Type Communications
   MAC - Media Access Control
   MACsec - Media Access Control Security
   URLLC - Ultra-Reliable and Low Latency Communications
   OAM - Operations, Administration, and Maintenance

All good, thanks

-->

25) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this should 
still be reviewed as a best practice.

-->

Are you allowed to use 'to flag'? 
I'm pretty careful with the language these days, which is possibly why your script finds nothing.

Thank you.

No! Thank you!