Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 1 Jun 2021 11:20:01 +0000

Hi Jeffrey,

Inline with [PC5]. I believe this last answer with the two updated I-D revs addresses all your comments in this email. Let me know if this is not the case.

I will answer your other thread separately.

Many thanks,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> 
Sent: miércoles, 26 de mayo de 2021 14:25
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see  zzh4> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, May 21, 2021 5:40 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]

Hi Jeffrey, Joel,
What this draft is doing is defining the building blocks for a mobility system with SRv6. The building blocks are the new SRv6 behaviors.
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.

Jeffrey,
I've posted an updated revision (rev13) of this document based on the previous comments/feedback.
See answers to the remaining points inline with [PC4].
Many thanks for all your feedback.

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: miércoles, 19 de mayo de 2021 22:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

One can say "this solutions relies on VLAN which is outside the scope of this document", because VLAN is specified somewhere else.
This document relies on changed 3GPP architecture and control plane, yet I don't see that 3GPP will adopt those changes anytime soon. You mentioned another mobile architecture could adopt this, but I don't know if there is another mobile architecture. With that, I don't see how we can put this document on standard track at this time.

Of course, if you state that 3GPP architecture/control plane does not change at all, and a UPF/gNB uses SRv6 based on signaled GTP-U parameters autonomously per local policy, then it's a different situation.

A few zzh3> embedded below.

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: Wednesday, May 19, 2021 12:49 PM
To: Pablo Camarillo (pcamaril) <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

[External Email. Be cautious of content]

It is reasonable to say that control plane changes are out of scope for the document.

However, defining a data plane behavior that does not work with the existing control plane does require dealing somehow with the fact that this document changes the 3GPP architecture and control plane.  Even if it does not specify how those changes should be realized.

Yours,
Joel

On 5/19/2021 12:35 PM, Pablo Camarillo (pcamaril) wrote:
> Hi Jeffrey,
>
> Inline with [PC3].
>
> Cheers,
> Pablo.
>
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> Sent: lunes, 17 de mayo de 2021 22:22
> To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi Pablo,
>
> Please see zzh2 > below.
>
> -----Original Message-----
> From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Sent: Friday, May 14, 2021 4:15 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> [External Email. Be cautious of content]
>
>
> Hi Jeffrey,
>
> Many thanks for your reply. Good to see some of your points are resolved now. Answers to the remaining points below inline with [PC2].
>
> Cheers,
> Pablo.
>
> -----Original Message-----
> From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
> Sent: miércoles, 5 de mayo de 2021 20:37
> To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
> Cc: [email-masked]' <[email-masked]>
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi Pablo,
>
> A lot of my questions/confusion came from the fact that in many cases described in this document, the gNB/UPF will use SRv6 in place of GTP-U based on changed N2/N4. That was not clear to me because my understanding is that 3GPP has *not* agreed on using SRv6 in place of GTP-U.
>
> [PC2] As stated in the draft "The user plane described in this document does not depend on any specific architecture."
>
> Zzh2> Because many sections are based on changed N2/N4 interfaces, so this document does depend on a changed architecture not yet approved by 3GPP, with the exception of drop-in mode (which is transparent to 3GPP)?
> [PC3] As stated in the I-D, control plane specification is out of the scope of this document. So not sure I follow your point on N2/N4 above...
>
> I could be wrong on that, but if the understanding is correct, I do not think IETF/DMM should standardize this. At most an experimental document to show how IETF views SRv6 could be used for mobile user plane. The drop-in mode is fine, but I am curious why bother have GWs messing with the packets, and what are the security implications.
>
> I still need some help understanding the modes better.
>
> Please see zzh> below. I snipped some exchanges to focus remaining questions/comments.
>
> -----Original Message-----
> From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
> Sent: Tuesday, May 4, 2021 6:36 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
> Subject: RE: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> [External Email. Be cautious of content]
>
>
> Hi Jeffrey,
>
> Many thanks for your review. We've posted an updated revision of the document (rev12). Comments inline with [PC].
>
> Thanks,
> Pablo.
>
> -----Original Message-----
> From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
> Sent: miércoles, 21 de abril de 2021 6:49
> To: Erik Kline <[email-masked]>; SPRING WG <[email-masked]>; 
> [email-masked]
> Subject: Re: [DMM] [spring] note: WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> Hi,
>
> I noticed this late and just did a rushed review of the document, so pardon if my questions and comments do not make sense.
>
> It seems that there is no real difference between traditional mode and enhanced mode - it's just whether an SRH is used for TE purpose or not. Is there a need to define these two modes? For example, section "5.3.  Enhanced mode with unchanged gNB GTP behavior" should work with traditional mode as well.
>
> 5.2 does talk about "scalability" and "service programming", but the they're not elaborated by the example. I think it's important to elaborate since you introduced the two modes.
> [PC] The example does talk about service programming (S1 is a VNF). Ack on the scalability, which is briefly mentioned but not explained in detail. I've added more on it to the document. Thanks.
> Zzh> It seems to me that "service programming" and TE are both transparent; even for the "traditional" mode, the two functions can be applicable.
> [PC2] It is different for the source node, who needs to encode a SID list into the packet.
>
> Zzh2> Section 5.1 only talks about "there will be a unique SRv6 SID associated with each PDU Session" but does not talk SID list. If SID list is a key difference, it should be mentioned in 5.1 as well.
> [PC3] Sure, we can mention it explicitly.
> Zzh2> Section 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.
> Zzh2> I don't understand why the above can't be done for 5.1 as well. That's why I was asking why the SID list is a difference between the two modes.
> [PC3] You could very well define another mode based on the traditional where you also do that.
>
> In fact, I see the following later:
>
>     Even though we have presented these methods as an extension to the
>     "Enhanced mode", it is straightforward in its applicability to the
>     "Traditional mode".
>
> So I wonder why you need to define two modes.
> [PC] Traditional mode is simply a replacement of GTP-U as overlay protocol by SRv6. This minimizes changes to the mobile architecture. The enhanced mode allows to have intermediate SIDs for TE and NFV, but also allows to aggregate several devices under the same SID -which improves scalability-. The differences are covered in Section 5.2.
> Section 5.3 presents interworking mechanisms for the case whereas the N3 interface is unmodified. The interworking mechanisms presented in 5.3 are applicable to both Traditional and Enhanced mode.
>
> Zzh> About "This minimizes changes to the mobile architecture", I was assuming that it means the N2/N4 interface does not change and traditional <tunnel endpoint address, TEID> tuple is still  used in the control plane to identify a PDU session, but the gNB/UPF will map between the tuple (received on N2/N4) and SRv6 SID. Now it seems that N2/N4 are changed and GTP is not used at all. For that I don't think "this minimizes the changes to the mobile architecture".
> [PC2] On the control plane you send an IPv6 address, which now will be an SRv6 SID. In enhanced mode you need to pass a SID list of more than one SID, which needs modification on N2/N4 to be able to support it.
>
> Zzh2> For traditional mode don't you also need to modify N2/N4 to instruct gNB/UPF to use SRv6 instead of GTP-U?
> [PC3] Local policy to the node.
> Zzh2> In fact, your above text seems to suggest that the SID list is passed in N2/N4, which is contradicting to the following:
>     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> Can you clarify how the SID list is installed on gNB?
> [PC3] Local policy to the node. In the future you can define a new control plane to support it. That is out of the scope of this document.
>
> Zzh> On the other hand, the "drop-in" mode described later in 5.4 really "minimizes changes to the mobile architecture". Additionally, whatever mode it is (traditional/drop-in, enhanced w/ or w/o interworking), intermediate SIDs for TE/NFV should be applicable.
> [PC2] Drop-in mode does not have any change on the mobile architecture. Indeed the mobile architecture is completely agnostic from the SRv6 dataplane.
> Zzh2> That's what I mean, and that's the only mode I think that IETF/DMM can specify. Though some details are missing, e.g. how are all GTP-U functions achieved via SRv6 - there are other fields in the GTP header besides the tunnel destination address and TEID.
> [PC3]  What we are doing is defining the building blocks for a mobility system could work with SRv6. IETF is providing the tool. If 3GPP wishes to adopt it in their specifications, it is up to them to do it. If another mobile architecture, not based on 3GPP standards, wishes to use it, they can use it as well directly from our spec.
>
> Zzh> Section 5 says:
>
>     In order to simplify the adoption of SRv6, we present two different
>     "modes" that vary with respect to the use of SRv6.  The first one is
>     the "Traditional mode", which inherits the current 3GPP mobile user-
>     plane.  In this mode GTP-U protocol [TS.29281] is replaced by SRv6,
>     however the N3, N9 and N6 interfaces are still point-to-point
>     interfaces with no intermediate waypoints as in the current mobile
>     network architecture.
>
> Zzh> Don't " inherits the current 3GPP mobile user-plane" and "GTP-U protocol [TS.29281] is replaced by SRv6" contradict each other? The "inherits ..." caused major confusion to me and it should be reworded.
> [PC2]  There's a typo in the first sentence. s/user-plane/architecture. Updated draft.
> Zzh> My understanding is that N3/N9 interfaces are logical. Whether there are intermediate TE/NFV waypoints is transparent to 5GS (unless the NVF are actually 5G functions), so I don't understand why that is a distinguisher between the traditional and enhanced mode.
> Zzh> I understand that a gNB may not be able to push SRHs, but that should not become a factor of categorizing modes. Scalability is a reasonable factor but more on that later.
> [PC2] The difference is on the control plane towards the gNB (or its local policy in absence of a control plane), not a question of dataplane capabilities.
> Zzh2> If it's based on local policy, or if the control plane is not N2/N4, then the use of SRH does not seem to be a real difference between the two modes. Why can't it be applied to "traditional" mode as well?
> [PC3] I do see a difference in the local policy at the node, in having one vs several SIDs. As replied above, we could define a new mode based on the traditional where you also have this. This can be done. Another question is whether there is value to it. As stated in the draft:
> "   The traditional mode minimizes the changes required to the mobile
>     system; hence it is a good starting point for forming a common
>     ground."
>
> Zzh> 5.2 says:
>     The gNB control-plane (N2 interface) is unchanged, specifically a
>     single IPv6 address is provided to the gNB.
> Zzh> For clarity/parity, 5.1 should explicitly say that N2/N4 interfaces are changed.
> [PC2] Added in 5.1
> Zzh2> Now the above quoted text for 5.2 is a bit misleading. Obviously, the N2/N4 interface is changed in 5.2 as well, because it is now instructing gNB/UPF to use SRv6 instead of GTP-U?
> [PC3] Local policy at the node.
>
> Zzh> 5.2.1 says:
>
>     UE sends its packet (A,Z) on a specific bearer to its gNB.  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>.
>
> Zzh> What is that "IP address B"? The endpoint address of the tunnel? What's the TEID to use, and where is that TEID encoded in the packet (since we no longer has per-session SID)?
> [PC2] B is an address passes through control plane, that is used in the gNB to resolve the SID list. There is no TEID per-se, but instead different SIDs identify different sessions.
> Zzh2> So N2/N4 interface is indeed changed, not that "The gNB control-plane (N2 interface) is unchanged"?
> [PC3] You do not change the control plane to convey a SID list... It is the same as today.
Zzh3> It is not clear/consistent whether the SID list (for TE purpose) is from the AMF/SMF over N2/N4 or some other 3GPP independent controller; not using TEID or GTP-U anymore is also a change, unless you clearly say that the same N2/N4 signaling is used, just that a UPF or gNB will decide to use SRv6 based on signaled GTP-U parameters autonomously per local policy.
[PC4] I see your point. Added to the draft.

>
> Zzh> 5.2.2 says:
>
>     When the packet arrives at the UPF2, the UPF2 maps that particular
>     flow into a UE PDU Session.  This UE PDU Session is associated with
>     the policy <C1, S1, gNB>.  The UPF2 performs a H.Encaps.Red
>     operation, encapsulating the packet into a new IPv6 header with its
>     corresponding SRH.
>
>     Once the packet arrives at the gNB, the IPv6 DA corresponds to an
>     End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
>     underlying traffic).  The gNB decapsulates the packet, removing the
>     IPv6 header and forwards the traffic toward the UE.
>
> Zzh> While UPF2 can identify the PDU session based on the UE address, how is that session information encoded in the packet to gNB? Policy <C1, S1, gNB> is not session specific. I assume gNB is not a simple address, but a prefix followed by the arg bits that represents the session information. It should be made clear here.
> [PC2] I believe this is stated in 5.2.2
>     Once the packet arrives at the gNB, the IPv6 DA corresponds to an
>     End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
>     underlying traffic).  The gNB decapsulates the packet, removing the
>     IPv6 header and forwards the traffic toward the UE.
> Zzh2> So is this (downlink) the same as in traditional mode?
> [PC3] Not the same. The gNB behavior is the same as you say, but not the same downlink behavior for all the nodes.
Zzh3> I meant that the for the traditional mode, the gNB forwards downlink traffic based on END.DX2/4/6 as well, just like in the enhanced mode?
[PC4] Oh yes.

>
> Zzh> RFC8986 says:
>
>     The End.DX4 SID MUST be the last segment in an SR Policy, and it is
>     associated with one or more L3 IPv4 adjacencies J.
>
>     The End.DX6 SID MUST be the last segment in an SR Policy, and it is
>     associated with one or more L3 IPv6 adjacencies J.
>
> zzh> As I understand it, the connection between gNB and UE is *not* an IP/Ether adjacency, so not sure if DX2/4/6 can be used.
> [PC2] Can you please clarify? If the PDU is IP, then the adjacency is IP. Regardless of whether for example you send this traffic using pdcp.
> Zzh2> For IP PDU, the IP adjacency is between the UPF and UE, not between gNB and UE. My understanding of DX2/4/6 is that the cross-connect is on a local L2/IP PE-CE adjacency.
> [PC3] Why do you say there is no adjacency from gNB to UE?
Zzh3> No *IP* adjacency (for IP PDU session). It is the same as two IP nodes connected by an ethernet switch - the IP adjacency is between the two IP nodes not between the switch and an IP node.
[PC4] I disagree. A downlink packet from PGW/UPF is destined to an IP address belonging to the eNB/gNB. The eNB/gNB terminates this IP packet. Hence the eNB/gNB is an IP node. Do you agree with that? The gNB functionality is equivalent to that of a PE device: in the uplink it encapsulates the received customer packet from UE, and in the downlink it removes the GTP header and forward the packet to the UE.

Zzh4> gNB is certainly an IP device but its IP adjacency is in the "underlay" (transport network) not at the "overlay" (towards the UE).
[PC5] The End.DX4 behavior (or the others) are not limited or restricted by "underlay" vs "overlay" IP adjacencies. The behavior is the same: remove the encaps, forward on a particular IP adjacency (regardless of its type).
Zzh4> In the wireline/IETF VPN case, there is PE-CE IP adjacency. Traffic from CE is forwarded based on IP lookup in the VRF, whether the traffic to the CE requires IP lookup or not (i.e. whether per-CE or per-VPN label is used, or whether END.DT4/6/X is used).
Zzh4> In case of gNB, UE-gNB is not IP adjacency and traffic to/from a UE does not have IP lookup (based on the inner IP header) at the gNB.

>
> Zzh> 5.2.3 says:
>
>     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> The above compares it to both "unique SID per UE" and "dedicated TEID per UE". It means that the N2/N4 interface does not distinguish session anymore (at least for uplink traffic) and the aggregation is provided by the 5G itself and would work for GTP-U as well, and not provided by SRv6 or by the enhanced mode.
> [PC2] Neither traditional mode, nor GTP-U allows sharing TEIDs for different UEs. Hence the scale improvement.
> Zzh2> My point is that the sharing is not because of SRv6, but because there are cases you where you don't need to distinguish the source UE. That, if adopted by 3GPP, can be easily done to GTP-U as well.
> [PC3] We cannot evaluate on the basis of potential improvement to 3GPP standards that have not been done/proposed. Maybe you are right, and the same could be done with GTPU. But that is not the current status.
>
> Zzh> Per earlier questions/comments, the downlink traffic still has session information in the SRv6 header (so that END.DX is done), so the same SID list can't be used, and the scalability improvement is only for uplink traffic?
> [PC2] As stated in the beginning of 5.2
>     Additionally in this mode the operator may choose to aggregate
>     several devices under the same SID list (e.g., stationary residential
>     meters connected to the same cell) to improve scalability.
> Zzh2> Right - I wanted to confirm that the aggregation is only for uplink traffic. Is that so?
> [PC3] I don't see why you cannot do it for downlink traffic (e.g.
> traffic destined to water meter)
Zzh3> How does the gNB know if a packet is for meter1 vs. meter2? gNB does not do IP lookup (using inner IP address in the PDU).
[PC4] Several ways come to mind. gNB could do a lookup on the IP; it could forward to all meters and based on IP address each meter only process his packets...

Zzh4> Well that is not what gNBs do.
[PC5] Agreed. Laying out some new ways it could be done. 
>
> 5.3.1 says:
>
>     o  The gNB is unchanged (control-plane or user-plane) and
>        encapsulates into GTP (N3 interface is not modified).
>     o  The 5G Control-Plane (N2 interface) is unmodified; one IPv6
>        address is needed (i.e. a BSID at the SRGW).
>
> It seems that N4 needs to be changed so that SMF can tell UPF1 and UPF2 to use SRv6 instead of GTP. Or is that N4 still assuming GTP but UPF1 and UPF2 are configured to turn to GTP parameters into SRv6 stuff? That should be made clear here.
> [PC] The UPFs are SRv6 aware (and thus N4 interface as well). The gNB is the legacy device that still runs GTPU. This is explained at the beginning of the section.
>
> Zzh> UPFs being SRv6 aware does not necessarily imply N4 interface will actually tell UPFs to use SRv6 tunnel instead of GTPU. My impression is that 3GPP has not approved to use SRv6 yet so please make it clear if this document assumes that 3GPP approves using SRv6 via changed N2/N4 (vs. the devices autonomously use SRv6 based on signaled GTP-U parameters).
> [PC2] This document does not "assume that 3GPP approves using SRv6 via changed N2/N4"
> Zzh2> If 3GPP does not approve that, then only the drop-in mode can work?
> [PC3] Any mode can work on a mobile architecture. If you wish to use SRv6 on the 3GPP architecture, then 3GPP needs to adopt this standard into their 3GPP specs (in the same way they did with IPv6).
>
> Zzh> Besides, it is strange that 5GS will tell gNB to use GTP while telling UPF to use SRv6.
> [PC2] The decision to use of SRv6 is a local policy at the UPF. Alternatively, you could also choose to instruct this through a new control plane, but this is out of the scope of this document.
> Zzh2> If so, please make it clear that if N4 does not change, then the UPF make decision to use SRv6 per local policy, based on GTP-U parameters signaled on N4. That's why I was asking "Or is that N4 still assuming GTP but UPF1 and UPF2 are configured to turn to GTP parameters into SRv6 stuff? That should be made clear here"?
> [PC3] Good point. I'll add.
>
> In the following:
>
> 5.3.2.2.  Packet flow - Downlink
>
>     The downlink packet flow is as follows:
>
>     UPF2_in : (Z,A)                            -> UPF2 maps flow with SID
>                                                 <C1, S1,SRGW::SA:DA:TEID>
>     UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
>     C1_out  : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
>     S1_out  : (U2::1, SRGW::SA:DA:TEID)(Z,A)
>     SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A)       -> End.M.GTP4.E
>     gNB_out : (Z,A)
>
> How does UPF2 know the address of the gNB? In IPv6 case (5.3.1) the UPF1 knows the gNB address from the N4 signaling but shouldn't IPv4 case be the same?
> [PC] In both 5.3.1 and 5.3.2 the gNB address is provided in the SRH. In 5.3.1 it is provided as the next SID; in 5.3.2 it is provided as SID arguments.
> Zzh> For UPF2 to put the gNB address into the SRH, it has to learn it first. How/where does UPF2 learn the gNB address (for either IPv4 or IPv6 case)? My understanding is that when there is a UPF1 in place, UPF2 only knows about UPF1 not gNB.
> [PC2] Your understanding is correct, and since in this case there is no intermediate UPF, UPF2 only knows about gNB.
> [PC2] If there would be an I-UPF, then UPF2 would not know about gNB, and it would use an End.MAP SID at UPF1.
>
> Zzh2> Apparently, in Figure 6, there is a UPF1?
> [PC3] Typo. Ill change. Figure should state SRGW.
>
> Zzh> Additionally, since you mention SRGW is separate from UPF1, using the "SRGW::" prefix is confusing. How is UPF2 supposed to know about the SRGW which is supposed/assumed to be transparent?
> [PC2] Local policy at the UPF2.
>
> For the following:
>
> 5.3.2.3.  Scalability
>
> Is it the same as IPv6 case? If so it's better to just state so instead of repeating.
> [PC] It is not exactly the same, as in IPv6 the use of the BSID yields remote steering; while in the IPv4 case you need to have an Uplink Classifier in the SRGW that performs packet classification. While the diff is small, it is not equivalent.
>
> Zzh> I need to think this through. May come back to this later.
>
> What is a L3-anchor vs. L2-anchor?
> [PC] Different types of 3GPP UPF functionalities. Equivalent to SGW/PGW in 4G.
> Zzh> Can you give a reference for my better understanding? I can't find it.
> [PC2]. Sure 4.1.4.2 of
> https://urldefense.com/v3/__https://portal.3gpp.org/desktopmodules/Spe
> cifications/SpecificationDetails.aspx?specificationId=728__;!!NEt6yMaO
> -gk!RWgox3-e0-NCn506Dily-LC6qemqom36PnLRe0zsQOp6wg1L8TshqU0jmz-4A2GJ$
>
> Zzh2> 4.1.4.2 of 23.002 does not talk about l3/l2-anchor. Can you use well-known terms from 5G specifications?
> [PC3] 23.002 speaks about SGW (4.1.4.2.1) and PGW (4.1.4.2.2), which is 4G. If you are asking for 5G specification, then you should check 23.501 instead.
> [PC3] Also, you can check RFC6459.
Zzh3> I don't see l3/l2-anchor in either 23.002 or 23.501 or RFC6459. If you change l3/l2-anchor term to something already defined it'll be clear.
[PC4] RFC6459:
 Serving Gateway
      The Serving Gateway (SGW) is a gateway function in the EPS, which
      terminates the interface towards the E-UTRAN.  The SGW is the
      Mobility Anchor point for layer-2 mobility (inter-eNodeB
      handovers).
[PC4] Actually, the only appearance of l2/l3 is on a single parenthesis that could be removed. Removed from doc.

>
> For 6.4, how is the SGB::TEID written into the SRH? If it's via "S04.    Push a new IPv6 header with its own SRH containing B", does that mean we need one policy for each TEID?
> [PC] It is pushed in line S08.
> Zzh> The question is how the GTP information (e.g., TEID) is put into in the SRv6 header. Apparently, the policy needs to extract the TEID from the GTP header but the instructions does not talk about (S08 is about S which does not have the information).
> [PC2] Sure, we can make that explicit in S08.
>
> For the following rules in 6.5:
>
>     S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
>     S02.    Copy SRH[0] to buffer memory
>     ...
>     S08.    Set the GTP TEID (from buffer memory)
>
> Does SRH[0] corresponds to U::1 or SGB::TEID in the 5.4 example as quoted below?
>
>   C1_out  : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
>   GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z)            ->U1b::TEID is an
>                                                           End.M.GTP6.E
>                                                           SID at 
> SRGW-B [PC] U::1
> Zzh> Since U::1 does not have TEID, how does S08 get TEID "from the buffer memory"?
> [PC2] As stated in the Note right after the pseudocode: " The TEID is extracted from the argument space of the current SID."
> Zzh2> To do the extraction, I expected to see "Copy S to buffer memory" at step S02, but it's not there, hence the question.
> [PC3] Line S02 of the pseudocode. (S = SRH[0])

Zzh3> This is when " Segments Left == 1", so SRH[0] is not the S (current SID) but gNB according to 5.3.1.2?
[PC4] Correct

Zzh3> Additionally, for "S06.    Set the outer IPv6 DA to the first SID of B", what is B and what is "first SID of B"? B is sometimes a binding SID and sometimes a policy. According to 5.3.1.2, should S06 set the outer DA to "the gNB which is the last SID in  the received SRH", i.e. SRH[0]?
[PC4] Indeed, fixed.

> Zzh2> Additional question - I had thought that the UPF is using SRv6 w/o GTP. So when downlink traffic gets to the SRGW in 5.3.1.2, how is the S01 condition met (Next Header = UDP & UDP_Dest_port = GTP)? Does the SRv6 packet carry a complete UDP/GTP header (I had thought there is no UDP/GTP header at all when traffic leaves the UPF because we're using SRv6)? If yes, how is that different from transporting GTP over SRv6?
> [PC3] Indeed you are right. The packet does not have an GTP header, and the node builds it. It's a copy paste leftover. Ill remove s01.
>
> Zzh> A new question about 5.4:
>
>     gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z)
>     GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an
>                                                           End.M.GTP6.D.Di
>                                                           SID at SRGW-A
>     S1_out  : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z)
>     C1_out  : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
>     GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z)            ->SGB::TEID is an
>                                                           End.M.GTP6.E
>                                                           SID at 
> SRGW-B
>
> Zzh> gNB sends (gNB, U::1) packets and UPF also expects the same gNB source address. However, GW-B sends (GW-B, U::1) - wouldn't this cause trouble on the UPF if the there are security checks for the validity of source addresses?
> [PC2] The UPF has a route to the gateway, and hence uRPF does not fail. If this is what you mean...
> Zzh2> This is not about uRPF. I assume UPF would not just accept tunnel packets from any source address (to which it has a route) - it would only accept from know addresses it learned from SMF, right?
> [PC3] That, I would assume is implementation specific. Regardless, you can have local config on the UPF to allow it.
Zzh3> That needs to be pointed out, because existing solution does not have that issue.
[PC4] Do you have the pointer to any document or public info that states that "UPF would not just accept tunnel packets from any source address" ? Could you please share? Thanks.
Zzh4> I don't have that, but given the tight security control in mobile networks I would be surprised that's not done.
Zzh4> Thanks.
Zzh4> Jeffrey

[PC4] Many thanks!

Zzh3> Thanks.
Zzh3> Jeffrey

> Zzh2> Thanks.
> Zzh2> Jeffrey
>
> Zzh> Thanks.
> Zzh> Jeffrey
>
> Thanks.
> Jeffrey
>
> -----Original Message-----
> From: spring <[email-masked]> On Behalf Of Erik Kline
> Sent: Wednesday, April 7, 2021 11:59 PM
> To: SPRING WG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [spring] note: [DMM] WGLC on
> draft-ietf-dmm-srv6-mobile-uplane-11
>
> [External Email. Be cautious of content]
>
>
> Spring folk,
>
> Per request from spring chairs, I wanted to drop a note that a document discussing using SRv6 in a 3GPP carrier network is in dmm WGLC.  If this is of interest to you, please feel free to read and review (please direct comments to dmm@).
>
> Thanks,
> -Erik
>
>
> On Wed, Apr 7, 2021 at 10:35 AM Sri Gundavelli (sgundave) <sgundave=[email-masked]> wrote:
>>
>> Working Group:
>>
>>
>>
>> As we discussed in the last IETF meeting, we are issuing WGLC on draft-ietf-dmm-srv6-mobile-uplane-11.
>>
>> The document went through several revisions and there were good amount of reviews on this document. I am very pleased with the quality of this document. The authors have addressed all the comments and there are no open issues that we are tracking at this time. We believe the document is ready for IESG reviews and like to confirm the same from the working group.
>>
>>
>>
>> The following message commences a two week WGLC for all feedback.
>>
>>
>>
>> Document Link:
>>
>> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-iet
>> f
>> -dmm-srv6-mobile-uplane-11.txt__;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-
>> R TNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-zDgRDc4fJS$
>>
>>
>>
>>
>>
>> Please post any comments/concerns on this document.
>>
>>
>>
>>
>>
>> Thanks!
>>
>> Sri
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm
>> _
>> _;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW
>> -
>> zDgY0wXO9D$
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvB
> bW-zDgQZXTemu$
>
> Juniper Business Use Only
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm_
> _;!!NEt6yMaO-gk!VfY3TV_tyoDu-Jl2ZATcisDxW0ThG3_0UhTy33UgBAM_eiwNmnAps4
> fqtSRX3Ayz$
>
> 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!VNHWNg1AywcVwumOfK-yVC5puMExE-g3VVs65vQbSJHsRZ0IgUU9QF
> lZuQIUdvgY$
>

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 1 Jun 2021 14:04:00 +0000

Hi Pablo,

Let me pull this up:

-----------

---------

As I pointed out in zzh4>, the point is that there is *no IP adjacency* between UE and gNB.
Practically, a device can implement the END.DX4/6 behavior to forward IP traffic over non-IP adjacencies. It's just that RFC8986 specifically calls out IP adjacencies. You may want to point it out and see if SR folks have any concerns.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Tuesday, June 1, 2021 7:20 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Many thanks,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: miércoles, 26 de mayo de 2021 14:25
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see  zzh4> below.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, May 21, 2021 5:40 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey, Joel,

Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Sent: miércoles, 19 de mayo de 2021 22:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: Wednesday, May 19, 2021 12:49 PM
To: Pablo Camarillo (pcamaril) <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Yours,
Joel

[PC4] Many thanks!

Zzh3> Thanks.
Zzh3> Jeffrey

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 4 Jun 2021 16:52:11 +0000

Hi Jeffrey,

Why do you say there is no IP adjacency from gNB to UE? 
In the downlink, the gNB receives an IP packet from the UPF destined to itself. The gNB decapsulates such packet, and forwards the inner-exposed packet to the UE. Assuming the inner-exposed packet is IPv4, in such case the IPv4 Destination Address is the one of the UE. 

RFC1812: "Adjacent - reachable without going through any IP routers"

As far as I know, there is no IP router in between the gNB and the UE. Can you please clarify?

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> 
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 4 Jun 2021 20:06:27 +0000

Hi Pablo,

The IP adjacency to the UE is from the UPF, not from the gNB.
While gNB is an IP router, it is at the underlay. This is similar to the following situation:

    Host1     ---- EVPN PE1 --------- EVPN PE2 ---- Host2

Host1 and Host2 have IP adjacency, even though EVPN PE1 and PE2 are IP routers. Host1 and EVPN PE1 are not IP adjacent.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 11 Jun 2021 14:16:14 +0000

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> 
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Host1 and Host2 have IP adjacency, even though EVPN PE1 and PE2 are IP routers. Host1 and EVPN PE1 are not IP adjacent.
[PC] Your examples assume PDU Session Type is L2. In which case indeed there is no IP Adjacency (there is only a L2 adjacency).
[PC] If the PDU Session Type is either IPv4 or IPv6, then I believe the interface at the gNB facing towards the UE is IP enabled, and therefore there exists an IP adjacency. Similarly, in your example above there would be an IP adjacency in between Host1 and PE; as both interfaces (Host1 towards PE1, and PE1 from Host1) are IP based.
[PC] Also, for IPv4 or IPv6, Host1 and Host2 are not adjacent as per RFC1812, since the PE processes/forward the IP packet.
[PC] Please let me know whether you agree. It would be great if you can send me some pointer that I could read if you still think Im wrong.
[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 11 Jun 2021 16:14:30 +0000

Hi Pablo,

I have to say that we completely disagree on this one. Someone else will have to chime in if we want to get a conclusion 😊

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Zzh> In the UE---gNB---UPF scenario, even for IPv4/6 PDU session, there is no IP adjacency between UE and gNB.
Zzh> In the EVPN scenario above, there is no IP between Host1 and PE1 or between Host2 and PE2 either. It's just Ethernet. IP is between Host1 and Host2.

Zzh> For the EVPN example, EVPN is emulating an Ethernet network - no different from Host1 and Host2 being connected via two Ethernet switches.
Zzh> The UE case is similar, though it is not Ethernet below the IP, but a lower layer consisting of one segment being PDCP (3G case at least) and the other segment being GTP-U. I could only find a 3G picture here: https://www.researchgate.net/figure/3GPP-protocol-stack-see-9_fig1_224357167.
Zzh> Jeffrey

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

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

---

From: Kaippallimalil John <[email-masked]>
Date: Fri, 11 Jun 2021 16:42:32 +0000

Hi Pablo, Jeffrey, 
If the question is on IP adjacency in 3GPP, it is between the UE and UPF (PSA).

The gNB switches radio bearer (DRB) to IP flow (GTP-U) based on instructions from SMF (SMF --> AMF --> gNB).
The first router for the user's IP flow is the UPF.

An easy to read reference is RFC 6459 (refers to 4G, but the concepts in this case are similar)
MME (instead-of SMF) provisions eNB (i-o gNB) to switch radio bearer to GTP-U bearer, and IP adjacency is between UE - PGW (i-o UPF).
Or 3GPP TS 23.501, 5.8 (and other sections) provide more details.

BR,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Zzh> For the EVPN example, EVPN is emulating an Ethernet network - no different from Host1 and Host2 being connected via two Ethernet switches.
Zzh> The UE case is similar, though it is not Ethernet below the IP, but a lower layer consisting of one segment being PDCP (3G case at least) and the other segment being GTP-U. I could only find a 3G picture here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Ffigure%2F3GPP-protocol-stack-see-9_fig1_224357167&amp;data=04%7C01%7Ckjohn%40futurewei.com%7C456f17a4ee40443db5bb08d92cf40938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637590248940170467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=bxnRyzjBodb%2BBYJLGTt6lyznfGugXeU4ywY6ukgNVrQ%3D&amp;reserved=0.
Zzh> Jeffrey

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm__%3B!!NEt6yMaO-gk!UbiidCykEZnbLyjo8UMPaSlhktUmVxQv7QR3n6XJAj5q053iHL7Vj9-HloD_jsGX%24&amp;data=04%7C01%7Ckjohn%40futurewei.com%7C456f17a4ee40443db5bb08d92cf40938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637590248940170467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=i3lT17Js0hp7WwdrwV1trZmXRbgvHuiuY3TrDogkJEk%3D&amp;reserved=0

Juniper Business Use Only
_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Ckjohn%40futurewei.com%7C456f17a4ee40443db5bb08d92cf40938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637590248940170467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vYQcKmFG%2B6QDq7zpzMbDaDDhwHLNQW9hEWEkJGZyYbs%3D&amp;reserved=0

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 14 Jun 2021 17:15:10 +0000

John,

Indeed, the point was on the downlink, whether there is an IP adjacency in between the gNB and the UE. Many thanks for your answer. 
If it is not an IP adjacency, what is the type of the adjacency between the gNB and the UE?

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,

An easy to read reference is RFC 6459 (refers to 4G, but the concepts in this case are similar) MME (instead-of SMF) provisions eNB (i-o gNB) to switch radio bearer to GTP-U bearer, and IP adjacency is between UE - PGW (i-o UPF).
Or 3GPP TS 23.501, 5.8 (and other sections) provide more details.

BR,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

Juniper Business Use Only
_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Ckjohn%40futurewei.com%7C456f17a4ee40443db5bb08d92cf40938%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637590248940170467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vYQcKmFG%2B6QDq7zpzMbDaDDhwHLNQW9hEWEkJGZyYbs%3D&amp;reserved=0
_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: Kaippallimalil John <[email-masked]>
Date: Mon, 14 Jun 2021 18:56:36 +0000

Hi Pablo,
There is no IP adjacency between UE - gNB. 

It is a data link protocol and the user plane stack for adjacency is as in figure below (see TS 38.300. 6.6 L2 Data Flow).
IP flow is packaged in SDAP SDU, then in PDCP layer with RoHC, security & RLC with seg/ARQ. This RLC SDU is carried in a MAC transport block /multiplexed with other RLC SDUs.
Addressing, mapping and (de)multiplexing are handled by these layers and related control plane.

       UE                                          gNB
   [SDAP] <----------------------> [SDAP]
   [PDCP] <----------------------> [PDCP]
    [RLC]   <---------------------->   [RLC]
    [PHY]  <---------------------->   [PHY]

BR,
John 

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Monday, June 14, 2021 12:15 PM
To: Kaippallimalil John <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

John,

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,

BR,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Zzh> For the EVPN example, EVPN is emulating an Ethernet network - no different from Host1 and Host2 being connected via two Ethernet switches.
Zzh> The UE case is similar, though it is not Ethernet below the IP, but a lower layer consisting of one segment being PDCP (3G case at least) and the other segment being GTP-U. I could only find a 3G picture here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Ffigure%2F3GPP-protocol-stack-see-9_fig1_224357167&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C7799f627bf594cbacd4008d92f580259%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592877337757478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xbvxyfaD9%2Bm0B8kBonrSgWYsXRQrWJs8QKU89M6qPj8%3D&amp;reserved=0.
Zzh> Jeffrey

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm__%3B!!NEt6yMaO-gk!UbiidCykEZnbLyjo8UMPaSlhktUmVxQv7QR3n6XJAj5q053iHL7Vj9-HloD_jsGX%24&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C7799f627bf594cbacd4008d92f580259%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592877337757478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=UgsaTuULwPD0iRiISZs0QiX88j99hl5cbzOvq1CAxHU%3D&amp;reserved=0

Juniper Business Use Only
_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C7799f627bf594cbacd4008d92f580259%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592877337757478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9M7IUgkghZdGtWnIxS2gb4Je5SnoIlYtBCV2UnCByyw%3D&amp;reserved=0
_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C7799f627bf594cbacd4008d92f580259%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592877337757478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9M7IUgkghZdGtWnIxS2gb4Je5SnoIlYtBCV2UnCByyw%3D&amp;reserved=0

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 14 Jun 2021 19:25:27 +0000

Hi John,

Many thanks for detailed your answer.
Do you think it would be fair to use "L2 Adjacency" to refer to it in the draft?

Thanks,
Pablo.

-----Original Message-----
From: Kaippallimalil John <[email-masked]> 
Sent: lunes, 14 de junio de 2021 20:57
To: Pablo Camarillo (pcamaril) <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

       UE                                          gNB

BR,
John 

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Monday, June 14, 2021 12:15 PM
To: Kaippallimalil John <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

John,

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,

BR,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

---

From: Kaippallimalil John <[email-masked]>
Date: Mon, 14 Jun 2021 19:29:52 +0000

L2 adjacency would be ok.
BR,
John

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Monday, June 14, 2021 2:25 PM
To: Kaippallimalil John <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi John,

Thanks,
Pablo.

-----Original Message-----
From: Kaippallimalil John <[email-masked]> 
Sent: lunes, 14 de junio de 2021 20:57
To: Pablo Camarillo (pcamaril) <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

       UE                                          gNB

BR,
John 

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Monday, June 14, 2021 12:15 PM
To: Kaippallimalil John <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

John,

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,

BR,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Zzh> For the EVPN example, EVPN is emulating an Ethernet network - no different from Host1 and Host2 being connected via two Ethernet switches.
Zzh> The UE case is similar, though it is not Ethernet below the IP, but a lower layer consisting of one segment being PDCP (3G case at least) and the other segment being GTP-U. I could only find a 3G picture here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Ffigure%2F3GPP-protocol-stack-see-9_fig1_224357167&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Ce49b237ceede443f7c0408d92f6a2d34%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592955355021142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=hniWKZOX2j7cBTy2GAe0Iz2XIoA%2BzmKj0aW8u6iIwis%3D&amp;reserved=0.
Zzh> Jeffrey

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey

_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm__%3B!!NEt6yMaO-gk!UbiidCykEZnbLyjo8UMPaSlhktUmVxQv7QR3n6XJAj5q053iHL7Vj9-HloD_jsGX%24&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Ce49b237ceede443f7c0408d92f6a2d34%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592955355021142%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SFFuux5asd1dsRdHRjyVcqfwwGtFZMfRxZIJf%2B3SYFA%3D&amp;reserved=0

Juniper Business Use Only
_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Ce49b237ceede443f7c0408d92f6a2d34%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592955355031097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=uzxLYduPhKkEVqWbbZSRS59A1TLOwODBxRQVLwJVCLA%3D&amp;reserved=0
_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Ce49b237ceede443f7c0408d92f6a2d34%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637592955355031097%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=uzxLYduPhKkEVqWbbZSRS59A1TLOwODBxRQVLwJVCLA%3D&amp;reserved=0

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 14 Jun 2021 19:47:52 +0000

Thanks for confirming. I'll use that moving forward in the I-D.

Cheers,
Pablo.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Monday, June 14, 2021 2:25 PM
To: Kaippallimalil John <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi John,

Thanks,
Pablo.

-----Original Message-----
From: Kaippallimalil John <[email-masked]> 
Sent: lunes, 14 de junio de 2021 20:57
To: Pablo Camarillo (pcamaril) <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

       UE                                          gNB

BR,
John 

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: Monday, June 14, 2021 12:15 PM
To: Kaippallimalil John <[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

John,

Thanks,
Pablo.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Kaippallimalil John
Sent: viernes, 11 de junio de 2021 18:43
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo, Jeffrey,

BR,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, June 11, 2021 11:15 AM
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>; Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Please see zzh> below.

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Friday, June 11, 2021 10:16 AM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Jeffrey,

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: viernes, 4 de junio de 2021 22:06
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

[PC] Many thanks.

Jeffrey

-----Original Message-----
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Friday, June 4, 2021 12:52 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Jeffrey,

Cheers,
Pablo.

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Sent: martes, 1 de junio de 2021 16:04
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Subject: RE: [DMM] [spring] note: WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Hi Pablo,

Let me pull this up:

-----------

Jeffrey