Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Too much traffic goes between a small set of destination IP’s using same ports. GRE and IPSec have the same problem. But TEID is unique per session for a given EPC element and thus great to hash on. We worked long and hard with goth Cisco and Juniper on this. Nothing came close this even hashes better than the Internet traffic by quite a bit.

We take fiber utilization quite serious and this was a huge.

It’s a configuration item in carrier grade switches/routers/firewalls but until we know how the mix  of GTP and non-GTP traffic will be handled and how 3GPP incorporates some of this stuff its really hard to guess at what configuration changes are needed. If we still have GTP traffic then the mix is a bit of a challenge. But I don’t see ANY mobility operator getting completely off GTP for a very long time.

Plus currently the business case for doing this would be blood red. The encapsulation and fragmentation argument are bogus because its much cheaper to simply switch to transport MTU2000. Since we were able to address this across the Americas and others will just jump on after our lead this is fixable in western hemisphere. All of our 5G cell sites are migrated to MTU2000 for NR and eNB. We are do this by tracking area so all the sites in a tracking area get done together. Apparently X2 handoffs not only can’t go between vendor and IP address families they can’t go between MTU sizes. So we need to do all the tracking areas in a market to avoid S1 handovers.

But I can see value in the mapping approach for services but who knows how this will play out over next few years in 3GPP where a lot of work needs to happen.

From: Tom Herbert <tom@herbertland.com>
Sent: Thursday, June 07, 2018 7:57 AM
To: Luigi Iannone <ggx@gigix.net>
Cc: FIGURELLE, TERRY F <tf2934@att.com>; 5GANGIP <5gangip@ietf.org>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

On Thu, Jun 7, 2018 at 3:13 AM, Luigi Iannone <ggx@gigix.net<mailto:ggx@gigix.net>> wrote:

On 6 Jun 2018, at 23:58, FIGURELLE, TERRY F <tf2934@att.com<mailto:tf2934@att.com>> wrote:

Switches may be impact and any layer2 element is impacted if they are optimized for GTP. Why? Because at layer2 hashing across multiple fibers is sensitive to traffic. With GTP they use  TEID to get good hashing over fibers in a bundle. This is typically just configuration and mostly we use switch/router instead of pure switch. We had same challenges with load balancers and firewalls but all now scale and hash for GTP.

Said another way, mobile operators have been supporting GTP for a very long time. Over that time it is likely some optimizations were leveraged to improve layer2 systems in the paths for  traffic.

How complex are those optimisations? Cannot be adapted to any other encapsulation solution (usually is just a hash….)

I think the question instead should be: why can't GTP adapt solutions from other IETF protocols?

For instance, in other UDP encpasulations (GUE, Geneve, GRE/UDP, etc.) the UDP source port is set as the hash value representing the encapsulated flow. This means flow specific ECMP and load balancing can be done by intermediate devices by parsing transport header. There is no need for intermediate devices to be doing expensive and possibly incorrect DPI into the UDP payload to find TEIDs or TLVs for the hash.

Better yet, with IPv6 just use the flow label to generate the necessary hash. This doesn't require any DPI at all, just the core IP header needs to be inspected. Also, this works for any IP protocol as well as extension headers and even fragmentation. We've even done the work on the host side to set the hash appropriately (supported by all major OSes now AFAIK).

They also likely have security solution for GTP traffic too.

Same question. There has been a lot of work on security at IP layer which could be generic to any protocols. Are these being leveraged?

Tom

Security is a broad term, can you be more specific?

Ciao

L;

So those gaps need to be closed.

From: 5gangip <5gangip-bounces@ietf.org<mailto:5gangip-bounces@ietf.org>> On Behalf Of Luigi Iannone
Sent: Tuesday, May 29, 2018 1:33 AM
To: Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>>
Cc: 5GANGIP <5gangip@ietf.org<mailto:5gangip@ietf.org>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Hi,

On 28 May 2018, at 19:16, Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>> wrote:

There is some text which is incorrect - on page 4:

----
   Furthermore, ILNP demands a change in the way local (e.g., within a
   LAN) communication is carried out, needing all of the devices to
   support ILNP.  This in turn may raise heavy deployability issues.
----

This is not true - "all devices" do *not* need to be updated, but only those end-systems that wish to use ILNPv6. Switches

Switches clearly do not need to be changed since they are L2.

and routers

You need to implement the ILCC in your first hop router.

Then you need new ICMP messages, and few other tricks here and there in existing stuff.
Other solutions are more clear because introduce new entities and protocol, so either you have it or you don’t.

Yet, may be the last sentence can be soften deleting  “heavy”.

Ciao

L.

do not need to be updated, as ILNPv6 is backwards compatible with IPv6. It is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.

Cheers,
--/Saleem

On 25 May 2018, at 15:50, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> wrote:

Hi all,

We have submitted the gaps draft. Those who have contributed text are listed as co-authors.
Please send your comments to the list.

Regards,
Dirk& Behcet

A new version of I-D, draft-xyzy-atick-gaps-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-xyzy-atick-gaps
Revision:       00
Title:          Gap and Solution Space Analysis for End to End Privacy Enabled Mapping System
Document date:  2018-05-25
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dxyzy-2Datick-2Dgaps-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=JHCjCG90b48mXx2Mli_4FNx3qy80mb6fi-Kr4Z2dAu8&e=>
Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker..ietf.org_doc_draft-2Dxyzy-2Datick-2Dgaps_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=t5QGiu_jAW_cH1P0JkFVW2ESNVahK7obQU0waTiM2wY&e=>
Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxyzy-2Datick-2Dgaps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=5znCd2jz7p4APVeDGBdJR8QIV90W9mTYFft0Ud_kLrg&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker..ietf.org_doc_html_draft-2Dxyzy-2Datick-2Dgaps&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=CLW3JOJZwQYB-apye4JxkAsH1Kl-Z5_IPqaj31fsX4I&e=>

Abstract:
   This document presents a gap and solution analysis for end-to-end
   privacy enabled mapping systems.  Each of the identifier locator
   separation system has its own approach to mapping identifiers to the
   locators.  We analyse all these approaches and identify the gaps in
   each of them and do a solution space analysis in an attempt to
   identify a mapping system that can be end to end privacy enabled.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=pnlPaw7b14RkC63Q6o1vR1d9DPP7T-GkJxgti99nE6E&e=>.

The IETF Secretariat

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=XBUCO8KnEDmfXcxVrQBRrbx98CQRqJmRkKwwYbOpVqg&e=>

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=XBUCO8KnEDmfXcxVrQBRrbx98CQRqJmRkKwwYbOpVqg&e=>

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=5ej4aI56yXzDPyAdqRIRabJ7H0bpwX2473rPLEG8B1I&s=U3RCFMElACrH4CboM8bTYxJtDQN1N90xr6ZtNZFwEb8&e=>