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

"Kentaro Ebisawa" <ebiken.g@gmail.com> Sun, 10 March 2019 08:28 UTC

Return-Path: <ebiken.g@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAA8126DFA for <dmm@ietfa.amsl.com>; Sun, 10 Mar 2019 00:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRt96Tm8afGU for <dmm@ietfa.amsl.com>; Sun, 10 Mar 2019 00:28:14 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BEA124B91 for <dmm@ietf.org>; Sun, 10 Mar 2019 00:28:14 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id l11so1596967pgq.10 for <dmm@ietf.org>; Sun, 10 Mar 2019 00:28:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:reply-to:user-agent:mime-version :content-transfer-encoding; bh=qHVhjFVm9njsD+hYx/VBolYjOBC/JOpINzFFOMJP8KY=; b=G8UlELPD9UNlJSrW1VwBMqErkJ//HrtbnNaFOYhT6YD9GTVOalHLc9H0rQWfXBQFYP dEPNk1M5vqNSgL/GLNEFV2FrDPNFbp7rLAy+Ha+W6rquldpsUKdc98VuVFKjC4kdMRJg gL8APtw61vXA2hLsbd1UVR1fXzvVAzdn5UKTYoHSDDP45cJhiyMimKH2EB86pMV386hL 18dkH3k1NFyAfLhHiuH2CwY7/0Y7SIjuZY4oDNSzBzeGGZQ611i9jCIpoIt6Ekw61qvM TKCOs81L6rrnFZgmuEcPRmDua7ohpapKHehVzwFgGQLWfEgPhtcgykFx42puNG4FYyXe jwLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:reply-to :user-agent:mime-version:content-transfer-encoding; bh=qHVhjFVm9njsD+hYx/VBolYjOBC/JOpINzFFOMJP8KY=; b=WYyIAJxrpdjiDwiD7UMbr73UzVgKn9FFhqugydD7ZWFOftc+i/LZENZ5K2AbHidnIz lkMFXVtDEaaaclin5Q2Hkv1T7qSlf3DMyHXtXap9JP6R6e59QQ+cDjueCIzOHMXgIBW+ fONteEOB5h4ff8cB9oCwEC/xtXRFEK6AAlDeMpWT72mO4vcHpDafS3W/osj1aZ0RJs0N 1b71S4nTbmgdygXggashEuUQkEVzmEqZuZp6BizEeCOKJlFT5DPStNjjLSo3TlwDav39 XUpeDu59x970TNGEdYL3Wzodx89ySZFUWa6vtTykh6PJkZod9fyh5iYKlF+fqbGLnDr/ bVCg==
X-Gm-Message-State: APjAAAVlOfWrK6tSoXiyjUlj9f5PjsR5CWaZ3yn8FGaGKuqtJHLq88TV 0E7Yc81Pb/TlY8ji7z3cr6MacEyG
X-Google-Smtp-Source: APXvYqxOMXoxWubUcbIS4Ug0RtqeZsYhXEQz/ZpicmyVgdINbKTBy8ssh0OANdXTgNzWjcZTv0qwVA==
X-Received: by 2002:a17:902:9a46:: with SMTP id x6mr4823429plv.90.1552206493710; Sun, 10 Mar 2019 00:28:13 -0800 (PST)
Received: from [192.168.10.8] (122x210x140x66.ap122.ftth.ucom.ne.jp. [122.210.140.66]) by smtp.gmail.com with ESMTPSA id b138sm8873793pfb.48.2019.03.10.00.28.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Mar 2019 00:28:12 -0800 (PST)
From: "Kentaro Ebisawa" <ebiken.g@gmail.com>
To: dmm@ietf.org
Date: Sun, 10 Mar 2019 08:28:11 +0000
Message-Id: <emcdd38c49-deec-4b8d-81a1-9dfb2153edf5@ebiken-desktop>
Reply-To: "Kentaro Ebisawa" <ebiken.g@gmail.com>
User-Agent: eM_Client/7.1.30646.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/Vd8w909RtymCHyde40xzuweU7BI>
Subject: [DMM] review comment to SRv6-mobile-uplane draft (Kentaro Ebisawa)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 08:28:17 -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 <ebiken.g@gmail.com>
Work : Kentaro Ebisawa <ebisawa@jp.toyota-itc.com>
Principal Researcher | Toyota InfoTechnology Center Co., Ltd.