Subject: [DMM] review comment to SRv6-mobile-uplane draft (Kentaro Ebisawa)

From: "Kentaro Ebisawa" <[email-masked]>
Date: Sun, 10 Mar 2019 08:28:11 +0000

Hi,

Sorry for taking long ... here's my review comments to 
SRv6-mobile-uplane draft promised at Bangkok meeting.

 > 5. User-plane behaviors

Could we add the drop in mode (GTP/SRv6/GTP translation) which Arashmid 
has presented in IETF103?
https://datatracker.ietf.org/meeting/103/materials/slides-103-dmm-a-smooth-migration-of-mobile-core-user-plane-from-gtp-to-srv6-00

I think this mode would be useful as a use case using SRv6/GTP 
translation with minimum modification of existing Control Plane and 
eNB/gNB.
If we could, I think having "Enhanced drop in mode" (or any name) with 
same topology but have SRGW insert SRH would be usefullas a way to 
introduce SRv6 features with minimum modification.

 > 6.6. T.M.Tmap

I think the name of the function should be changed in line with 
End.M.GTP6.D since this is specific to GTP/IPv4.
For example, T.M.GTP4.D, just like End.M.GTP4.E / End.M.GTP6.E pair.

We assume Message Type is GTPMSG_TPDU(255) and cannot translate GTP ping 
which use GTPMSG_ECHO(1), GTPMSG_ECHOREPLY(2). Should we add capability 
to translate GTP ECHO* to ICMP6* or at store GTP Message Type to some 
place?

Both UDP Source / Dest port number will be lost.
I think it's OK to lose Dest port number, but have we considered anyone 
using UDP Source address, say for entropy?

 > 6.5. End.M.GTP4.E
 > ...
 > 1. IF NH=SRH & SL > 0 THEN
 > 2. decrement SL
 > 3. update the IPv6 DA with SRH[SL]
 > 4. pop the SRH
 > 5. push UDP/GTP headers with tunnel ID from S
 > 6. push outer IPv4 header with SA, DA from S
 > 7. ELSE
 > 8. Drop the packet

Since this is the last segment wich decapsulates SRv6 and encaps with 
GTP/IPv4, I think there would be two types of (valid) packets 
End.M.GTP4.E sgment could recive.

1. IPv6 with no SRH (as a result of PSP etc)
2. IPv6 with SRH whose SL == 0 (last segment)

Unless I'm missing something, I think the pseudo code should be modified 
based on above assumptions.

1. IF (NH=SRH & SL = 0) or (NH=IPIP & no SRH) THEN
2. store DA in variable S
3. pop IP header and all its extension headers
5. push UDP/GTP headers with tunnel ID from S
6. push outer IPv4 header with SA, DA from S
7. ELSE
8. Drop the packet

 > 6.6. T.M.Tmap amd 6.5. End.M.GTP4.E

Could we consider having PREFIX length longer than 32 bits?
I know most (mobile) operators would no have issue using 32 bit PREFIX 
for GTP/SRv6 translation.
But there might be cases when we want to use PREFIX longer than 32 bits. 
For example, if network is operated by smaller organization like MVNO, 
Private LTE.

Have you ever considered it?
I have some idea if others think it's worth considering.

--
Mailing List : Kentaro Ebisawa <[email-masked]>
Work : Kentaro Ebisawa <[email-masked]>
Principal Researcher | Toyota InfoTechnology Center Co., Ltd.