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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
