Re: [spring] note: [DMM] 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?

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.

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.

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

Any reason why Figure 3 omitted UPF1?

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?

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?

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.

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

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.

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).
What is a L3-anchor vs. L2-anchor?

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?
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?
UPF2b appeared twice but I could not find it in the figure.

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?

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.

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

Thanks.
Jeffrey

-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Erik Kline
Sent: Wednesday, April 7, 2021 11:59 PM
To: SPRING WG <spring@ietf.org>
Cc: spring-ads@ietf.org; spring-chairs@ietf.org; dmm@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.com@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-RTNNFjsP2hvLNFyz-fGE_jQjZlyvBbW-zDgRDc4fJS$
>
>
>
>
>
> Please post any comments/concerns on this document.
>
>
>
>
>
> Thanks!
>
> Sri
>
>
>
>
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@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