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.
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=40cisco....@dmarc.ietf.org>
Sent: Tuesday, May 4, 2021 6:36 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; d...@ietf.org
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 <dmm-boun...@ietf.org> On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: miércoles, 21 de abril de 2021 6:49
To: Erik Kline <ek.i...@gmail.com>; SPRING WG <spring@ietf.org>; d...@ietf.org
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.
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".
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.
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.
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.
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.
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)?
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.
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.
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.
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?
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).
Zzh> Besides, it is strange that 5GS will tell gNB to use GTP while telling UPF
to use SRv6.
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.
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?
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.
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).
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"?
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?
Zzh> Thanks.
Zzh> Jeffrey
Thanks.
Jeffrey
-----Original Message-----
From: spring <spring-boun...@ietf.org> On Behalf Of Erik Kline
Sent: Wednesday, April 7, 2021 11:59 PM
To: SPRING WG <spring@ietf.org>
Cc: spring-...@ietf.org; spring-cha...@ietf.org; d...@ietf.org
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=40cisco....@dmarc.ietf.org> 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-ietf
> -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
> d...@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm_
> _;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-
> zDgY0wXO9D$
_______________________________________________
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-zDgQZXTemu$
Juniper Business Use Only
_______________________________________________
dmm mailing list
d...@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm__;!!NEt6yMaO-gk!VfY3TV_tyoDu-Jl2ZATcisDxW0ThG3_0UhTy33UgBAM_eiwNmnAps4fqtSRX3Ayz$
Juniper Business Use Only
Juniper Business Use Only
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
