Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

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

Hi Joel,

I believe the TEAS slicing framework is orthogonal and complementary to this. This draft, and many other technologies around IETF, will benefit from the slicing framework of TEAS.
Nonetheless, the text below is one of the key motivations, but not the only one. More details on the other key points in here: draft-kohno-dmm-srv6mob-arch-04

Many thanks,
Pablo.

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: miércoles, 16 de junio de 2021 0:03
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

Actually, assuming that the IETF TEAS network slicing definitions / framework and follow-on work is successful, it should be quite possible to deliver appropriate services (network sliced service based on IETF network slices) to 3GPPP GTP encapsulated 5G traffic while using the GTP-U encapsulation.  SRv6 is likely to be one of several transport mechanisms available to do so.

So if the inability to do so is the premise of your document, it appears to me that there is no need for the document.

Yours,
Joel

PS: In fact, it is pretty clear that the needed services can be delivered even now in conjunction with GTP.  The TEAS work will make managing and coordinating that delivery interoperably easier.

On 6/15/2021 3:01 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Jeffrey,
> 
> I've already provided one of the key motivations in my previous email. There is an operational challenge in the current mobility networks: there are no means to have a fine-granular SLA across both the mobile and the transport network. SRv6 is bridging this gap by integrating the underlay and the overlay control from the source node (either the gNB or the UPF).
> I am not aware of any standardized solution that solves this problem.
> Therefore, I disagree on your statement "the only benefit of SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints".
> 
> Cheers,
> Pablo.
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> Sent: lunes, 14 de junio de 2021 22:19
> To: Pablo Camarillo (pcamaril) <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> As you have alluded to, we're not converging but that's ok.
> 
> My point is not to write a draft about SRv6-transported-GTP-U (there is no need for such draft, just like we don't need another draft about "transporting foo" with SRv6). My point is that the only benefit of SRv6-replacing-GTP-U is the MTU saving between SRv6 tunnel endpoints.
> 
> There are other details that need to be taken care of in the draft, which we have been discussing.
> 
> Jeffrey
> 
> -----Original Message-----
> From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Sent: Monday, June 14, 2021 3:47 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Jeffrey,
> 
> Inline with [PC6]. Many thanks for your explicit answers.
> 
> Cheers,
> Pablo.
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> Sent: lunes, 14 de junio de 2021 21:01
> To: Pablo Camarillo (pcamaril) <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> Let me also copy (zzh2>, zzh3>) and explicitly add (zzh4>) my answers below.
> 
> -----Original Message-----
> From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Sent: Monday, June 14, 2021 2:22 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Jeffrey,
> Inline with [PC5].
> Cheers,
> Pablo.
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Sent: lunes, 14 de junio de 2021 19:32
> To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; 
> Pablo Camarillo (pcamaril) <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> If we look at the my original points:
> [PC5] Jeffrey, I believe both of your points have been answered. I've copied the relevant answers for your reference here below with PC, PC2 and PC4. Answer does not differ. If any clarification is needed on my previous answers, please let me know. Thanks.
> 
> -------
> 1. Since GTP-U can be transported over SRv6, which can also make use of TE capability and used for service programing (NFS chaining), the only real difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes part of the IPv6 address). With that, most of " 3.  Motivation" are not really applicable.
> [PC] The integration of the overlay with the underlay SLA and service chaining cannot be achieved with GTP-U.
> [PC2] As documented in 5.2, the SID list imposed by the source node includes segments for traffic engineering, NFV, and the overlay creation -all within the context of one network slice-. All the intermediate nodes in the fabric are stateless, hence you achieve highly scalable SLA.
> [PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. Then the cell site router needs to do a mapping of GTP-U sessions to SLA policies. This implies that you need some mapping mechanism at the Cell Site Router, that needs to have state. The gNB will not have any control of the underlay path, ...
> 
> Zzh2> For SRv6-transported GTP-U, why can't the gNB itself put on the appropriate SRH like in the SRv6-replacing-GTP-U case?
> Zzh2> As quoted/discussed later, even in SRv6-replacing-GTU-U case, the gNB does not get the SRv6 information from the AMF:
>     The gNB MAY resolve the IP address received via the control plane
>     into a SID list using a mechanism like PCEP, DNS-lookup, LISP
>     control-plane or others.  The resolution mechanism is out of the
>     scope of this document.
> Zzh2> With that, even if you have a separate device to do the mapping, why can't that device do the same?
> Zzh2> In other words, I still don’t see difference wrt SLA between SRv6-transported-GTP-U and SRv6-replacing-GTP-U.
> [PC3] If the gNB also adds the SRH as you suggest, then you are changing the N3/N9 interface as well.
> 
> Zzh3> Wouldn't it be the other way around - SRv6-replacing-GTP-U is "changing the N3/N9 interface"? SRv6-transported-GTU-U is still the same N3/N9 interface, just that now they have SRH for traffic steering purpose.
> [PC4] SRv6-replacing-GTP-U is a change in the N3/N9 interface.
> 
> Zzh4> I said in zzh2> that with SRv6-transported-GTP-U, gNB could also add traffic steering via SRH - no different from SRv6-replacing-GTP-U. You said that's changing N3/N9, and I replied in zzh3> SRv6-replacing-GTP-U is changing the N3/N9, which you confirmed in [PC4]. Therefore, you have not really countered zzh2> above.
> [PC6] There are no means to have fine-grained mapping of transport SLA with the mobility SLA.
> [PC6] Any transport protocol that encapsulates the gNB packet in the cell site router cannot achieve fine-grained SLA due to scaling limitations and control plane complexity.
> [PC6] One option to solve this problem is to use SRv6 as a replacement to GTP-U, whereas the gNB encodes the SLA in the packet. This is what this draft is about.
> [PC6] Certainly you write a new I-D to define a new N3/N9 interfaces that bundle together the overlay and underlay protocols (e.g. the gNB pushes the GTP-U header together with the MPLS label stack of the transport). I don't see the benefits of such approach, and this draft is not proposing anything close to it.
> 
> -------
> Aggregation can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 replacing GTP-U.
> [PC4] I'm not aware that 29.281 allows aggregating N3/N9 traffic from different TEIDs into the same TEID -despite from any local policy-. That said, this I-D is not proposing a change in GTPU. Hence, any discussion on GTPU aggregation or change to allow it in GTP-U is out of the scope of this draft.
> -------
> Zzh4> It's not clear why you would refer to 29.281 - since it certainly does not talk about SRv6 either. Local policy means it's local behavior based on unchanged N2/N4 - if you play SRv6 tricks for aggregation one can certainly play other tricks for GTP-U based on local policy. I understand that aggregation in GTP-U (via local policy) is outside the scope of this draft and I am not suggesting to add that - my point is only that the aggregation benefit is not only enabled by or exclusive to SRv6.
> [PC6] I completely agree with you. Aggregation can be achieved with GTP-U. It needs to be modified first though, as 29.281 -or any other 3GPP spec- does not seem to allow it; while in the case of SRv6 we are writing an I-D that explicitly allows it.
> [PC6] Please let me know if there is any action item with respect to this comment on this I-D. As said, GTP-U aggregation is out of the scope of the document.
> Zzh4> In summary, the benefit of SRv6-replacing-GTP-U is really just the MTU saving between the SRv6 endpoints, and I have not seen a real counter argument against that.
> [PC6] I disagree with this comment for the reasons exposed above.
> Zzh4> Jeffrey
> [PC6] Please let me know whether there is any extra clarification needed.
> 
> Our exchanges had some clarifications on details, but I don't think the above points have been invalidated.
> [PC5] Please let me know whether there is any clarification needed on top of the previous answers.
> 
> Jeffrey
> 
> -----Original Message-----
> From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Sent: Monday, June 14, 2021 1:16 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Pablo Camarillo 
> (pcamaril) <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Jeffrey,
> Inline with PC4.
> Pablo.
> 
> -----Original Message-----
> From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: lunes, 14 de junio de 2021 18:00
> To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> Hi Pablo,
> 
> Please see zzh3> below. I don't agree with the two [PC3] points.
> 
> -----Original Message-----
> From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Sent: Friday, June 11, 2021 10:17 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Jeffrey,
> 
> Inline with [PC3].
> 
> Thanks,
> Pablo.
> 
> -----Original Message-----
> From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: lunes, 7 de junio de 2021 15:58
> To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DMM] 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: Friday, June 4, 2021 12:53 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Inline with PC2.
> Many thanks and have a good weekend.
> 
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> Sent: martes, 1 de junio de 2021 16:46
> To: Pablo Camarillo (pcamaril) <[email-masked]>
> Cc: [email-masked]
> Subject: RE: 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: Tuesday, June 1, 2021 7:23 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Jeffrey,
> 
> Thanks for the reviews. Answers inline with [PC].
> 
> Thanks,
> Pablo.
> 
> -----Original Message-----
> From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: martes, 1 de junio de 2021 4:33
> To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; 
> [email-masked]
> Subject: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13
> 
> After many email exchanges and seeing two revisions (-12, -13), I now have a much better understanding of the draft. Here my further observations/understanding/comments.
> 
> Observations/Understanding:
> 
> A. This does *not* require *any* changes in the N2/N4 signaling. AMF/SMF/gNB/UPF will still use existing signaling based on GTP-U, but gNB/UPF will use either SRv6 or GTP-U tunnels based on local policy.
> B. If both ends (gNB/UPF) of a tunnel use SRv6, no interworking is needed, and two modes (traditional/enhanced) are defined. This is in section 5.1 and 5.2 respectively.
> C. If gNB does not use SRv6 but UPF does, an SRGW is placed next to the gNB. This is covered in 5.3 using enhanced mode example, but can be applied to traditional mode as well.
> D. If neither gNB nor UPF uses SRv6, GTP-U tunnels could still be changed to SRv6 between two GWs - another SRGW is placed next to the UPF as well. This is covered in 5.4 and referred to as drop-in mode.
> 
> [PC] All the observations look good, with a side note on A: Future documents may define a new signaling.
> 
> Comments:
> 
> 1. Since GTP-U can be transported over SRv6, which can also make use of TE capability and used for service programing (NFS chaining), the only real difference between SRv6 tunnel and GTP-U tunnel is that the UDP/GTP-U header is no longer needed in the SRv6 tunnel case (in particular, the GTP-U TEID becomes part of the IPv6 address). With that, most of " 3.  Motivation" are not really applicable.
> [PC] The integration of the overlay with the underlay SLA and service chaining cannot be achieved with GTP-U.
> 
> Zzh> Can you elaborate how they're achieved w/ SRv6 replacing GTP-U and not achieved with SRv6 transported GTP-U?
> [PC2] As documented in 5.2, the SID list imposed by the source node includes segments for traffic engineering, NFV, and the overlay creation -all within the context of one network slice-. All the intermediate nodes in the fabric are stateless, hence you achieve highly scalable SLA.
> [PC2] With an SRv6 transported GTP-U, the gNB only inserts the GTP-U header. Then the cell site router needs to do a mapping of GTP-U sessions to SLA policies. This implies that you need some mapping mechanism at the Cell Site Router, that needs to have state. The gNB will not have any control of the underlay path, ...
> Zzh2> For SRv6-transported GTP-U, why can't the gNB itself put on the appropriate SRH like in the SRv6-replacing-GTP-U case?
> Zzh2> As quoted/discussed later, even in SRv6-replacing-GTU-U case, the gNB does not get the SRv6 information from the AMF:
>     The gNB MAY resolve the IP address received via the control plane
>     into a SID list using a mechanism like PCEP, DNS-lookup, LISP
>     control-plane or others.  The resolution mechanism is out of the
>     scope of this document.
> Zzh2> With that, even if you have a separate device to do the mapping, why can't that device do the same?
> Zzh2> In other words, I still don’t see difference wrt SLA between SRv6-transported-GTP-U and SRv6-replacing-GTP-U.
> [PC3] If the gNB also adds the SRH as you suggest, then you are changing the N3/N9 interface as well.
> 
> Zzh3> Wouldn't it be the other way around - SRv6-replacing-GTP-U is "changing the N3/N9 interface"? SRv6-transported-GTU-U is still the same N3/N9 interface, just that now they have SRH for traffic steering purpose.
> [PC4] SRv6-replacing-GTP-U is a change in the N3/N9 interface.
> [PC4] SRv6-transported-GTP-U, if SRv6 is starting at the gNB and terminating at the UPF, to me it is also a change in N3/N9.
> [PC4] SRv6-transported-GTP-U, if SRv6 is the transport starting at the cell site router, to me this is NOT a change in N3/N9.
> 
> [PC2] By the way, the limitations of SRv6 transported GTP-U are also present in the Drop-in mode of this document.
> 
> [PC] Actually you have a lot more of motivation in this document: 
> draft-kohno-dmm-srv6mob-arch-04
> 
> Zzh> I had similar comments in that thread.
> 
> 2. Besides the TEID, there are other parameters in the GTP-U header. How those are represented in the SRv6 header needs to be defined.
> [PC] draft-murakami-dmm-user-plane-message-encoding-03
> 
> Zzh> That should be a normative reference then.
> [PC2] I don't think any of those is required to implement the I-D. I could foresee an operator that is interested on this ID to also be interested on that one, but I don’t think this is a reason to add the normative reference..
> Zzh2> This document assumes that the 5G NFs will encode/decode SRv6 headers based on signaled GTP-U parameters, or GWs will convert between GTP-U and SRv6 headers. If that does not warrant a normative reference to draft-murakami, I am not sure what normative references are for. I'll defer this to chairs/ADs/IESG.
> 
> 3. I still think there is no need to define the traditional/enhanced mode (see my reasoning below).
> 4. Now it's not clear if the interworking mode (including the drop-in mode) is worth the trouble (see my reasoning at the end).
> [PC] Answers to 3 and 4 below.
> 
> Let me expand on #3 above.
> 
> "5.1.  Traditional mode" focuses on the one-to-one mapping among (PDU session, GTP-U tunnel, SRv6 tunnel) and casually mentions "SID list only contains a single SID".
> " 5.2.  Enhanced Mode" talks about two things: SID list for TE and service programing/chaining, and scalability improvement via aggregation.
> 
> 5.2 says:
> 
>     The gNB MAY resolve the IP address received via the control plane
>     into a SID list using a mechanism like PCEP, DNS-lookup, LISP
>     control-plane or others.  The resolution mechanism is out of the
>     scope of this document.
> 
> That means the use of SID list for TE and service programming is not per the mobile architecture, but purely per operator's choice [PC] Indeed. The operator is the one that decides whether traffic needs a particular SLA. As in wireline...
> , and it can also be used for both traditional mode and SRv6-transported GTP-U tunnels - really nothing special to be limited to enhanced mode only.
> It is true that some gNB may not be able to put on an SRH, but that equipment limitation should not become a criteria - just like that for general SRv6 (outside this mobile user plane context) we don't have "basic" vs. "advanced/enhanced" modes just because some devices cannot insert SRH.
> [PC] The motivation behind traditional mode is:
> "   The traditional mode minimizes the changes required to the mobile
>     system; hence it is a good starting point for forming a common
>     ground."
> 
> Zzh> Why did we not have "basic" vs. "advanced/enhanced" modes for SRv6 in wireline networks 😊 There is no change to mobile system/architecture, except the transport network, which is no different from wireline.
> [PC2] Fair point. 😉 I understand your opinion, but after three years the working group seemed to prefer the traditional mode. I note your preference.
> 
> Defining traditional/enhanced mode based on aggregation is more reasonable. However, consider the following aspects:
> 
> - Currently only up link traffic can benefit from aggregation, and 
> that's only when the AMF provides the same <UPF address, TEID> for 
> multiple PDU sessions
> - The same can be done for traditional GTP-U, SRv6 transported GTP-U, or SRv6 replacing GTP-U.
> [PC] GTP-U does not allow that. Certainly you could go to 3GPP and change the specs to allow it, but as per today it is not allowed.
> 
> Zzh> We established that there is no change to N2/N4 or mobile architecture: AMF/SMF continue to signal GTP-U parameters like <tunnel endpoint, TEID> but gNB/UPF may use SRv6 replacing GTP-U per local policy. With that, how is uplink aggregation achieved?
> [PC2] The local policy indicates to aggregate several bearers into the same SRv6 SID list.
> Zzh2> For GTP-U, whether transported by SRv6 or not, traffic is routed based on the UPF/gNB address - that is aggregation already. If finer granularity is needed, similar local policy (to the ones used in SRv6-replacing-GTP-U case) can aggregate smaller subsets of UEs, right?
> Zzh2> Basically, I really don't see any difference.
> [PC3] As stated above, certainly you change the current GTP-U spec to allow aggregation as proposed in this I-D. However, the current GTP-U standard does not allow it.
> 
> Zzh3> There is no change to GTP-U spec or N2/N4 interface. As stated above, it is the local policy (when finer granularity is needed) that does the aggregation - no different from SRv6-replacing-GTP-U.
> [PC4] I'm not aware that 29.281 allows aggregating N3/N9 traffic from different TEIDs into the same TEID -despite from any local policy-. That said, this I-D is not proposing a change in GTPU. Hence, any discussion on GTPU aggregation or change to allow it in GTP-U is out of the scope of this draft.
> Zzh3> Jeffrey
> 
> Zzh2> Jeffrey
> 
> Zzh> Thanks.
> Zzh> Jeffrey
> 
> The reason the aggregation is not applicable to downlink traffic is because the gNB does not do IP lookup based on inner header.
> [PC] Indeed that is one option. That is new compared to today's mobile architecture. I don’t think its complex to implement though. End of the day we've done it for quite some time in wireline. Another option is to forward to a group of UEs and let the UE drop the packet based on the IPV6 DA.
> Rather, downlink traffic forwarding on a gNB is purely based on TEID (whether it is in the GTP-U header or in the SRv6 SID). Therefore, the uplink aggregation or downlink aggregation (if gNB starts doing IP lookup based on inner header, which would be a big departure from existing architecture) is really controlled by the mobile architecture, not by the use of SRv6 tunnel. To achieve aggregation, the AMF/SMF will need to signal different GTP-U parameters, even though the signaling format does not need to change.
> 
> As a result, defining traditional/enhanced mode for SRv6 user plane really is not necessary.
> [PC] There is a motivation behind each of the modes. Operators find it easier to deploy this way.
> 
> Now let me expand on #4 above.
> 
> There is no real difference between SRv6-transported GTP-U  and SRv6 replacing GTP-U (other than that the latter does not have UDP/GTP-U headers). If both tunnel ends can support SRv6 natively, it's reasonable to use SRv6 tunnels (replacing GTP-U) right at the tunnel ends. But if a gNB has to start/end with GTP-U (with the UDP/GTP-U headers), what is the benefit of converting to/from SRv6 by a GW, which means additional capex/opex? It's an additional failure point - the implementation could have bugs and it could fail for various reasons. It may be better off to only do SRv6 tunneling when both ends can support it. It's not clear to me that the bandwidth saving between the GW and UPF is worth the trouble.
> [PC] Well... there are two differences between SRv6-transported GTPU and SRv6 replacing GTP-U. The first and obvious is the removal of the UDP/GTP-U header -which already has huge benefits as the IPv6 Flow Label for entropy 😉-. The second and most interesting difference is that the SRv6 replacement of GTP-U allows the integration of the overlay with the underlay SLA and service chaining. More in draft-kohno-dmm-srv6mob-arch-04.
> 
> These are high level comments. I may have more to come, and I definitely have more text/wording comments to share afterwards.
> 
> Thanks.
> Jeffrey
> 
> Juniper Business Use Only
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm_
> _;!!NEt6yMaO-gk!TuSYNLYkiLkieDF_Rvz9641_tQoKTcUOG-4qEG4eLshWb-mDfdVjr_
> YwD9DLfzGU$
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm_
> _;!!NEt6yMaO-gk!Sx5QlZ5tYiUVPbgIXEQfo3TCPMtohG0NFBC42ie9MbEDb5emPpkAeW
> rOJgJ1JgQ3$
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm_
> _;!!NEt6yMaO-gk!Sc4_uTC6g9WGXUpKJ2nlwgUzssL4oYfk82fb2KzDDkczbl6d2OPlrP
> g8r6Qn-opA$
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> 
> Juniper Business Use Only
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Jul 2021 13:40:15 -0400

You asserted that certain needs can not be met without the changes to 
the 3GPP architecture this draft calls for.

Clearly, 3GPP does not agree as they have declined to make the changes 
you are asking for.

Equally, the IETF appears not to agree, as we have some approaches that 
appear to work without these changes, and are developing others.  (I 
admit this is an individual judgment, but then so is the problem kohno 
draft you are pointing at.)

More importantly, the IETF has no business changing the 3GPP 
architecture.  We object (have in the past, and expect would in the 
future) when people change IETF architecturse externally to the IETF. 
We owe other SDOs the same respect.

Yours,
Joel

---

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

Joel,

What this draft is doing is defining the building blocks for a mobility architecture with SRv6. The building blocks are the new SRv6 behaviors for the dataplane.
IETF is providing the tool. If 3GPP wishes to adopt it in their specifications, it is up to them to do it. But this document does not change any 3GPP architecture.

Cheers,
Pablo.

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: miércoles, 21 de julio de 2021 19:40
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] Comments on draft-ietf-dmm-srv6-mobile-uplane-13

You asserted that certain needs can not be met without the changes to the 3GPP architecture this draft calls for.

Clearly, 3GPP does not agree as they have declined to make the changes you are asking for.

Equally, the IETF appears not to agree, as we have some approaches that appear to work without these changes, and are developing others.  (I admit this is an individual judgment, but then so is the problem kohno draft you are pointing at.)

More importantly, the IETF has no business changing the 3GPP architecture.  We object (have in the past, and expect would in the
future) when people change IETF architecturse externally to the IETF. 
We owe other SDOs the same respect.

Yours,
Joel

On 7/21/2021 1:34 PM, Pablo Camarillo (pcamaril) wrote:
> Nonetheless, the text below is one of the key motivations, but not the 
> only one. More details on the other key points in here:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Jul 2021 13:33:10 -0400

If providing behavioral building blocks is your intention, then in my 
opinion you need to

1) Go through and edit the document to remove all the places where you 
change 3GPP defined nodal operation / behavior.

2) Focus on the Srv6 endpoint behaviors, and take it to SPRING to define 
those, rather than focusing on the mobile system behavior.

Given the sheer number of behaviors that have been defined with minimal 
explanation of why all the different variations are needed, I doubt that 
getting a few more would be a problem.

As currently written, the draft does things that do not align with the 
purpose you describe below.

Yours,
Joel

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 22 Jul 2021 17:37:32 +0000

Working Group - 

Thank you for all the feedback and the lively discussions on this LC. Thank you for that. At the same time, we do want to structure these discussions, as it is all over the place. Few points:

1. Any comments on the technical approach, clarifications and things which are in editorial in nature are totally welcome and are in scope of the WGLC.

2. Any discussions such as a given SDO may use it, or that they have other plans ..etc are outside the scope of this discussion. We have already explained and concluded on our approach for bringing forward looking work to IETF. This approach is not unique to this document, or a special favor that is being extended to this document. As I have said before, IETF is not an extension to any SDO organization, we are not at their mercy to move work in IETF. We will propose extensions that the IETF community supports and sees value, for building a better internet, and is not conditional to SDO's approval. The SDO may not adopt it in this release, but they choose to do so in the future. 

We therefore request the WG to keep these two things in mind. We do want to conclude these discussions very soon. Please be very specific on your objections and suggestions.

Sri