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

Hi Jeffrey,

Many thanks for the summary of the open items. 
See inline with [PC].

Cheers,
Pablo.

> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <[email protected]>
> Sent: miércoles, 14 de julio de 2021 21:56
> To: Sri Gundavelli (sgundave) <[email protected]>; Pablo Camarillo
> (pcamaril) <[email protected]>
> Cc: [email protected]
> Subject: 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.

[PC] I have mixed feelings about removing the Section 3(Motivation).
[PC] Stating a couple of paragraphs of motivation is useful to the reader, while -if they want details- then they could jump to the draft-kohno for the specifics.
[PC] That said, I also see the point that a Standards Track document should only focus on the technical details and do not discuss such things.
[PC] I'm fine either way (remove or keep). I don't have any preference. I'm the document editor: I'll edit the document to whatever the WG prefers.

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

[PC] As the I-D states
"   The traditional mode minimizes the changes required to the mobile
   system; hence it is a good starting point for forming a common
   ground."
[PC] Since 2017 the wg guidance/consensus was to have these two modes for that reason above.

> 3. draft-murakami-dmm-user-plane-message-encoding should be a normative
> reference.

[PC] I believe it's fine as an informative reference. One could implement this draft without draft-murakami. (While I agree with you that it will be common to implement both)

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

[PC] Replied in the other thread.

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

[PC] Replied in the other thread. TEID is not present. It is a specific SID instance.

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

[PC] I don't follow your point. You have stated in previous emails that aggregation can be done, hence I don't understand which part of the statement you disagree with.
"Aggregation can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 replacing GTP-U."
https://mailarchive.ietf.org/arch/msg/dmm/Fv98rJ_PLyg5PNrQdnOa8g-1-EQ/

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

[PC] Control-plane is out of the scope of this document.

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

[PC] Control-plane is out of the scope of this document. Section 9 provides some considerations, and refers to some technologies that could be used. I don't think any further text should be added -quite the contrary, we should remove-.

> 
> Jeffrey
> 
> -----Original Message-----
> From: dmm <[email protected]> On Behalf Of Sri Gundavelli (sgundave)
> Sent: Wednesday, July 7, 2021 2:59 PM
> To: Pablo Camarillo (pcamaril) <[email protected]>
> Cc: [email protected]
> 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
> [email protected]
> 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