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

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 21 Jul 2021 17:37:09 +0000

Hi Jeffrey,

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

Cheers,
Pablo.

> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> Sent: miércoles, 14 de julio de 2021 21:56
> To: Sri Gundavelli (sgundave) <[email-masked]>; Pablo Camarillo
> (pcamaril) <[email-masked]>
> Cc: [email-masked]
> 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-masked]> On Behalf Of Sri Gundavelli (sgundave)
> Sent: Wednesday, July 7, 2021 2:59 PM
> To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Cc: [email-masked]
> 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-masked]
> 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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Jul 2021 14:36:04 +0000

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Wednesday, July 21, 2021 1:37 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Jeffrey,

Cheers,
Pablo.

[PC] As the I-D states

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

[PC] Replied in the other thread.
Zzh> I did not see it there?

[PC] Replied in the other thread. TEID is not present. It is a specific SID instance.
Zzh> I also replied there.

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

> different DNs but that needs to be spelled out.

Zzh> What about this one?

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.

[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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 22 Jul 2021 17:27:04 +0000

Hi Jeffrey, 

Inline with PC2.

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: jueves, 22 de julio de 2021 16:36
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
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=[email-masked]>
Sent: Wednesday, July 21, 2021 1:37 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Jeffrey,

Cheers,
Pablo.

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

[PC] As the I-D states

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

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

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

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

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

[PC2] GTP-U today does not allow to perform aggregation. Please point me to the relevant 3GPP standard if I'm wrong.
[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).
[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.

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

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

   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

> 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-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Jul 2021 19:00:10 +0000

Hi Pablo,

Please see zzh2> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Thursday, July 22, 2021 1:27 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Jeffrey,

Inline with PC2.

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: jueves, 22 de julio de 2021 16:36
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
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=[email-masked]>
Sent: Wednesday, July 21, 2021 1:37 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Jeffrey,

Cheers,
Pablo.

[PC] As the I-D states

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

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

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.

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.

Zzh2> To claim the aggregation advantages, these need 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).

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

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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 23 Jul 2021 15:41:33 +0000

Hi Jeffrey,

Inline with PC3.
I'm also attaching the diff that we will be pushing once the I-D submission tool reopens. It includes the changes agreed to in our previous emails.

Thanks,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> 
Sent: jueves, 22 de julio de 2021 21:00
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo,

Please see zzh2> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Thursday, July 22, 2021 1:27 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Jeffrey,

Inline with PC2.

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: jueves, 22 de julio de 2021 16:36
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
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=[email-masked]>
Sent: Wednesday, July 21, 2021 1:37 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]
Subject: RE: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Jeffrey,

Cheers,
Pablo.

[PC] As the I-D states

Zzh> Let me take one step back.
Zzh> This spec includes an option where SRv6 encapsulation/decapsulation 
Zzh> 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.

[PC3] Added. 

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).
[PC3] Using a BSID at the SRGW provides you several benefits: 1) You can combine it with FlexAlgo and have SLA before reaching the SRGW; 2) At the SRGW you want to apply the SR policy as soon as possible to allow VNFs before the UPF.
[PC3] Using an address of the UPF does not provide any benefit, and quite the contrary, adds extra complexity as you need to manage several addresses on the UPF, one per SLA. 

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.
[PC3] The amount of state to hold in GTP-U is the combination of {IP, TEID} tuples. In SRv6 it is the number of unique SID lists. In GTP-U there is no aggregation -you could change the spec it if you want, but today there is none-. In SRv6 traditional mode there is no aggregation at all -a unique SID list per UE-. Therefore the state in those two solutions is exactly the same. In Enhanced mode you reuse the same SID list for several UE, hence the scalability improvement.

Zzh2> For uplink, either you need to use different B addresses on UPF, 
Zzh2> or you still have to include TEID somewhere so that UPF knows 
Zzh2> where to do lookup for the inner address. It is true that this can 
Zzh2> be done by local policy on gNB, but the same can be done for GTP 
Zzh2> as well. You can say that GTP is out of scope and that's fine, but 
Zzh2> don't claim this is an advantage over GTP 😊
[PC3] Can you please point me to the relevant 3GPP spec that allows to do aggregation for 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.

Zzh2> To claim the aggregation advantages, these need to be spelled out.
[PC3] Added in the rev14.

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).
[PC3] In the same way than in a VPN we have a different label for each different tenant. There's nothing particular about it...

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. 
[PC3] Analogy: RFC8986 does not have any reference to neither the ISIS-SRv6 I-D, nor the BGP-SRv6 drafts. And actually, the IESG was the one asking to remove those references. I don't see why it should be different in this case.
zzh2> Otherwise, this is like a controller based network w/o standard signaling from the controller and not implementable.
Zzh2> Jeffrey

---

From: David Allan I <[email-masked]>
Date: Fri, 23 Jul 2021 17:50:30 +0000

Hi:

Looking over this draft it strikes me that IF you are discussing a GTP replacement, there are a few unaddressed gaps...or at least I see no mention of them.

-  adding X2 to the list of interfaces to be supported
-  support for end-marker for handoff stream synchronization (probably could fit the unused bit in Args.Mob.Session but frankly I have not studied this in detail)
-  support for QMP (quality measurement protocol), which I believe needs to also extend across the radio interface so is not simply local to the GTP domain and can be "stunt doubled"
-  support for paging policy presence/indication

If this has come up elsewhere, let me know

Cheers
Dave

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 23 Jul 2021 12:03:46 -0700

Hi Dave,

Very good list and I am sure there could be a bit more functionalities GTP
overlay  has been supporting over a period of time *and* still currently
being used in various parts of the cellular networks.

Replacing overlays may be a good goal if we can bring the same technical
benefits different underlays (L2, L2.5, IPv4, IPv6) bring to the table in
various parts of the networks, in this case cellular deployments. We(IETF)
should develop tools towards the objective but I suspect we are there to
replace any overlay (if this is the central goal) with a single underlay
mechanism. Dino presented multiple times on this topic in various
WGs/pre-bofs/BoFs and also asked to "get over with it" (a thin overlay).

One of the things that we all should ask ourselves is - what overlay
functionalities we want to bring to underlay (L3/L2.5) as opposed to
complete replacement of the overlay. IMO, this is a better question than
"replacing".

Appreciate your thoughts and views on this.

Thank you!
--
Uma C.

On Fri, Jul 23, 2021 at 10:50 AM David Allan I <david.i.allan=
[email-masked]> wrote:

> Hi:
>
> Looking over this draft it strikes me that IF you are discussing a GTP
> replacement, there are a few unaddressed gaps...or at least I see no
> mention of them.
>
> -  support for end-marker for handoff stream synchronization (probably
> could fit the unused bit in Args.Mob.Session but frankly I have not studied
> this in detail)
> -  support for QMP (quality measurement protocol), which I believe needs
> to also extend across the radio interface so is not simply local to the GTP
> domain and can be "stunt doubled"

---

From: David Allan I <[email-masked]>
Date: Fri, 23 Jul 2021 19:29:01 +0000

Hi Uma

Thanks for this, in line below.

From: Uma Chunduri <[email-masked]>
Sent: Friday, July 23, 2021 12:04 PM
To: David Allan I <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Dave,

Very good list and I am sure there could be a bit more functionalities GTP overlay  has been supporting over a period of time *and* still currently being used in various parts of the cellular networks.

Replacing overlays may be a good goal if we can bring the same technical benefits different underlays (L2, L2.5, IPv4, IPv6) bring to the table in various parts of the networks, in this case cellular deployments. We(IETF)  should develop tools towards the objective but I suspect we are there to replace any overlay (if this is the central goal) with a single underlay mechanism. Dino presented multiple times on this topic in various WGs/pre-bofs/BoFs and also asked to "get over with it" (a thin overlay).

One of the things that we all should ask ourselves is - what overlay functionalities we want to bring to underlay (L3/L2.5) as opposed to complete replacement of the overlay. IMO, this is a better question than "replacing".

DA> I think we are in a situation where what we need to bring forward in a solution mirrors what is there ESPECIALLY if the goal is a transparent stunt double to the higher level 5G System.  From what I can tell 3GPP already has a bit of a winnowing process if not from release to release, at least from generation to generation.  So we are not in a situation like for example, the early days of pseudowires where the deployed protocol landscape was massive and triage was definitely called for.   What is more then there was complete divergence in systems as you moved up the stack whereas transport for 5G serves a common higher level system.

The sorts of features we are seeing in the larger 3GPP picture AFAIK are more recent additions for URLLC, CIoT etc.  So picking and choosing based on convenience is not an option; the problem space is not a matter of choosing what to support, but in replicating the functionality exists and having similar extensibility.

A further note is that GTP is not in isolation, and some functionalities are UE to UPF (e.g. QMP),  so interworking between “whatever” and RLC etc on the radio link is also table stakes.

At least that is the view from here
Regards
Dave

On Fri, Jul 23, 2021 at 10:50 AM David Allan I <david.i.allan=[email-masked]<mailto:[email-masked]>> wrote:
Hi:

Cheers
Dave

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 23 Jul 2021 16:52:04 -0700

Dear Dave,

I got what you are saying.

>The sorts of features we are seeing in the larger 3GPP picture AFAIK are
more recent additions for URLLC, CIoT etc.
>So picking and choosing based on convenience is not an option; the problem
space is not a matter of choosing what to support,
>but in replicating the functionality exists and having similar
extensibility.

In this particular case, I am afraid we can even take that kind of
undertaking to create a complete "Stunt Double" as you put it.  I also
believe this is not under the purview of IETF and inevitably we intervene
with their control plane procedures to create this kind of framework.

I still believe we ought to develop value addition functionalities in
the transport network layer, applicable to these deployments which brings a
better E2E service. At the end of the day neither a packet traversing the
network doesn't know which SDO owns this nor the end user consuming the
service.

This is a generic comment and I am not implying to any particular work
being done here.

BR!
--
Uma C.

---

From: David Allan I <[email-masked]>
Date: Sat, 24 Jul 2021 16:14:43 +0000

HI Again:

One quick comment in line:

Cheers
Dave

From: Uma Chunduri <[email-masked]>
Sent: Friday, July 23, 2021 4:52 PM
To: David Allan I <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Dear Dave,

>The sorts of features we are seeing in the larger 3GPP picture AFAIK are more recent additions for URLLC, CIoT etc.
>So picking and choosing based on convenience is not an option; the problem space is not a matter of choosing what to support,
>but in replicating the functionality exists and having similar extensibility.

In this particular case, I am afraid we can even take that kind of undertaking to create a complete "Stunt Double" as you put it.  I also believe this is not under the purview of IETF and inevitably we intervene with their control plane procedures to create this kind of framework.

I still believe we ought to develop value addition functionalities in the transport network layer, applicable to these deployments which brings a better E2E service. At the end of the day neither a packet traversing the network doesn't know which SDO owns this nor the end user consuming the service.

DA> I’d consider the “stunt double” capability in the user plane to be table stakes, the “value add” beyond that point is the “justify your existence” moment 😊

This is a generic comment and I am not implying to any particular work being done here.

BR!
--
Uma C.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 27 Jul 2021 18:35:37 +0000

Hi Dave,

Many thanks for your comments. Inline with PC.

Cheers,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of David Allan I
Sent: viernes, 23 de julio de 2021 19:51
To: [email-masked]
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi:

-  adding X2 to the list of interfaces to be supported
[PC] Do you think there is any new mechanism to be added to the currently defined ones?

-  support for end-marker for handoff stream synchronization (probably could fit the unused bit in Args.Mob.Session but frankly I have not studied this in detail)
[PC] User Plane Message encoding is out of the scope of this draft. However, draft-murakami-dmm-user-plane-message-encoding-03 proposes a mechanism to encode the Echo Request, Echo Reply, Error Indication, and End Marker.

-  support for QMP (quality measurement protocol), which I believe needs to also extend across the radio interface so is not simply local to the GTP domain and can be "stunt doubled"
[PC] Excellent point. Seems we missed this one in draft-murakami! We can add in there the QoS Monitoring Packet indicator, as well as the encoding for the timestamps and average DL/UL delays.

-  support for paging policy presence/indication
[PC] Same as previous. Many thanks. 

[PC], By the way, I've posted an updated revision as the reference to draft-murakami was missing.

Cheers
Dave

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 28 Jul 2021 19:03:55 +0530

Hi Pablo / Dave all,

See my additional comment inline marked [SB]

Regards
Sridhar

On Wed, Jul 28, 2021 at 12:06 AM Pablo Camarillo (pcamaril) <pcamaril=
[email-masked]> wrote:

> [SB] If we are including X2 then F1U also needs to be considered. Both X2
and F1U also have GTPU flow control mechanism defined in TS 38.425. I am
not sure if a corresponding feedback mechanism exists in SRv6 for flow
control.

> [PC] User Plane Message encoding is out of the scope of this draft.
> However, draft-murakami-dmm-user-plane-message-encoding-03 proposes a
> mechanism to encode the Echo Request, Echo Reply, Error Indication, and End
> Marker.
>
> [PC] Excellent point. Seems we missed this one in draft-murakami! We can
> add in there the QoS Monitoring Packet indicator, as well as the encoding
> for the timestamps and average DL/UL delays.
>

-- 
 o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)

Sridhar Bhaskaran

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 28 Jul 2021 13:50:28 +0000

Hi Sridhar,

Inline with PC2.

Thanks!

From: Sridhar Bhaskaran <[email-masked]>
Sent: miércoles, 28 de julio de 2021 15:34
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: David Allan I <[email-masked]>; [email-masked]
Subject: [SUSPECTED SPAM] Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi Pablo / Dave all,

Regards
Sridhar

On Wed, Jul 28, 2021 at 12:06 AM Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>> wrote:
Hi Dave,

Cheers,
Pablo.

-----Original Message-----
From: dmm <[email-masked]<mailto:[email-masked]>> On Behalf Of David Allan I
Sent: viernes, 23 de julio de 2021 19:51
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

Hi:

-  adding X2 to the list of interfaces to be supported
[PC] Do you think there is any new mechanism to be added to the currently defined ones?
[SB] If we are including X2 then F1U also needs to be considered. Both X2 and F1U also have GTPU flow control mechanism defined in TS 38.425. I am not sure if a corresponding feedback mechanism exists in SRv6 for flow control.
[PC2] The user plane message encoding, or Flow control, is out of the scope of this draft; but covered in draft-murakami-dmm-user-plane-message-encoding.
Speaking as a co-author of draft-murakami: up to now we did not consider X2, but if the working group believes there is value then we could add it. Thanks.

Cheers
Dave

Sridhar Bhaskaran