Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi,

Here is my summary.

General comments:

1. There were some architecture discussions about SRv6-transporting-GTPu vs SRv6-replacing-GTPu. I understand that this document is about SRv6-replacing-GTPu and the other is out of scope. That's ok - but the draft should omit "3.  Motivation" and just have an informational reference to draft-kohno-dmm-srv6mob-arch. In other words, defer the motivation discussion to the separate draft and just focus on technical details in this spec. BTW - I want to clarify here that when I said "the only advantage of SRv6-replacing-GTPu is MTU savings" is *in comparison* to SRv6-transporting-GTPu.
2. I don't think it is good to categorize into "traditional mode" and "enhanced mode" (note that I am not saying that an operator does not have a choice in what it wants to deploy - it's just that the categorization itself is strange), though that's not technically critical.
3. draft-murakami-dmm-user-plane-message-encoding should be a normative reference.

Specific outstanding technical comments:

4. In 5.3, for uplink traffic, the GW has End.M.GTP6.D for the UPF address B and the gNB does not need to know the existence of GW. For downlink traffic, the UPF knows there is a GW and put the GW::TEID in the SRH. Why not make GW invisible to UPF as well and just use gNB::TEID, and then have gNB/96 as End.M.GTP6.E on the SRGW? You can still put GW in the SRH to steer traffic through the GW.
5. In 5.2.2, because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just simply use gNB. It must be gNB:TEID.
6. I still don't agree with the aggregation statement in 5.2.3. Per 5.2.2 (and see #5 above), the gNB does END.DX2/4/6 so per-UE SID (based on N2/4-signaled TEID) is needed. Otherwise, gNB needs to forward traffic based on inner header (UE address), which is different from both 5.2.2 and normal gNB behavior.
7. (this is new) 5.2.2 says " gNB's  control plane associates that session from the UE(A) with the IPv6 address B.  gNB's control plane does a lookup on B to find the related SID list <S1, C1, U2::1> ... When the packet arrives at UPF2, the active segment (U2::1) is an End.DT4/End.DT6/End.DT2U". End.DT4/6/2U requires specific tables for lookup (to go to different DNs in this case) and the text is not clear on how that table is determined. Different UEs could be associated with different DNs but the N2 signaling can give the same IPv6 address B. In GTP-U case, the UPF is able to associate different UEs to different DNs based on TEID but for SRv6 different mechanism is needed (and missing for now). It could be that the control plane will give out different address B for different DNs but that needs to be spelled out.

There may be other minor points/nits. For example, 5.1 says N2/N4 is unchanged while 5.2 only says N2 is unchanged. Does 5.2 imply/need N4 change? Good to be explicit.

BTW - while trying to confirm whether N4 needs to be changed for 5.2, I noticed the following in section 9:

   The control plane could be the current 3GPP-defined control plane
   with slight modifications to the N4 interface [TS.29244].

It should be clarified what kind of modifications to the N4 is needed and for what scenario.

Jeffrey

-----Original Message-----
From: dmm <dmm-bounces@ietf.org> On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, July 7, 2021 2:59 PM
To: Pablo Camarillo (pcamaril) <pcamaril=40cisco.com@dmarc.ietf.org>
Cc: dmm@ietf.org
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]

Authors:

Can you please summarize the discussions and identify the open issues, or areas of non-agreement that have come up as part of this WGCLC

Thanks
Sri

_______________________________________________
dmm mailing list
dmm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!RHnpE1MQpMxwvVzdJxpCZjAUFz5bvXIR6cIWkZ21QDqH-Jv91pT-qaf5U6u-eMJx$

Juniper Business Use Only

Juniper Business Use Only