Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

"Jeffrey \(Zhaohui\) Zhang" <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <BL0PR05MB565295B44940D46F4EFF7C1FD43E9@BL0PR05MB5652.namprd05.prod.outlook.com>
Hi Pablo,

5.2.2.  Packet flow - Downlink

   The downlink packet flow is as follows:

   UPF2_in : (Z,A)                             ->UPF2 maps the flow w/
                                                 SID list <C1,S1, gNB>
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)   ->H.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A)                 ->End with PSP
   gNB_out : (Z,A)                             ->End.DX4/End.DX6/End.DX2

   ...
   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).

Because of the END.DX2/4/6 behavior on gNB, the SID list and S1_out can't just simply use gNB. It must be gNB:TEID.

In 5.3, for uplink traffic, the GW has End.M.GTP6.D for the UPF address B and the gNB does not need to know the existence of GW. For downlink traffic, the UPF knows there is a GW and put the GW::TEID in the SRH. Why not make GW invisible to UPF as well and just use gNB::TEID, and then have gNB/96 as End.M.GTP6.E on the SRGW? You can still put GW in the SRH to steer traffic through the GW.

5.3.1.1.  Packet flow - Uplink

   The uplink packet flow is as follows:

   UE_out  : (A,Z)
   gNB_out : (gNB, B)(GTP: TEID T)(A,Z)       -> Interface N3 unmodified
                                                 (IPv6/GTP)
   SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
                                                 SID at the SRGW
   S1_out  : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
   C1_out  : (SRGW, U2::1)(A,Z)               -> End with PSP
   UPF2_out: (A,Z)                            -> End.DT4 or End.DT6

Shouldn't U2::1 be U2::TEID? Even for the enhanced mode, TEID is still signaled and used - just that multiple UEs will share the same TEID.
BTW, since you removed UPF1 in Figure 5, it's better to rename UPF2 to UPF1, and change U2 to U1.

For 5.3.1.3, why is downlink considered stateless while uplink has some state? Aren't the same - just one converts GTP-U to SRv6 while the other does the opposite?

5.3.2.1 has the following:

   When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
   Classifier rule for incoming traffic from the gNB, that steers the
   traffic into an SR policy by using the function H.M.GTP4.D.

The SRGW is not a 5G NF, so the "Uplink Classifier rule" does not have to be the following (draft-homma-dmm-5gs-id-loc-coexistence):

    Uplink Classifier (ULCL):
       An ULCL is an UPF functionality that aims at diverting Uplink traffic, based on filter rules provided by SMF, towards Data Network (DN).

So, instead of ULCL, the SRGW could have an IPv4 route for the UPF address which steers the matching traffic to an SR policy with function H.M.GTP4.D. If that is done, then the following is not true:

   For the uplink traffic, the state at the SRGW is dedicated on a per
   UE/session basis according to an Uplink Classifier.  There is state
   for steering the different sessions in the form of an SR Policy.
   However, SR policies are shared among several UE/sessions.

Because we don't need per UE/session steering - we can just steer based on UPF's address (just like in IPv6 case). It seems that the only reason ULCL is used here is just that we don't call an IPv4 address a SID - but that does not mean we can't use an IPv4 route to steer traffic into a policy (isn't it the same thing that we use an IPv6 route for an address that we call SID)?

5.3.3.  Extensions to the interworking mechanisms

   In this section we presented two mechanisms for interworking with
   gNBs and UPFs that do not support SRv6.  These mechanisms are used to
   support GTP over IPv4 and IPv6.

Only gNB, not UPF, right?

   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.

Are you referring to the following?

 gNB (GTP-U) -- SRGW1 ----- UPF1  -------  SRGW2 ----- (GTP-U) UPF2

What's the difference between SRGW1 and SRGw2? If there is, then the above paragraph is incorrect.
If there is no difference, why do we need drop-in mode (which has difference between SRGW-A and SRGW-B)?

Jeffrey

Juniper Business Use Only
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.