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 protected]> On Behalf Of Jeffrey (Zhaohui) Zhang Sent: miércoles, 21 de abril de 2021 6:49 To: Erik Kline <[email protected]>; SPRING WG <[email protected]>; [email protected] 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. End.Map seems to be rather generic and not specific to DMM. Should it be extracted out to a spring document? [PC] The only use-case so far for this behavior is DMM. Maybe in the future other use-case pops up, in which case the fact that this behavior is defined in an RFC coming from DMM doesn't preclude them from using it. 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. 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. In 5.2: ... Note that both S1 and C1 are not required to have an N4 interface. Do you mean "neither S1 nor C1 is required to have an N4 interface"? [PC] Fixed. Thanks. Any reason why Figure 3 omitted UPF1? [PC] Two different examples. You do not need to have 2 UPFs always. 5.3, which is about enhanced mode, has the following: In the interworking scenarios as illustrated in Figure 4, the gNB does not support SRv6. It later says in 5.3.1: o When a packet from the UE leaves the gNB, it is SR-routed. Is that "SR-routed" conflicting with "gNB does not support SRv6"? Or does it really mean that gNB is still using GTP though it does support SRv6? [PC] The SR-routed is achieved using FlexAlgo. The gNB -since in this case is a legacy device- is not capable of adding an SRH to the packet; but the IPv6 Destination Address is a binding SID that is steered in the network according to FlexAlgo, as explained in the line after the one you quote. In 5.3: To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. The SRGW maps the GTP traffic into SRv6. It seems that it's more accurate to say "UPF1 acts as a SRGW": To achieve interworking, UPF1 acts as a SRGW and maps the GTP traffic into SRv6. Is it true that this only works if there is this intermediate UPF1? What if there is no I-UPF (UPF1) for some scenarios? Would UPF2 need to handle both GTP and SRv6? [PC] As described in the beginning of section 5.3, the interworking mechanism are based on the introduction of an intermediate SR Gateway that maps GTP to SRv6. The SRGW is not an anchor point. It could simply be a P4 programmable switch. 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. 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) I assume (SA, DA) are the addresses of UPF1 and gNB respectively? [PC] Correct, the IPv4 addresses of UPF1 and gNB. I've fixed it in the diagram. 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. 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. In the following: 5.3.3. Extensions to the interworking mechanisms In this section we presented three mechanisms for interworking with gNBs and UPFs that do not support SRv6. These mechanisms are used to support GTP over IPv4 and IPv6. Furthermore, although these mechanisms are designed for interworking with legacy RAN at the N3 interface, these methods could also be applied for interworking with a non-SRv6 capable UPF at the N9 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). What's the third mechanism? I only counted two (5.3.1 and 5.3.2). [PC] Corrected. Thanks. What is a L3-anchor vs. L2-anchor? [PC] Different types of 3GPP UPF functionalities. Equivalent to SGW/PGW in 4G. For 5.4 and Figure 7: When a packet destined to Z to the gNB, which is unmodified, it performs encapsulation into a new IP, UDP and GTP headers. The IPv6 DA, U::1, and the GTP TEID are the ones received at the N2 interface. What does "which is unmodified" mean? [PC] Clarified. U1b::TEID only appeared once and I could not figure out what it is - should it be SGB::TEID? U2b:: appeared twice but I could not figure out what it is. Could it be U::1? [PC] Indeed. Corrected. UPF2b appeared twice but I could not find it in the figure. [PC] Corrected. Thanks. 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. Should the following be added to 6.5. End.M.GTP6.E, like in 6.4? Any SID instance of this behavior is associated with an SR Policy B and an IPv6 Source Address A. [PC] I guess you are referring to the End.M.GTP6.D, in which case yes, it needs to be added. Thanks. 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 Thanks. Jeffrey -----Original Message----- From: spring <[email protected]> On Behalf Of Erik Kline Sent: Wednesday, April 7, 2021 11:59 PM To: SPRING WG <[email protected]> Cc: [email protected]; [email protected]; [email protected] 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) <[email protected]> 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 > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmm_ > _;!!NEt6yMaO-gk!RyYI05Z41Depmow2gAcvg-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW- > zDgY0wXO9D$ _______________________________________________ spring mailing list [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
