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

[Krzysztof Szarkowicz <[e-mail]>]

Hi Alvaro,

Thank you for spending time on the review. Please see my comments inline.

—
Krzysztof


> On Jan 8, 2024, at 19:55, Alvaro Retana <[e-mail]> wrote:
> 
> 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.

[Krzysztof] As the draft evolved over past two years, or so, the focus slightly shifted. Initially its started with the focus on the realization of RFC XXXX Network Slice (called at that time ‘IETF Network Slice’), while the current focus is rather how to implement/realize end-to-end transport connectivity between 5G network functions (NFs). Some domains in this end-to-end path between NFs might use RFC XXXX concepts (i.e., typically wide area network), while some parts of this end-to-end patch might not use RFC XXXX concepts (i.e., O-Cloud in O-RAN deployments). We emphasize this in Figure 5m, where RFC XXXX concepts are deployed only in the middle part (provider network), Thus, we will adjust the draft title to avoid understanding, that the draft talks about RFC XXXX end-to-end (from 5G NF to another 5G NF).

[Krzysztof] Regarding RFC 5706 -> this document doesn’t introduce any 'New Protocols and Protocol Extensions’, therefore we do not reference RFC 5706 in this work.


> 
> 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.

[Krzysztof] IMHO, updating framework document is too late (as it is in the RFC Editor’s queue, as you mentioned), Saying that, even today operators are deploying network slices (e.g., virtual leased line with SLO guarantees, which is essentially a point-to-point slice) over IP/MPLS networks, so we are not sure about your conclusion that realizing IETF Network Slices is not possible.

> 
> 
> 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)

[Krzysztof] While this document describes overall high-level orchestration architecture to provide end-to-end transport connectivity between 5G NFs, which slicing where applicable, it, indeed, doesn’t focus on the orchestration details. It would be too big for this document (which big already). Here we referencer other works done in the area, like for example I-D.ietf-opsawg-ntw-attachment-circuit, I-D.ietf-opsawg-teas-attachment-circuit, I-D.ietf-teas-5g-network-slice-application, I-D.ietf-teas-ietf-network-slice-nbi-yang.

>  - "implications of any change of S-NSSAI on the addressing plans" (Section 4.2)

[Krzysztof] changes of S-NSSAI might have implications of many things, like VLANs (Section 4.1), IP addresses (Section 4.3), BGP communities and/or MPLS labels (Section 4.3), and so on. In general, this document describes how to realize the request, with the pre-determined values. How these values are pre-determined (which assumes some sort of orchestrator level communication between different orchestrator domains) it out of scope, and as mentioned earlier we refer to other documents focusing more on this aspect.

>  - "how to realize or orchestrate transport planes" (Section 6)

[Krzysztof] Indeed, it is out of scope. We provide some examples of transport planes (like, e..g, Flex-Algo or RSVP/SR traffic engineering tunnels with or without PCE, and with or without bandwidth reservations), but to keep this document within reasonable size we decided to consider orchestration details (i.e., how to orchestrate Flex-Algo or set of traffic engineering tunnels) as out-of scope for this document. 


>  - "mechanism...to inform the NSC which DC-pairs are of interest" (Section 7.1)

[Krzysztof] For dynamically created 5G NFs, higher level orchestrator decides about best placement of such 5G NFs in a specific DC (among many available DCs). This decision process is an orchestration thing, and this out of scope for this document. Once decided, appropriate request (with concrete identification of the DC-pair - more details are in I-D.ietf-teas-5g-network-slice-application) is passed to NSC. To keep the size of the document within reasonable limits, we cannot describe every aspects in single document, thus orchestration aspect is described in more details in other documents referenced from this document.

> 
> 
> 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.

[Krzysztof] The intended status of this draft is ‘informative’. Within this work, we do not have aspiration to define new protocols extensions or similar. The aspiration of this work, is to show to the SP community, that deploying 5G, including 5G with slicing capability, over existing transmission infrastructure is possible, and we are showing here some possible ways, how to do it with currently deployed technology/featyrest, without reinventing the wheel. However, there could be many ways, how to implement it, therefore we avoid any normative language. We will review entire document too ensure normative (‘mandatory’, ‘must’) language is not used.

> 
> 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.

[Krzysztof] We will work on more clear language here.

> 
> 
> 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.
> 
> 

[Krzysztof] That is good point. In the next revision, we will rework security section of this document to address these aspects one by one.

> 
> 
> 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?

[Krzysztof] In the next revision, we will correct references (e.g., RFC 8754 -> RFC 8986), and add new references, where appropriate. Also, we will explicitly define “5G Network Slice” term at the beginning of this draft.

> 
> 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.
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas