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

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

Hi Pablo,

Please see zzh2> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[e-mail]>
Sent: Thursday, July 22, 2021 1:27 PM
To: Jeffrey (Zhaohui) Zhang <[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]


Hi Jeffrey,

Inline with PC2.

Thanks,
Pablo.

-----Original Message-----
From: dmm <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: jueves, 22 de julio de 2021 16:36
To: Pablo Camarillo (pcamaril) <pcamaril=[e-mail]>
Cc: [e-mail]
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

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.
[PC2] None of those additional GTP-U parameters are included in the SRv6 encapsulation defined in this document.

Zzh2> I think that should be pointed out explicitly.

[PC2] The N2/N4-signaled GTP-U parameters are combined with a local policy to steer on a SID list. If you want to encode the additional parameters, then this is out of the scope of this document. Informative reference to draft-murakami provides one possible encoding.

+       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?
[PC2] I got confused to the other point. Indeed it wasn't replied.
[PC2] The address B in the uplink is a BindingSID at the SRGW. It is not a SID belonging to the UPF as you state in your first sentence.

Zzh2> My point is to use a loopback address on the UPF instead of the SRGW - that way the GW is completely transparent to others (like in the other direction). That does not prevent the SRGW from having a binding SID for it.
Zzh2> Once you do that, we can actually get rid of one endpoint behavior (I'll talk about that separately).

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

[PC2] GTP-U today does not allow to perform aggregation. Please point me to the relevant 3GPP standard if I'm wrong.

Zzh2> You were saying "all such devices can share the same SID list" (vs. different SIDs on the gNB). But with GTP-U, there is only gNB address in the first place - it’s aggregation by default.

[PC2] You may have aggregation on the uplink and on the downlink. I believe your point is particularly on the downlink (as you have already recognized uplink is doable).

Zzh2> For uplink, either you need to use different B addresses on UPF, or you still have to include TEID somewhere so that UPF knows where to do lookup for the inner address. It is true that this can be done by local policy on gNB, but the same can be done for GTP as well. You can say that GTP is out of scope and that's fine, but don't claim this is an advantage over GTP 😊
Zzh2> In short, my points are: a) there are implications to do aggregation and they should be spelled out; b) the same can be done for GTP as well - not SRv6 specific.

[PC2] You have various methods or forms to perform the downlink aggregation.
[PC2] One of them is to do an inner address lookup. In such case you are indeed right that instead of using End.DX2/DX4/DX6, the DT4/DT6/DT2 should be used.
[PC2] Another option is to forward to the group of UEs and let the UE drop the packet based on the IP destination address.

Zzh2> To claim the aggregation advantages, these need to be spelled out.

> 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?
[PC2] You are right, the control plane needs to ensure consistency when doing SID advertisements. That said, I don't see why such control plane consideration should be added to this document given that this document focuses on the dataplane and control plane is out of the scope of this document.
Zzh2> The implications to the control plane should be pointed out at high level in this document (e.g. the control plane will give out different address B for different DNs).

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

[PC2] It is already stated in 5.2 (fourth paragraph). Text only talks about N2. I will add N4.

>
> 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.
[PC2] I will replace the entire section 9 by the following:
<OLD>
9.  Control Plane Considerations

   This document focuses on user-plane behavior and its independence
   from the control plane.

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

zzh2> The slight modifications should be pointed out at high level in this document; Details should be specified in some document that is referenced to in this document. Otherwise, this is like a controller based network w/o standard signaling from the controller and not implementable.
Zzh2> Jeffrey

   Alternatively, SRv6 could be used in conjunction with a new mobility
   control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6],
   hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in
   conjunction with FPC [I-D.ietf-dmm-fpc-cpdp].  The analysis of new
   mobility control-planes and its applicability to an SRv6 user-plane
   is out of the scope of this document.

   Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for
   the new behaviors defined in this document.
</OLD>
<NEW>
9.  Control Plane Considerations

   This document focuses on user-plane behavior and its independence
   from the control plane. While there are benefits in an enhanced control plane, this document does not impose any change to it.

   Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for
   the new behaviors defined in this document to be used by a control plane if needed.
</NEW>
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

_______________________________________________
dmm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!TBkcHZoTGAsJLktHtw_FIcrUCxwrvpD8oFODkgBc-W6j6JW8yl7QflO-sYu7bf-m$

Juniper Business Use Only

Juniper Business Use Only