Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[e-mail]>
Sent: Tuesday, June 1, 2021 7:23 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

Thanks for the reviews. Answers inline with [PC].

Thanks,
Pablo.

-----Original Message-----
From: dmm <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: martes, 1 de junio de 2021 4:33
To: Pablo Camarillo (pcamaril) <pcamaril=[e-mail]>; [e-mail]
Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

After many email exchanges and seeing two revisions (-12, -13), I now have a much better understanding of the draft. Here my further observations/understanding/comments.

Observations/Understanding:

A. This does *not* require *any* changes in the N2/N4 signaling. AMF/SMF/gNB/UPF will still use existing signaling based on GTP-U, but gNB/UPF will use either SRv6 or GTP-U tunnels based on local policy.
B. If both ends (gNB/UPF) of a tunnel use SRv6, no interworking is needed, and two modes (traditional/enhanced) are defined. This is in section 5.1 and 5.2 respectively.
C. If gNB does not use SRv6 but UPF does, an SRGW is placed next to the gNB. This is covered in 5.3 using enhanced mode example, but can be applied to traditional mode as well.
D. If neither gNB nor UPF uses SRv6, GTP-U tunnels could still be changed to SRv6 between two GWs - another SRGW is placed next to the UPF as well. This is covered in 5.4 and referred to as drop-in mode.

[PC] All the observations look good, with a side note on A: Future documents may define a new signaling.

Comments:

1. Since GTP-U can be transported over SRv6, which can also make use of TE capability and used for service programing (NFS chaining), the only real difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes part of the IPv6 address). With that, most of " 3.  Motivation" are not really applicable.
[PC] The integration of the overlay with the underlay SLA and service chaining cannot be achieved with GTP-U.

Zzh> Can you elaborate how they're achieved w/ SRv6 replacing GTP-U and not achieved with SRv6 transported GTP-U?

[PC] Actually you have a lot more of motivation in this document: draft-kohno-dmm-srv6mob-arch-04

Zzh> I had similar comments in that thread.

2. Besides the TEID, there are other parameters in the GTP-U header. How those are represented in the SRv6 header needs to be defined.
[PC] draft-murakami-dmm-user-plane-message-encoding-03

Zzh> That should be a normative reference then.

3. I still think there is no need to define the traditional/enhanced mode (see my reasoning below).
4. Now it's not clear if the interworking mode (including the drop-in mode) is worth the trouble (see my reasoning at the end).
[PC] Answers to 3 and 4 below.

Let me expand on #3 above.

"5.1.  Traditional mode" focuses on the one-to-one mapping among (PDU session, GTP-U tunnel, SRv6 tunnel) and casually mentions "SID list only contains a single SID".
" 5.2.  Enhanced Mode" talks about two things: SID list for TE and service programing/chaining, and scalability improvement via aggregation.

5.2 says:

   The gNB MAY resolve the IP address received via the control plane
   into a SID list using a mechanism like PCEP, DNS-lookup, LISP
   control-plane or others.  The resolution mechanism is out of the
   scope of this document.

That means the use of SID list for TE and service programming is not per the mobile architecture, but purely per operator's choice
[PC] Indeed. The operator is the one that decides whether traffic needs a particular SLA. As in wireline...
, and it can also be used for both traditional mode and SRv6-transported GTP-U tunnels - really nothing special to be limited to enhanced mode only.
It is true that some gNB may not be able to put on an SRH, but that equipment limitation should not become a criteria - just like that for general SRv6 (outside this mobile user plane context) we don't have "basic" vs. "advanced/enhanced" modes just because some devices cannot insert SRH.
[PC] The motivation behind traditional mode is:
"   The traditional mode minimizes the changes required to the mobile
   system; hence it is a good starting point for forming a common
   ground."

Zzh> Why did we not have "basic" vs. "advanced/enhanced" modes for SRv6 in wireline networks 😊 There is no change to mobile system/architecture, except the transport network, which is no different from wireline.

Defining traditional/enhanced mode based on aggregation is more reasonable. However, consider the following aspects:

- Currently only up link traffic can benefit from aggregation, and that's only when the AMF provides the same <UPF address, TEID> for multiple PDU sessions
- The same can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 replacing GTP-U.
[PC] GTP-U does not allow that. Certainly you could go to 3GPP and change the specs to allow it, but as per today it is not allowed.

Zzh> We established that there is no change to N2/N4 or mobile architecture: AMF/SMF continue to signal GTP-U parameters like <tunnel endpoint, TEID> but gNB/UPF may use SRv6 replacing GTP-U per local policy. With that, how is uplink aggregation achieved?
Zzh> Thanks.
Zzh> Jeffrey

The reason the aggregation is not applicable to downlink traffic is because the gNB does not do IP lookup based on inner header.
[PC] Indeed that is one option. That is new compared to today's mobile architecture. I don’t think its complex to implement though. End of the day we've done it for quite some time in wireline. Another option is to forward to a group of UEs and let the UE drop the packet based on the IPV6 DA.
Rather, downlink traffic forwarding on a gNB is purely based on TEID (whether it is in the GTP-U header or in the SRv6 SID). Therefore, the uplink aggregation or downlink aggregation (if gNB starts doing IP lookup based on inner header, which would be a big departure from existing architecture) is really controlled by the mobile architecture, not by the use of SRv6 tunnel. To achieve aggregation, the AMF/SMF will need to signal different GTP-U parameters, even though the signaling format does not need to change.

As a result, defining traditional/enhanced mode for SRv6 user plane really is not necessary.
[PC] There is a motivation behind each of the modes. Operators find it easier to deploy this way.

Now let me expand on #4 above.

There is no real difference between SRv6-transported GTP-U  and SRv6 replacing GTP-U (other than that the latter does not have UDP/GTP-U headers). If both tunnel ends can support SRv6 natively, it's reasonable to use SRv6 tunnels (replacing GTP-U) right at the tunnel ends. But if a gNB has to start/end with GTP-U (with the UDP/GTP-U headers), what is the benefit of converting to/from SRv6 by a GW, which means additional capex/opex? It's an additional failure point - the implementation could have bugs and it could fail for various reasons. It may be better off to only do SRv6 tunneling when both ends can support it. It's not clear to me that the bandwidth saving between the GW and UPF is worth the trouble.
[PC] Well... there are two differences between SRv6-transported GTPU and SRv6 replacing GTP-U. The first and obvious is the removal of the UDP/GTP-U header -which already has huge benefits as the IPv6 Flow Label for entropy 😉-. The second and most interesting difference is that the SRv6 replacement of GTP-U allows the integration of the overlay with the underlay SLA and service chaining. More in draft-kohno-dmm-srv6mob-arch-04.

These are high level comments. I may have more to come, and I definitely have more text/wording comments to share afterwards.

Thanks.
Jeffrey

Juniper Business Use Only

_______________________________________________
dmm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!TuSYNLYkiLkieDF_Rvz9641_tQoKTcUOG-4qEG4eLshWb-mDfdVjr_YwD9DLfzGU$

Juniper Business Use Only

Juniper Business Use Only