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

> On 7 Jun 2018, at 16:56, Tom Herbert <tom@herbertland.com> wrote:
> 
> 
> 
> 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?

Good point.

> 
> For instance, in other UDP encpasulations (GUE, Geneve, GRE/UDP, etc.)

LISP can do the same (at least in the OpenLISP implementation …)

Ciao
L.

> 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://www.ietf.org/mailman/listinfo/5gangip>
> 
> 