[Teas] RtgDir Early review of draft-ietf-teas-5g-ns-ip-mpls-02

[Alvaro Retana <[e-mail]>]

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.