Hi! I have been selected to do a routing directorate "early" review of this draft. https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/ The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted to the IESG for publication. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. The review focuses on providing a new perspective on the work, intending to catch any issues early on in the document's life cycle. For more information about the Routing Directorate, please see https://wiki.ietf.org/group/rtg/RtgDir . Alvaro. Document: draft-ietf-teas-5g-ns-ip-mpls-02 Reviewer: Alvaro Retana Review Date: Jan. 8, 2024 Intended Status: Informational Summary: This document needs more work before being submitted to the IESG. Comments: >From the abstract:    This document describes a basic RFC XXXX Network Slice realization    model in IP/MPLS networks with a focus on the Transport Network    fulfilling 5G slicing connectivity requirements. This realization    model reuses many building blocks currently commonly used in service    provider networks. Based on this objective, I expected the document to explain how to realize RFC XXXX Network Slices in IP/MPLS networks. To be up-front about my expectations.  RFC XXXX Network Slices represent new technology/functionality introduced in the TN.  It is clear that operational and management considerations exist -- I usually turn to rfc5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) as a guide.  Some of the information is covered in this document and some is not.  Of course, my expectations may not match the WG's. Note that I built my expectations despite this text from RFC XXXX indicating that realizing IETF Network Slides is not possible yet:   7.5. Network Slicing and Aggregation in IP/MPLS Networks      ...      Many approaches are currently being worked on to support IETF Network Slices in IP and MPLS networks with or without the use of Segment      Routing. Most of these approaches utilize a way of marking packets so      that network nodes can apply specific routing and forwarding      behaviors to packets that belong to different IETF Network Slices.      Different mechanisms for marking packets have been proposed      (including using MPLS labels and Segment Routing segment IDs) and      those mechanisms are agnostic to the path control technology used      within the underlay network.      ...      At this stage, it is inappropriate to cite any of these proposed      solutions that are currently work in progress and not yet adopted as      IETF work. Maybe draft-ietf-teas-ietf-network-slices needs to be updated (even if it's already in the RFC Editor's Queue) to reflect the current state better and perhaps point to this draft. OTOH, this document leaves several important pieces for the realization out of scope.  I wonder if some of these are the "proposed solutions" mentioned in RFC XXXX.  For example:  - "How a Network Slice Service request is placed for realization" (Section 1)  - "implications of any change of S-NSSAI on the addressing plans" (Section 4.2)  - "how to realize or orchestrate transport planes" (Section 6)  - "mechanism...to inform the NSC which DC-pairs are of interest" (Section 7.1) Also, some technology that can be used for the realization is listed as Informative references and examples.  Besides the fact that the required technology for the realization should be Normative, their use as examples is not followed by proper guidance to help operators make good decisions for their environment. In fact, the text and the possible realization are full of phrases like "could be", "would be", or "may be" -- a total of over 20 occurrences. Note that only one mention of a "mandatory (function) in the architecture described in this document" is present in the whole document (Section 5.2.1.2.  Outbound Edge Resource Control) -- making everything else optional and requiring some guidance. Speaking of terms only mentioned once, "tunnel group" is only used in the first paragraph of Section 6 to introduce "transport planes".  Is this indirection necessary?  Also, what is the difference between tunnel groups/transport planes and an NRP?  Even if it is evident to you, it would help readers if it was clarified. Security Considerations I-D.ietf-teas-ietf-network-slices points to specific issues that need to be addressed in actual implementations or deployments:    Conformance to security constraints    IETF NSC authentication    Specific isolation criteria    Data Confidentiality and Integrity of an IETF Network Slice ...but none of these are addressed here. The document reads:    Security considerations specific to each of the technologies and    protocols listed in the document are discussed in the specification    documents of each of these protocols. The existing documentation doesn't always address slicing-specific aspects that may come up.  Quoting from I-D.ietf-teas-ietf-network-slices:    IETF Network Slices might use underlying virtualized networking. All    types of virtual networking require special consideration to be given    to the separation of traffic between distinct virtual networks, as    well as some amount of protection from effects of traffic use of    underlay network (and other) resources from other virtual networks    sharing those resources.    For example, if a service requires a specific upper bound on latency,    then that service could be degraded with added delay caused by the    processing of packets from another service or application that shares    the same network resources. Thus, without careful planning or traffic    policing, it may be possible to attack an IETF Network Slice Service    simply by increasing the traffic on another service in the network. The realization requires understanding the potential risks/mitigations that are slice-specific.  This document mentions that resources can be shared between slices and even suggests a mechanism that can result in per S-NSSAI monitoring.  These issues need to be highlighted in this section. Note that some references are wrong (rfc8754 specifies the SRH; the reference to SRv6 should be rfc8986), and others are missing: I didn't see a reference to where a "5G Network Slice" is defined, and there's no reference for "RSVP-TE or SR-TE LSPs".  Are there references for 1r2c/2r3c? I don't believe this document can be used as a guide to realize RFC XXXX Network Slides in IP/MPLS networks because there is missing information.  The 5G-related background information is excellent., even if it is too much at times. Given that RFC XXXX provides a "general framework", the technology and recommendations in this document (even if focused on "fulfilling 5G slicing connectivity requirements") should also be generally valid. As other realization documents may be developed, it might be an excellent way to reuse resources if this document could also be used as a general reference.  IOW, I imagine there would not be a significant difference (generalizing/taking out 5G-specific things like the 5QI) between what is discussed here and "general" slices using the same technology.