Re: [DMM] Additional questions/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: Wednesday, July 21, 2021 1:37 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: Sri Gundavelli (sgundave) <[e-mail]>; [e-mail]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[External Email. Be cautious of content]


Hi Jeffrey,

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

Cheers,
Pablo.

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

Zzh> Let me take one step back.
Zzh> This spec includes an option where SRv6 encapsulation/decapsulation based on N2/N4-signaled GTP-U parameters, so I thought there must be a spec about how the GTP-U header fields are encoded in SRv6. If draft-murakami is that draft, then it must be a normative reference. If draft-murakami is not that draft, then either all details need to be spelled out in this document, or some other document should be referenced (normatively).
Zzh> It seems that you're saying draft-murakmi is a separate/parallel thing. If so, which spec talks about how the GTP extension headers, sequence number, N-PDU number are encoded? If those are not expected to be used/supported, it needs to be pointed out.

+       0-2     3       4       5       6       7       8-15    16-23   24-31
0       Version Protocol type   Reserved        Extension Header Flag   Sequence Number Flag    N-PDU Number Flag       Message Type    Message length
32      TEID
64      Sequence number N-PDU number    Next extension header type

>
> 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.
Zzh> I did not see it there?

> 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.
Zzh> I also replied there.

> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmm/Fv98rJ_PLyg5PNrQdnOa8g-1-EQ/__;!!NEt6yMaO-gk!TtoDf0I3B72KdJ0dz3B-TP46AGXDxJNcJ1LVz5UAFrW--mj0qmI4qbK0gdw9oFfR$

zzh> Let's look at the text here:

   The Enhanced Mode improves since it allows the aggregation of several
   UEs under the same SID list.  For example, in the case of stationary
   residential meters that are connected to the same cell, all such
   devices can share the same SID list.  This improves scalability
   compared to Traditional Mode (unique SID per UE) and compared to
   GTP-U (dedicated TEID per UE).

Zzh> Unless gNB does inner (UE) address lookup to forward traffic, you have to use unique SID per UE. This means that, the aggregation is *not provided by SRv6-replacing-GTP". It is provided by upgraded gNB function (that is not 3GPP-defined) that does inner address lookup and completely independent of SRv6.
Zzh> If the "improved scalability" refers to that a single SID is used to reach many UEs, then GTP-U (legacy or SRv6-transported) already has that from day-one (only the gNB address is used).
Zzh> I do agree that when gNB does inner address lookup for forwarding, then aggregation is achieved compared to traditional mode in 5.1. That's also why I suggested from early on that the main distinction of enhanced mode is this aggregation (not the traffic steering and service programming). But the spec should be explicit that this is done by inner address lookup. However, with aggregation then section 5.2.2 is incorrect because it talks about End.DX2/4/6 with gNB address - how can you do End.DX2/4/6 without per-UE SIDs?

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

Zzh> What about this one?

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

Zzh> Like in 5.1 saying that N2/N4 is unchanged, 5.2 should be explicit if N4 is changed.
Zzh> Details of changes can be out of scope of this document, but a) there must be a referenced document talking about it; b) it's good to talk about the changes at high level (e.g., different addresses B is given out) in 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-.
Zzh> If a solution relies on changed control plane, the changes must be talked somewhere. If it is not in this document, then a reference should be provided.
Zzh> Jeffrey

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

Juniper Business Use Only

Juniper Business Use Only