[Last-Call] Genart last call review of draft-ietf-dmm-srv6-mobile-uplane-22

[Gyan Mishra via Datatracker <[e-mail]>]

Reviewer: Gyan Mishra
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dmm-srv6-mobile-uplane-??
Reviewer: Gyan Mishra
Review Date: 2022-12-03
IETF LC End Date: 2022-11-23
IESG Telechat date: Not scheduled for a telechat

Summary:

   This document specifies the applicability of SRv6 (Segment Routing
   IPv6) to the user-plane of mobile networks.  The network programming
   nature of SRv6 accomplishes mobile user-plane functions in a simple
   manner.  The statelessness of SRv6 and its ability to control both
   service layer path and underlying transport can be beneficial to the
   mobile user-plane, providing flexibility, end-to-end network slicing,
   and SLA control for various applications.

This draft is well written and is almost ready for publication with a few minor
nits and issues I would like to have addressed. I have been following this
draft throughout its progression and I believe it’s a very critical and
important optimization for operators to be able to leverage SRv6 in the 5G
Cloud RAN virtualized environment.

Major issues:
None

Minor issues:
I noticed that this draft does not mention the use of SRv6 CID endpoint flavor
uSID or GSID.  All implementations that would be deployed now would either use
one of the two endpoint flavors either uSID 16 bit uSID  which can support up
to 5 or 6 uSID within a uSID carrier using shift and forward Next endpoint
behavior and G-SID can support up to 3 32 bit G-SID within a single carrier
using Replace endpoint behavior which requires copy of G-SID from SRH to DA. 
So I think it’s important to mention that MUP is relevant for maybe Full SID
and CID Next and Replace endpoint functions or as any future deployment would
not use the Base Full 128 bit SID I think it’s fair to say that MUP is
applicable to the SRv6 compression CSID endpoint behaviors Next and Replace SID.

Since section 5.4 SRv6 drop in interworking is the section that defines the MUP
specification for standardization my recommendation is to maybe make a separate
section would make it more clear and then would avoid having to state in the
introduction that all section 5 sub sections are informational and only 5.4 is
standards track.  Also in creating a new section I would put that before the
information section.  Also for the informational sections heading “5G MUP
operational models suggestions”.  Another idea is to remove the informational
sections from the body and move to appendix.  For the reader as it’s all
clumped together in the body, for the reader it does make it confusing as to
why some or all of that is not part of the MUP specification and raises
questions as to why it should or should not be informational. The operational
models include traditional and enhanced replaces the GTP-U to use existing
SRv6-VPN PGM endpoint functions and traditional no SRv6 TE way points where
enhanced mode includes SRv6 TE way points and two interworking cases with
legacy gNB GTP-U for IPv4 and IPv6.  The two modes and interworking modes use
existing SRv6 endpoint behaviors so is not introducing anything new thus the
reason for keeping as informational models and I agree.  However breaking up
the Standard and informational sub sections into separate sections would help
the readability of the specification.

Nits/editorial comments:

GTP and GTP-U are mentioned throughout the draft and both AFAIK refer to the UE
Generic Tunneling Protocol User Plane encapsulation.  I would use GTP-U
throughout the draft.

On page 6 5G terminology section please mention GTP-U as well maybe mention
what each Nx interface represents.

Under terminology you mention VNF and CNF.

So my understanding is both VNF and CNF are components of NFV MANO and
programmatically chaining VNF / CNF together into a service chain. VNF refers
to use of VM virtual machines guest OS sitting on a hypervisor and separate
binaries where CNF refers to a container sitting on the host OS with shared
binaries with context name spaces that logically separate the container
providing the network functions.  So the natural progression has been from PNF
physical hardware to VNF - VMs to now CNF - cloud native containers.

AFAIK I don’t think this description is correct

VNF: Virtual Network Function (including CNFs)

Page 5 section 3

Old

It is also suitable for virtualized
   environments, like VNF/CNF to VNF/CNF networking.

New

It is also suitable for virtualized
   environments, like VNF/CNF to VNF/CNF networking.

Section 2.3 mentions endpoint behavior AFAIK that are applicable to the
informational operational models.  Maybe should mention that explicitly and as
not all endpoint behaviors are mentioned that is my interpretation of the
section.  So if that is the case End.DX2 I don’t think EVPN would be relevant
and only L3 VPN endpoint behaviors would be relevant.

Section 3 3rd paragraph

In the meantime, applications have shifted to use IPv6, and network
   operators have started adopting IPv6 as their IP transport.  SRv6,
   the IPv6 dataplane instantiation of Segment Routing [RFC8402],
   integrates both the application data-path and the underlying
   transport layer into a single protocol, allowing operators to
   optimize the network in a simplified manner and removing forwarding
   state from the network.

In this paragraph are we referring to SRv6 in particular that the VPN service
layer FUNCT encoding and transport layer Locator encoding into the SRv6 SID
merging together into a flat data plane with SRv6 BGP Overlay RFC 9252 as
compare to traditional SR-MPLS 2 level label stack.  This flat data plane also
caters to cloud native networking and 5G Cloud RAN virtualization of networking
components.  In Section 3 motivation maybe mention the 5G architectural change
to virtualized Cloud RAN - NFV / CNF cloud native - that makes the change to
SRv6 much more prudent for operators as SRv6 uses the native IPv6 data plane as
compare to SR-MPLS which reuses the MPLS data plane.