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 protected]>
Work : Kentaro Ebisawa <[email protected]>
Principal Researcher | Toyota InfoTechnology Center Co., Ltd.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
