Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!-- [rfced] We updated the abbreviated title (only appears in the running
header in the PDF output) as follows to more closely align with the
document title. Please let us know if you prefer otherwise.
Original:
Implementing 5G Transport Slices
Updated:
Realization of Network Slices for 5G Networks
-->
2) <!-- [rfced] This is a question for Luis. How would you like for your
initials
to appear in the first-page header? For now, we have updated to
"L. Contreras" per the format used in the most recent documents you have
authored, but we see that some documents use "LM. Contreras" in the
first-page header.
L. Contreras - RFCs 9543, 9439, 9013
LM. Contreras - RFCs 8597, 8568, 8432, 7161, 7028
-->
3) <!-- [rfced] How may we update these sentences to improve readability of "5G
slicing connectivity service objectives" and "currently commonly"?
Original:
This document describes a Network Slice realization model for IP/MPLS
networks with a focus on the Transport Network fulfilling 5G slicing
connectivity service objectives. The realization model reuses many
building blocks currently commonly used in service provider networks.
Perhaps:
This document describes a Network Slice realization model for IP/MPLS
networks with a focus on the Transport Network fulfilling the connectivity
service objectives for 5G slicing. The realization model reuses many
building blocks commonly used in service provider networks at the current
time.
-->
4) <!-- [rfced] Section 1 of RFC 9543 notes the following:
It is intended that the terms "IETF Network Slice" and "IETF Network
Slice Service" be used only in this document. Other documents that
need to indicate the type of network slice or network slice service
described in this document can use the terms "RFC 9543 Network Slice"
and "RFC 9543 Network Slice Service".
Based on this, should "IETF Network Slice Service" and "IETF Network Slice" in
the sentences below be updated to "RFC 9543 Network Slice Service" and "RFC
9543 Network Slice", respectively?
Original:
Mapping
considerations between 3GPP and IETF Network Slice Service (e.g.,
mapping of service parameters) are discussed, e.g., in
[I-D.ietf-teas-5g-network-slice-application].
...
Data Confidentiality and Integrity of an IETF Network Slice: As desc
ribed in Section 5.1.2.1 of [RFC9543], the customer might request
a Service Level Expectation (SLE) that mandates encryption.
-->
5) <!-- [rfced] We have a few questions about the sentence below (which is also
mentioned in the question above).
a) How may we revise "Mapping considerations between 3GPP and IETF Network
Slice Service" to improve clarity?
b) Is the second "e.g." needed?
Original:
Mapping
considerations between 3GPP and IETF Network Slice Service (e.g.,
mapping of service parameters) are discussed, e.g., in
[I-D.ietf-teas-5g-network-slice-application].
Perhaps:
Considerations regarding the mapping between the 5G Network Slice Service
and RFC 9543 Network Slice Service (e.g., mapping of service parameters)
are discussed in [NS-APP].
-->
6) <!-- [rfced] Figure 4 contains "SW" and "RTR", which are not used elsewhere
in
the document. We believe these stand for "switch" and "router", respectively.
May we update this sentence in one of the following ways to make this clear?
Original:
An example of distributed CE is the
realization of an interconnection using a L3VPN service based on a
distributed CE composed of a switch (Layer 2) and a router (Layer 3)
(Figure 4).
Perhaps:
An example of distributed CE is the
realization of an interconnection using an L3VPN service based on a
distributed CE composed of a switch (SW) in Layer 2 and a router (RTR)
in Layer 3, as shown in Figure 4.
Or:
An example of distributed CE is the
realization of an interconnection using an L3VPN service based on a
distributed CE composed of a switch (Layer 2) and a router (Layer 3);
see SW and RTR in Figure 4.
-->
7) <!-- [rfced] Are the two instances of "(AC)" needed here?
Original:
Examples of ACs are Virtual Local Area
Networks (VLANs) (AC) configured on a physical interface (bearer) or
an Overlay VXLAN EVI (AC) configured on an IP underlay (bearer).
Perhaps:
Examples of ACs are Virtual Local Area
Networks (VLANs) configured on a physical interface (bearer) or
an Overlay VXLAN EVI configured on an IP underlay (bearer).
-->
8) <!-- [rfced] Is "End-to-End" intended to be part of the expansion for "5G
NSO"?
Original:
In reference to Figure 6, a 5G End-to-End Network Slice Orchestrator
(5G NSO) is responsible for orchestrating 5G Network Slices end-to-
end.
Perhaps:
In Figure 6, a 5G Network Slice Orchestrator
(5G NSO) is responsible for orchestrating 5G Network Slices end-to-
end.
-->
9) <!-- [rfced] Should "various orchestration" in this sentence be updated to
either "various orchestration domains" or "various orchestrations"? Also,
is "e.g." needed in the sentence?
Original:
The various orchestration depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned, e.g., in
Figure 5 of [I-D.ietf-teas-5g-network-slice-application].
Perhaps:
The various orchestration domains depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned in
Figure 5 of [NS-APP].
Or:
The various orchestrations depicted in Figure 6 encompass the 3GPP's
Network Slice Subnet Management Function (NSSMF) mentioned in
Figure 5 of [NS-APP].
-->
10) <!-- [rfced] Will readers understand the ">>" notation here?
We see it defined as "bitwise right shift", "logical right shift",
and "arithmetic right shift of the two's complement integer representation
of M by N binary digits" in various RFCs.
Original:
In practice, for operational and scaling reasons, typically M to N
would be used, with M >> N.
-->
11) <!-- [rfced] Titles of figures
a) Should "Site" be plural in this title as Figure 3 shows two sites?
Original:
Figure 3: Reference Design with Customer Site and Provider Network
Perhaps:
Figure 3: Reference Design with Customer Sites and Provider Network
b) Should the title of Figure 9 use "M" rather than "N"? We ask because
"N to 1" is not included in the list above the figure. The list only includes
"1 to N", "M to 1", and "M to N". Also, may revise the titles of Figures 8 and 9
in one of the following ways to improve readability?
Original:
Figure 8: 1 (5G Slice) to N (TN Slice) Mapping
Figure 9: N (5G Slice) to 1 (TN Slice) Mapping
Perhaps:
Figure 8: 1-to-N Mapping
Figure 9: M-to-1 Mapping
Or:
Figure 8: 1-to-N Mapping (Single 5G Slice to Multiple TN Slices)
Figure 9: M-to-1 Mapping (Multiple 5G Slices to Single TN Slice)
c) FYI - We added "Example of" to the title of Figure 16 to align with the
title of Figure 15.
Original:
Figure 15: Example of MPLS Hand-off with Option B
Figure 16: MPLS Hand-off with Option C
Updated:
Figure 15: Example of MPLS Handoff with Option B
Figure 16: Example of MPLS Handoff with Option C
d) Is "Ingress" correct in the title of Figure 21, or should it be updated to
"Egress"? Also, is "Output" needed? We included the title of Figure 20 below
for comparison.
Original:
Figure 20: Ingress Slice Admission Control (5QI-unaware Model)
Figure 21: Ingress Slice Admission control (5QI-unaware Model) - Output
Perhaps:
Figure 20: Ingress Slice Admission Control (5QI-Unaware Model)
Figure 21: Egress Slice Admission Control (5QI-Unaware Model)
e) FYI - We included "Model" to the parenthetical in these figure titles.
Original:
Figure 25: Ingress Slice Admission Control (5QI-Aware) - Hierarchical
Figure 26: Egress Slice Admission Control (5QI-Aware)
Perhaps:
Figure 25: Ingress Slice Admission Control (5QI-Aware Model) - Hierarchical
Figure 26: Egress Slice Admission Control (5QI-Aware Model)
f) We revised the figure titles below as follows to avoid awkward hyphenation
with "Mapping". For Figure 28, we also removed "PEs" for consistency with the
title of Figure 29.
For the title of Figure 17, should "Slice" be updated to "Network Slice", or
is the current okay?
Original:
Figure 17: Slice to TN QoS Mapping (5QI-Unaware Model)
Figure 22: Slice 5Q QoS to TN QoS Mapping (5QI-Aware Model)
Figure 28: Network Slice to PEs Underlay Transport Mapping (5QI-Unaware Model)
Figure 29: Network Slice to Underlay Transport Mapping (5QI-Aware Model)
Updated:
Figure 17: Mapping of Slice to TN QoS (5QI-Unaware Model)
Figure 22: Mapping of Slice 5Q QoS to TN QoS (5QI-Aware Model)
Figure 28: Mapping of Network Slice to Underlay Transport (5QI-Unaware Model)
Figure 29: Mapping of Network Slice to Underlay Transport (5QI-Aware Model)
-->
12) <!-- [rfced] Is "to instruct" the correct word choice here? Or would "to
determine" or something else be an improvement?
Original:
TN slice mapping policies can be enforced by an operator (e.g.,
provided to a TN Orchestration or 5G NSO) to instruct whether
existing TN slices can be reused for handling a new slice service
creation request.
Perhaps:
TN slice mapping policies can be enforced by an operator (e.g.,
provided to a TN Orchestration or 5G NSO) to determine whether
existing TN slices can be reused for handling a new slice service
creation request.
-->
13) <!-- [rfced] This sentence may be difficult for readers to follow because of
the many "to.." phrases. How may we update?
Original:
The methods used here can range from careful network planning, to
ensure a more or less equal traffic distribution (i.e., equal cost
load balancing), to advanced TE techniques, with or without
bandwidth reservations, to force more consistent load distribution
even in non-ECMP friendly network topologies.
Perhaps:
The methods used here can range from careful network planning that
ensures a more or less equal traffic distribution (i.e., equal-cost
load balancing) to advanced TE techniques, with or without
bandwidth reservations, that force more consistent load distribution,
even in non-ECMP-friendly network topologies.
-->
14) <!-- [rfced] We do not see "F2" used elsewhere in the document. Will readers
understand what this refers to?
Original:
Since the 5G
interfaces are IP-based interfaces (with an exception of the F2
fronthaul-interface, where eCPRI with Ethernet encapsulation is
used), this VLAN is typically not transported across the provider
network.
-->
15) <!-- [rfced] Please confirm that "compute" (noun) is the correct word choice
here.
Original:
These L3VPN service instances are instantiated in
the customer site which could be, for example, either on the compute
that hosts mobile NFs (Figure 15, left-hand side) or within the DC/
cloud infrastructure itself (e.g., on the top of the rack or leaf
switch within cloud IP fabric (Figure 15, right-hand side)).
-->
16) <!-- [rfced] Should "COM-1" here be updated to "COM=1" to match the usage in
Figure 15?
Original:
For example, in Figure 15, for the slice identified with
COM-1, the PE advertises a dynamically allocated label A".
Perhaps:
For example, in Figure 15, for the slice identified with
COM=1, the PE advertises a dynamically allocated label A".
-->
17) <!--[rfced] Please clarify "label swap forwarding entries" in this sentence.
Original:
Appropriate label swap forwarding entries
for IPv4/IPv6 labeled unicast labels are programmed in the data
plane.
Perhaps:
Appropriate label swaps of forwarding entries
for IPv4/IPv6 labeled unicast labels are programmed in the data
plane.
Or:
Appropriate forwarding entries for label swaps
for IPv4/IPv6 labeled unicast labels are programmed in the data
plane.
-->
18) <!-- [rfced] How does the text starting with "used as NEXT_HOP..." connect
to
the rest of the sentence?
Original:
This significantly lowers the scaling pressure on
PEs, as PEs need to program forwarding entries only for IPv4/IPv6
labeled unicast host routes, used as NEXT_HOP for service prefixes.
Perhaps:
This significantly lowers the scaling pressure on
PEs, as PEs need to program forwarding entries only for IPv4/IPv6
labeled unicast host routes, which are used as NEXT_HOP for service prefixes.
-->
19) <!-- [rfced] The sentence below uses "SRv6 encapsulation" while the title of
Figure 19 uses "IPv6 Encapsulation". Should these be consistent? If so,
which form should be used?
Original:
This model is outlined in Figure 18 for MPLS
encapsulation, and in Figure 19 for SRv6 encapsulation.
...
Figure 19: QoS with IPv6 Encapsulation
-->
20) <!-- [rfced] Is the citation [I-D.ietf-teas-ietf-network-slice-nbi-yang]
correct here? We ask because we do not see "slice rate", "CIR", or "PIR"
in that document.
Link to document:
https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang/
Original:
The slice rates can be characterized with following parameters
[I-D.ietf-teas-ietf-network-slice-nbi-yang]:
* CIR: Committed Information Rate (i.e., guaranteed bandwidth)
* PIR: Peak Information Rate (i.e., maximum bandwidth)
-->
21) <!-- [rfced] Please confirm that Section 2.3 of [RFC2475] is correct here.
We
do not see "1r2c", "color", or "single rate" in [RFC2475].
Original:
* 1r2c (single-rate two-color) rate limiter
This is the most basic rate limiter, described in Section 2.3 of
[RFC2475].
-->
22) <!-- [rfced] We updated "provider" to "provider network" in the
parenthetical
in this sentence. Let us know if this is incorrect.
Original:
Inbound provider network edge enforcement model for 5QI-unaware
model, where all packets belonging to the slice are treated the same
way in the provider network (no 5Q QoS Class differentiation in the
provider) is outlined in Figure 20.
Perhaps:
Inbound provider network edge enforcement for the 5QI-unaware
model, where all packets belonging to the slice are treated the same
way in the provider network (no 5Q QoS Class differentiation in the
provider network), is outlined in Figure 20.
-->
23) <!-- [rfced] Please clarify "most commonly up 4 or 8 traffic classes".
(Also, we suggest removing "granular" as it's redundant with "fine-grained".)
Original:
In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more granular, fine-
grained manner, with dedicated resource allocation for each RFC 9543
Network Slice and dedicated resource allocation for number of traffic
classes (most commonly up 4 or 8 traffic classes, depending on the
Hardware capability of the equipment) within each RFC 9543 Network
Slice.
Perhaps:
In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more fine-grained
manner, with dedicated resource allocation for each RFC 9543
Network Slice and for a number of traffic
classes (most commonly, 4 or 8 traffic classes, depending on the
hardware capability of the equipment) within each RFC 9543 Network
Slice.
Or:
In the 5QI-aware model, compared to the 5QI-unaware model, provider
network edge resources are controlled in an even more fine-grained
manner, with dedicated resource allocation for each RFC 9543
Network Slice and for a number of traffic
classes (most commonly, up to 4 or 8 traffic classes, depending on the
hardware capability of the equipment) within each RFC 9543 Network
Slice.
-->
24) <!-- [rfced] May we update "2024" as follows in these sentences?
Original:
However, such an approach is left out of the scope given the current
state of the technology (2024).
...
it is not necessary (or indeed possible for
current SR-TE technology in 2024) to reserve bandwidth at the network
layer.
Perhaps:
However, such an approach is out of the scope given the current
state of the technology at the time of writing this document.
...
it is not necessary (or indeed possible for
current SR-TE technology at the time of writing this document) to reserve
bandwidth at the network layer.
-->
25) <!-- [rfced] We updated "[I-D.ietf-teas-ietf-network-slice-nbi-yang]" in
these
sentences to "the YANG data model defined in [NSSM]" for clarity. Let us
know any concerns.
Original:
[I-D.ietf-teas-ietf-network-slice-nbi-yang] can be used to convey all
of the information in the traffic matrix to an NSC.
...
...could be used instead of
[I-D.ietf-teas-ietf-network-slice-nbi-yang], as they support
conveying the bandwidth information in the right-most column of the
traffic matrix.
...
The 5G NSO can
use [I-D.ietf-teas-ietf-network-slice-nbi-yang] to request low-
latency transport for a given slice if required.
...
For example,
[I-D.ietf-teas-ietf-network-slice-nbi-yang] exposes a set of
statistics per SDP, connectivity construct, and connection group.
Updated:
The YANG data model defined in [NSSM] can be used to convey all of
the information in the traffic matrix to an NSC.
...
...could be used instead of the YANG
data model defined in [NSSM], as they support conveying the bandwidth
information in the right-most column of the traffic matrix.
...
The 5G NSO can
use the YANG data model defined in [NSSM] to request low-latency
transport for a given slice if required.
...
For example, the YANG data model defined
in [NSSM] exposes a set of statistics per SDP, connectivity
construct, and connection group.
-->
26) <!-- [rfced] Please confirm that "the paths of one or more paths" is correct
here.
Original:
In this
approach, when the actual traffic volume in the data plane on given
link exceeds a threshold, the controller, knowing how much actual
data plane traffic is currently traveling along each RSVP or SR-TE
path, can tune the paths of one or more paths using the link such
that they avoid that link. This approach is similar to that
described in Section 4.3.1 of [RFC9522].
Perhaps:
In this
approach, when the actual traffic volume in the data plane on given
link exceeds a threshold, the controller, knowing how much actual
data plane traffic is currently traveling along each RSVP or SR-TE
path, can tune one or more paths using the link such
that they avoid that link. This approach is similar to that
described in Section 4.3.1 of [RFC9522].
-->
27) <!-- [rfced] FYI - We updated this sentence as follows. Let us know any
concerns.
Original:
For example, [RFC9375] can be used to report links' one-way delay,
one-way delay variation, etc.
Perhaps:
For example, the YANG data model in [RFC9375] can be used to report
the one-way delay and one-way delay variation of links.
-->
28) <!-- [rfced] The top-level bullets in the list in Section 8 are all complete
sentences except for the items below. How may we revise these to create
complete sentences?
Original:
* Means to report a set of network performance metrics to assess
whether the agreed slice service objectives are honored.
...
* Means to report and expose observed performance metrics and other
OAM state to customer.
Perhaps:
* Providers should provide the means to report a set of network
performance metrics to assess whether the agreed slice service objectives
are honored.
...
* Providers should have the means to report and expose observed performance
metrics and other OAM state to customer.
-->
29) <!-- [rfced] The last two sentences mention 1-to-1 mapping and N-to-1
mapping, but these are not listed in Section 3.5 (which only lists 1 to
N, M to 1, and M to N). Please review and let us know if any updates are
needed. (The first two sentences are included for context.)
Original:
The mapping between 5G slice to TN slices (see Section 3.5) is a
design choice of service operators that may be a function of, e.g.,
the number of instantiated slices, requested services, or local
engineering capabilities and guidelines. However, operators should
carefully consider means to ease slice migration strategies. For
example, a provider may initially adopt a 1-to-1 mapping if it has to
instantiate just a few Network Slices and accommodate the need of
only a few customers. That provider may decide to move to an N-to-1
mapping for aggregation/scalability purposes if sustained increased
slice demand is observed.
-->
30) <!-- [rfced] FYI, we updated the title for this reference to match the title
at the URL. Please let us know if you prefer otherwise.
Original:
[Book-5G] Peterson, L., Sunay, O., and B. Davie, "5G Mobile
Networks: A Systems Approach", 2022,
<https://5g.systemsapproach.org/>.
Current:
[Book-5G] Peterson, L., Sunay, O., and B. Davie, "Private 5G: A
Systems Approach", 2023,
<https://5g.systemsapproach.org/>.
-->
31) <!-- [rfced] Would it be helpful to point to specific versions of
[TS-23.501]
and [TS-28.530]? The original date for both references was 2024, but
there are multiple versions across multiple releases from that year, and
both also have new 2025 versions.
Note that specific sections and figures in [TS-28.530] are mentioned in the
text. We are not sure if these will be stable across versions.
Current:
[TS-23.501]
3GPP, "System architecture for the 5G System (5GS)", 3GPP
TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
...
[TS-28.530]
3GPP, "Management and orchestration; Concepts, use cases
and requirements", 3GPP TS 28.530,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3273>.
-->
32) <!-- [rfced] The current URL for this reference
(https://www.o-ran.org/specifications) goes to a page titled "O-RAN
Specifications". We were able to find a list of O-RAN specifications here:
https://specifications.o-ran.org/specifications.
We were unable to find Version 04.00 of the O-RAN specification. It
appears that this page only has the most recent version - Version
08.00 - published in June 2024. May we update this reference
accordingly to point to this version?
Original:
[O-RAN.WG9.XPSAAS]
O-RAN Alliance, "O-RAN.WG9.XPSAAS: O-RAN WG9 Xhaul Packet
Switched Architectures and Solutions Version 04.00", March
2023, <https://www.o-ran.org/specifications>.
Perhaps:
[O-RAN.WG9.XPSAAS]
O-RAN Alliance, "Xhaul Packet Switched Architectures and
Solutions", O-RAN.WG9.XPSAAS, Version 08.00, June 2024,
<https://specifications.o-ran.org/specifications>.
-->
33) <!-- [rfced] Will readers understand what "the above approach" is in this
sentence? Does this refer to the approach described in Section 4.2 or in
this document in general?
Original:
Different IPv6 address allocation schemes following the above
approach may be used, with one example allocation shown in Figure 31.
Perhaps:
Different IPv6 address allocation schemes following the
approach in this document may be used, with one example allocation shown
in Figure 31.
Or:
Different IPv6 address allocation schemes following the
approach in Section 4.2 may be used, with one example allocation shown
in Figure 31.
-->
34) <!-- [rfced] We see some differences in the terms below in text in Appendix
A
and Figure 32. Please review and let us know if updates are needed.
2001:db8:b:0::/96
2001:db8:b::/96
2001:db8:a:0::/96
2001:db8:a::/96
SST-01
SST=1
SST-03
SST=3
-->
35) <!-- [rfced] Abbreviations. (To view the updates to this section,
which was moved to Section 2.2, we suggest using the alternative
diff file: https://www.rfc-editor.org/authors/rfc9889-alt-diff.html)
a) FYI, we updated the expansion of GPRS to use "General" rather
than "Generic".
Original:
Generic Packet Radio Service
Updated:
General Packet Radio Service
b) FYI, this entry appeared in the original, but it was not used
elsewhere in the document, so it has been removed.
UE: User Equipment
c) The abbreviation "DM" appears in Figure 7 but not elsewhere in the
document. Will readers know this abbreviation (perhaps "data model")? May we
add the expansion to the list of abbreviations in Section 2.2?
d) "AMF" appears in Figure 8 but not elsewhere in the document. How should this
be expanded?
e) Will readers understand "LxVPN"? It only appears once in the document. May
we update for clarity as follows?
Original:
The correlation between an LxVPN instance
and a Network Slice Service is maintained using "parent-service-
id" attribute (Section 7.3 of [RFC9182]).
Perhaps:
The correlation between an L3VPN/L2VPN instance
and a Network Slice Service is maintained using "parent-service-
id" attribute (Section 7.3 of [RFC9182]).
f) FYI, we have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
MACsec: Media Access Control Security
MNO: Mobile Network Operator
-->
36) <!-- [rfced] Terminology
a) "DC1" and "DC2" (no space) are used in the text in Section 7, but "DC 1" and
"DC 2" (with space) are used in Figure 30 and Tables 1 and 2. Should these be
consistent? If so, let us know which form is preferred.
b) Please review the names of domains and let us know if any updates are needed
for consistency. Some examples:
Provider Orchestration Domain (Figure 3)
provider orchestration domain
Provider Network Orchestration domain
Customer Orchestration Domain (Figure 3)
Customer Site Orchestration domain
3GPP orchestration domain
3GPP domains Orchestration (Figure 6)
provider and customer TN domains
customer and provider orchestration domains
c) We note capitalization inconsistencies in the terms below throughout the
text. Should these be uniform? If so, please let us know which form is
preferred.
transport network
Transport Network
mobile network
Mobile Network
d) We see a few instances of "5Q QoS". Should these be updated to "5G QoS"?
e) Should "Slice Services" (uppercase) in these sentences be updated to "slice
services" (lowercase)? It seems that "slice service" is lowercase in general
text and capitalized in the terms "Network Slice Service" and "5G Slice
Service".
Original:
The objective of Transport Network Slicing is to isolate, guarantee,
or prioritize Transport Network resources for Slice Services.
...
Putting in place adequate automation means to realize Network Slices
(including the adjustment of Slice Services to Network Slices
mapping) would ease slice migration operations.
f) Should "slice" be lowercase or uppercase in these contexts?
Transport Network Slice
TN slice
5G Network Slice
5G slice
g) In general text, we see both "Network Slice" (uppercase) and "network
slice" (lowercase). We suggest using the lowercase form when used on its own
(the capitalized form is used consistently in the terms "RFC 9543 Network
Slice", "Network Slice Service", and "5G Network Slice"). This seems to follow
the usage in RFC 9543. Let us know your thoughts. Some examples are below.
Examples of uppercase "Network Slice":
A TN slice might be considered as a variant of horizontal composition
of Network Slices mentioned in Appendix A.6 of [RFC9543].
...
The use of VPNs for realizing Network Slices is briefly described
in Appendix A.4 of [RFC9543].
Examples of lowercase "network slice":
The document is not
intended to be a BCP and does not claim to specify mandatory
mechanisms to realize network slices.
...
* Providers may want to enable differentiated failure detect and
repair features for a subset of network slices.
-->
37) <!-- [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. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
38) <!-- [rfced] We made the following changes regarding the <aside> element.
The <aside> element 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).
a) We placed the following note in Section 5.2.2 in the <aside>
element.
Original:
Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP, queue,
etc.) are provided for illustration purposes only and should not
be considered as deployment guidance.
Updated:
| Note: The numbers indicated in Figure 23 (S-NSSAI, 5QI, DSCP,
| queue, etc.) are provided for illustration purposes only and
| should not be considered as deployment guidance.
b) The following text in Section 3.3.5 appears in the <aside> element. We
added "Note:".
Original:
| In order to keep the figures simple, only one AC and single-
| homed CEs are represented. Also, the underlying bearers are
| not represented in most of the figures. However, this document
| does not exclude the instantiation of multiple ACs between a CE
| and a PE nor the presence of CEs that are attached to more than
| one PE.
Updated:
| Note: In order to keep the figures simple, only one AC and single-
| homed CEs are represented. Also, the underlying bearers are
| not represented in most of the figures. However, this document
| does not exclude the instantiation of multiple ACs between a CE
| and a PE nor the presence of CEs that are attached to more than
| one PE.
-->
39) <!-- [rfced] Please review all the SVG figures in the HTML/PDF outputs to
ensure that they convey the same information as the ascii-art in the
TXT output. We have included some notes below about particular figures.
If changes are needed, please either update the SVG in the XML file directly
or provide updated SVG for the affected figure(s).
a) Note that "===" appears as a solid double line in the SVG in the HTML
and PDF outputs. Are any updates needed for this sentence in Section 3.3.5?
Original:
For example,
the bearer is illustrated with "===" in Figures 4 and 5.
b) Figure 4: Do the boxes labeled "SW" and "PE" appear correctly in the SVG?
c) Figure 5: Do the boxes labeled "CE", "Mngd CE", and "DC GW" appear correctly
in the SVG?
d) Figures 12, 15, and 16:
- In the SVG, the lines do not extend all the way to the boxes labeled "PE".
- The "+" signs that appear in the ascii-art do not appear in the
SVG. Note that Figure 12 has a legend that includes "+", but "+" does not
appear in the SVG.
- Figure 12: Please consider changing each asterisk to a different character
and running aasvg again to get new SVG. It seems "+*" together does not appear
as you intended in the SVG. Please see issue #20 for aasvg
(https://github.com/martinthomson/aasvg/issues/20) where using a Unicode
character is a suggested workaround.
e) Figure 23:
- The boxes in the SVG that contain "5QI=", "DSCP=", and "TN QoS Class" are
not closed in the SVG. Will these be confusing for readers?
- In the "NF-A" box, a pipe character is spaced over. We can fix it in the
ascii-art, but we are unable to fix it in the SVG.
f) Figures 24 and 25:
- Do the boxes for Slice 1, Slice 2, and Slice 3 look okay in the SVG? They
are missing some corners.
- Do the boxes under "Slice Policer" in Figure 25 look as expected in the SVG?
g) Figure 26:
- The bottom right of the figure looks off, i.e., "/|\" in the txt
output. Should it be moved over one space to the left? We can fix this in the
ascii-art if needed, but we are unable to fix the SVG.
- The "..." in the txt output does not seem to be reflected in the SVG
output. There is a solid line with ".." in the SVG.
h) Figure 27: Does the ">>" in the ascii-art appear as expected in the SVG?
i) Figure 30: The filled-in dot in the SVG overlaps letters in the PE boxes.
This should be updated. Please see the note above regarding Figure 12 for
more information, assuming this SVG was created using aasvg.
j) Figure 32:
- Does the arrow "v" above the "^" above "MIot (SST=3)" look as expected in
the SVG?
- Do the PE and NF boxes look okay in the SVG?
-->
Thank you.
Rebecca VanRheenen and Alice Russo
RFC Production Center
On Oct 23, 2025, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/10/23
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9889.xml
https://www.rfc-editor.org/authors/rfc9889.html
https://www.rfc-editor.org/authors/rfc9889.pdf
https://www.rfc-editor.org/authors/rfc9889.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9889-diff.html
https://www.rfc-editor.org/authors/rfc9889-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9889-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9889
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9889 (draft-ietf-teas-5g-ns-ip-mpls-18)
Title : A Realization of Network Slices for 5G Networks Using
Current IP/MPLS Technologies
Author(s) : K. Szarkowicz, Ed., R. Roberts, Ed., J. Lucek, M. Boucadair,
Ed., L. Contreras
WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram
Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
