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

From: Saleem Bhatti <[email-masked]>
Date: Fri, 1 Jun 2018 07:24:02 +0000

Behcet;

On 30 May 2018, at 22:48, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Again trimming the cc list.

On Wed, May 30, 2018 at 1:52 PM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Behcet;

On 30 May 2018, at 19:36, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Tom;

> On 30 May 2018, at 16:44, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>
> Behcet,
>
> The statement "For ILNP the basic deployment requires end-systems to
> be updated." is unscoped. As written, this would imply that all hosts
> on the Internet need to be updated to support ILNP. That is simply a
> non-starter.

Good catch - thanks.

> If the idea is that ILNP can be deployed by networks then
> hosts within that network can be updated.

Only those end-systems that need to use ILNP need to be updated. ILNP nodes can work in networks with non-ILNP nodes - see Section 10.4 of RFC6741.

> But, then the question
> becomes how ILNP hosts are going to be able to talk non ILNP hosts
> (say servers on the Internet). For that the an ILNP gateway or proxy
> also must be deployed in the network.

A gateway or proxy is not required.

ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6 when required - the process is described in Section 10.6 of RFC6741.

So then it is no longer ILNP.

To talk to an IPv6 host that does not talk ILNPv6, the easiest method is to talk IPv6.

Maybe a better reply is this feature could be added to ILNP.

Yes, it is already a feature - the behaviour is defined in RFC6741 - please see above, my response to Tom's message.

Cheers,
--/Saleem

Cheers,
--/Saleem

Regards,
Behcet
Cheers,
--/Saleem

>
> Tom
>
> On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
>> Luigi, Saleem,
>>
>> What is the agreement now as to the revision of the draft?
>>
>> I had already added some text regarding UE being alone on the link, i.e.
>> point-to-point link in wireless networks, that should make both sides happy?
>>
>> Regards,
>> Behcet
>>
>> On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hi Saleem,
>>>
>>> On 29 May 2018, at 12:03, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hello Luigi;
>>>
>>> Thanks for your comments - my responses are inline, below.
>>>
>>> On 29 May 2018, at 09:32, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> 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.
>>>
>>>
>>> Agreed.
>>>
>>> However, the text clearly says "all of the devices", which is incorrect.
>>>
>>>
>>> Agreed.
>>>
>>>
>>>
>>> and routers
>>>
>>>
>>> You need to implement the ILCC in your first hop router.
>>>
>>>
>>> No, that is not required. I have a testbed at St Andrews and we run Linux
>>> routers that are not modified, and are not ILNP-aware. For example, please
>>> see the testbed experiment described in this paper:
>>>
>>>  IP without IP addresses
>>>  https://dl.acm.org/citation.cfm?doid=3012695.3012701
>>>
>>>
>>> Thanks for the pointer. :-)
>>>
>>>
>>> Then you need new ICMP messages, and few other tricks here and there in
>>> existing stuff.
>>>
>>>
>>> The new ICMP messages, e.g. Locator Updates for ILNPv6, RFC6743, are
>>> end-to-end - only the end hosts needs to be updated to generate these
>>> messages.
>>>
>>> If any on-path routers wish to examine such messages, then yes, they would
>>> need to be updated, but that is not required for ILNPv6 to work.
>>>
>>>
>>> Ack.
>>>
>>>
>>> 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”.
>>>
>>>
>>> All new solutions will incur some sort of deployment overhead, so I am not
>>> sure why such a comment should apply specifically and only to ILNP.
>>>
>>> For ILNP the basic deployment requires end-systems to be updated. Such
>>> updates would be deployed through over-the-air updates, as is common today
>>> with many operating systems. DNS entries for ILNP nodes would also be
>>> needed, and the new DNS RRs for ILNP (RFC6742) are supported commercially
>>> (e.g. by BIND, NSD, and KnotDNS, and possibly others)..
>>>
>>> For other solutions, other deployment issues exist, e.g. for ILA and LISP,
>>> new network entities/functions need to be deployed and managed for routing,
>>> and so, I guess, the existing network will need to be reconfigured to
>>> integrate the new functionality. I am guessing some operators may find that
>>> a "heavy" deployment burden, but it is best that those operators comment on
>>> whether or not they see that is a problem, as I have no experience with
>>> running large networks.
>>>
>>>
>>> Updating end-systems is IMHO a real nightmare. You have no control on who
>>> will update and when. Network history is full of such examples.
>>> Yes, ILA and LISP has to be deployed by operators, but they can have full
>>> control of what will happen in their own network (which they usually like).
>>> YMMV.
>>>
>>> In general, I may agree that deployment considerations for all of the
>>> considered solutions can be improved and corrected.
>>>
>>> Thanks
>>>
>>> L.
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>> --/Saleem
>>>
>>>
>>> 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 <[email-masked]<mailto:[email-masked]>> 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
>>> Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/
>>> Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps
>>>
>>>
>>> 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<http://tools.ietf.org/>.
>>>
>>> The IETF Secretariat
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>
>>
>> _______________________________________________
>> 5gangip mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/5gangip
>>
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 1 Jun 2018 09:11:34 -0500

Saleem,

On Fri, Jun 1, 2018 at 2:24 AM, Saleem Bhatti <[email-masked]>
wrote:

> Behcet;
>
> On 30 May 2018, at 22:48, Behcet Sarikaya <[email-masked]> wrote:
>
> On Wed, May 30, 2018 at 1:52 PM, Saleem Bhatti <[email-masked]>
> wrote:
>
>> Behcet;
>>
>> On 30 May 2018, at 19:36, Behcet Sarikaya <[email-masked]> wrote:
>>
>>
>>
>> On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[email-masked]>
>> wrote:
>>
>>> Tom;
>>>
>>> > On 30 May 2018, at 16:44, Tom Herbert <[email-masked]> wrote:
>>> >
>>> > Behcet,
>>> >
>>> Only those end-systems that need to use ILNP need to be updated. ILNP
>>> nodes can work in networks with non-ILNP nodes - see Section 10.4 of
>>> RFC6741.
>>>
>>>
>>> > But, then the question
>>> ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6 when
>>> required - the process is described in Section 10.6 of RFC6741.
>>>
>>>
> Yes, it is already a feature - the behaviour is defined in RFC6741 -
> please see above, my response to Tom's message.
>
>

IPv6 is no go, then there is no need for
ILNP, right?

Behcet

> Cheers,
> --/Saleem
>
>
>
>
>
>> Cheers,
>> --/Saleem
>>
>>
>>
>> Regards,
>> Behcet
>>
>>> Cheers,
>>> --/Saleem
>>>
>>>
>>> >
>>> > Tom
>>> >
>>> > On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <
>>> [email-masked]> wrote:
>>> >> Luigi, Saleem,
>>> >>
>>> >> On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[email-masked]> wrote:
>>> >>>
>>> >>> Hi Saleem,
>>> >>>
>>> >>> On 29 May 2018, at 12:03, Saleem Bhatti <[email-masked]>
>>> wrote:
>>> >>>
>>> >>> Hello Luigi;
>>> >>>
>>> >>> On 29 May 2018, at 09:32, Luigi Iannone <[email-masked]> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>>
>>> >>> On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked]>
>>> wrote:
>>> >>>
>>> >>> On 25 May 2018, at 15:50, Behcet Sarikaya <[email-masked]>
>>> wrote:
>>> >>>
>>> >>> Hi all,
>>> >>>
>>> >>> until the htmlized version and diff are available at tools.ietf.org.
>>> >>>
>>> >>> The IETF Secretariat
>>> >>>
>>> >>>
>>> >>> [email-masked]
>>> >>> [email-masked]
>>> >>> [email-masked]
>>> >> [email-masked]
>>> > [email-masked]

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 1 Jun 2018 14:50:33 +0000

Behcet;

On 01 Jun 2018, at 15:11, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Saleem,

On Fri, Jun 1, 2018 at 2:24 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Behcet;

Good catch - thanks.

Sorry ... I do not understand.

Cheers,
--/Saleem

Behcet
Cheers,
--/Saleem

Cheers,
--/Saleem

Regards,
Behcet
Cheers,
--/Saleem

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 1 Jun 2018 10:40:06 -0500

On Fri, Jun 1, 2018 at 9:50 AM, Saleem Bhatti <[email-masked]>
wrote:

> Behcet;
>
> On 01 Jun 2018, at 15:11, Behcet Sarikaya <[email-masked]> wrote:
>
> Saleem,
>
>>> On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[email-masked]
>>> > wrote:
>>>
>>>> Tom;
>>>>
>>>> ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6
>>>> when required - the process is described in Section 10.6 of RFC6741.
>>>>
>>>>
I get IPv6 on my laptop, I did not do anything for that no installation no
configuration nothing needed.

So  if that is what you are happy with that is fine, let's stop arguing.

Behcet

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Wed, 6 Jun 2018 21:58:14 +0000

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. They also likely have security solution for GTP traffic too. So those gaps need to be closed.

From: 5gangip <[email-masked]> On Behalf Of Luigi Iannone
Sent: Tuesday, May 29, 2018 1:33 AM
To: Saleem Bhatti <[email-masked]>
Cc: 5GANGIP <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Hi,

----

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

and routers

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.

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

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

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:

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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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=>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 7 Jun 2018 12:03:31 +0200

> On 30 May 2018, at 20:36, Behcet Sarikaya <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[email-masked] <mailto:[email-masked]>> wrote:
> Tom;
> 
> > On 30 May 2018, at 16:44, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Behcet,
> > 

+1

Either you have both side speaking ILNPv6 or you are “stuck” with IPv6 pure and simple.

I was wondering:  assuming that you do not use DNS to contact a node, how do you know it supports ILNPv6?

Ciao

L.

> 
> Regards,
> Behcet 
> Cheers,
> --/Saleem
> 
> 
> > 
> > Tom
> > 
> > On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <[email-masked] <mailto:[email-masked]>> wrote:
> >> Luigi, Saleem,
> >> 
> >> On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> Hi Saleem,
> >>> 
> >>> On 29 May 2018, at 12:03, Saleem Bhatti <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> Hello Luigi;
> >>> 
> >>> On 29 May 2018, at 09:32, Luigi Iannone <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> 
> >>> On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>>  https://dl.acm.org/citation.cfm?doid=3012695.3012701 <https://dl.acm.org/citation.cfm?doid=3012695.3012701>
> >>> 
> >>> 
> >>> On 25 May 2018, at 15:50, Behcet Sarikaya <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> Hi all,
> >>> 
> >>> https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt <https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt>
> >>> Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/ <https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/>
> >>> Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00 <https://tools.ietf.org/html/draft-xyzy-atick-gaps-00>
> >>> Htmlized:
> >>> https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps <https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps>
> >>> 
> >>> 
> >>> Abstract:
> >>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >>> 
> >>> The IETF Secretariat
> >>> 
> >>> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >>> 
> >>> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >>> 
> >>> 
> >>> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >>> 
> >> 
> >> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >> 
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> 
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 7 Jun 2018 12:08:13 +0200

> On 30 May 2018, at 20:48, Saleem Bhatti <[email-masked]> wrote:
> 
> Behcet;
> 
>> On 30 May 2018, at 19:35, Behcet Sarikaya <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>> On Wed, May 30, 2018 at 1:28 PM, David Allan I <[email-masked] <mailto:[email-masked]>> wrote:
>> The only network upgrade for ILNP is DNS support for RFC 6742, which is believe is already deployed.
>> 
>> 
>> I am not sure about deployed but maybe defined is better.
> 
> If you are running the most recent version of BIND, KnotDNS, or NSD, then they support RFC6742 out-of-the-box, as far as I know.

There is a difference between “supporting” vs “deployment”, the first does not necessarily imply the second.

How does it work when you have a WiFi where you do not have any clue which device is connected? How do you understand that that particular device that just connect supports ILNPv6? If you can, do you need to create a dynamic DNS entry with the ILNP record? How can I tell other that they need to check that particular dynamic entry to contact me?

Thanks 

Ciao

L.

> 
> Cheers,
> --/Saleem
> 
> 
>> However, DNS is not privacy enabled which is our main issue here.
>> 
>> Regards,
>> Behcet 
>> Cheers
>> Dave
>> 
>> -----Original Message-----
>> From: 5gangip <[email-masked] <mailto:[email-masked]>> On Behalf Of Saleem Bhatti
>> Sent: Wednesday, May 30, 2018 9:19 AM
>> To: Tom Herbert <[email-masked] <mailto:[email-masked]>>
>> Cc: Luigi Iannone <[email-masked] <mailto:[email-masked]>>; 5GANGIP <[email-masked] <mailto:[email-masked]>>; Behcet Sarikaya <[email-masked] <mailto:[email-masked]>>
>> > If the idea is that ILNP can be deployed by networks then hosts within 
>> > that network can be updated.
>> 
>> >>> This is not true - "all devices" do *not* need to be updated, but 
>> >>> only those end-systems that wish to use ILNPv6. Switches
>> >>> 
>> >>> 
>> >>> No, that is not required. I have a testbed at St Andrews and we run 
>> >>> Linux routers that are not modified, and are not ILNP-aware. For 
>> >>> example, please see the testbed experiment described in this paper:
>> >>> 
>> >>>  IP without IP addresses
>> >>> end-to-end - only the end hosts needs to be updated to generate 
>> >>> these messages.
>> >>> 
>> >>> If any on-path routers wish to examine such messages, then yes, they 
>> >>> would need to be updated, but that is not required for ILNPv6 to work.
>> >>> 
>> >>> 
>> >>> Ack.
>> >>> 
>> >>> 
>> >>> All new solutions will incur some sort of deployment overhead, so I 
>> >>> am not sure why such a comment should apply specifically and only to ILNP.
>> >>> 
>> >>> For ILNP the basic deployment requires end-systems to be updated. 
>> >>> Such updates would be deployed through over-the-air updates, as is 
>> >>> common today with many operating systems. DNS entries for ILNP nodes 
>> >>> would also be needed, and the new DNS RRs for ILNP (RFC6742) are 
>> >>> supported commercially (e.g. by BIND, NSD, and KnotDNS, and possibly others)..
>> >>> 
>> >>> For other solutions, other deployment issues exist, e.g. for ILA and 
>> >>> LISP, new network entities/functions need to be deployed and managed 
>> >>> for routing, and so, I guess, the existing network will need to be 
>> >>> reconfigured to integrate the new functionality. I am guessing some 
>> >>> operators may find that a "heavy" deployment burden, but it is best 
>> >>> that those operators comment on whether or not they see that is a 
>> >>> problem, as I have no experience with running large networks.
>> >>> 
>> >>> 
>> >>> Updating end-systems is IMHO a real nightmare. You have no control 
>> >>> on who will update and when. Network history is full of such examples.
>> >>> Yes, ILA and LISP has to be deployed by operators, but they can have 
>> >>> full control of what will happen in their own network (which they usually like).
>> >>> YMMV.
>> >>> 
>> >>> In general, I may agree that deployment considerations for all of 
>> >>> the considered solutions can be improved and corrected.
>> >>> 
>> >>> Thanks
>> >>> 
>> >>> L.
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>> >>> Cheers,
>> >>> --/Saleem
>> >>> 
>> >>> 
>> >>> 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
>> >>> 
>> >>> 
>> >>> 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.
>> >>> 
>> >>> submission until the htmlized version and diff are available at 
>> >>> tools.ietf.org <http://tools.ietf.org/>.
>> >>> 
>> >>> The IETF Secretariat
>> >>> 
>> >>>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 7 Jun 2018 12:13:40 +0200

> On 6 Jun 2018, at 23:58, FIGURELLE, TERRY F <[email-masked]> wrote:
> 
> 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….)

> They also likely have security solution for GTP traffic too.

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

Ciao

L;

> So those gaps need to be closed.
>  
> From: 5gangip <[email-masked] <mailto:[email-masked]>> On Behalf Of Luigi Iannone
> To: Saleem Bhatti <[email-masked] <mailto:[email-masked]>>
> Cc: 5GANGIP <[email-masked] <mailto:[email-masked]>>
> 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:
> 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
> 
>  
> 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=>
>  
> 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=>

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 7 Jun 2018 11:10:02 +0000

Luigi;

On 07 Jun 2018, at 11:03, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

On 30 May 2018, at 20:36, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Good catch - thanks.

+1

Correct.

ILNP is a "host-based" (end-system) solution and not a "network-based" solution. If the end-system is not updated to support ILNP, then ILNP cannot be used.

An IPv6 packet containing a Nonce Header (RFC6744) is sent. If the recipient does not respond with a Nonce Header, then it is assumed that ILNPv6 is not supported. The process is described in Section 10.6 of RFC6741.

Cheers,
--/Saleem

Ciao

L.

Regards,
Behcet
Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 7 Jun 2018 11:29:52 +0000

Luigi;

On 07 Jun 2018, at 11:08, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

On 30 May 2018, at 20:48, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

Behcet;

On 30 May 2018, at 19:35, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 30, 2018 at 1:28 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
The only network upgrade for ILNP is DNS support for RFC 6742, which is believe is already deployed.

The RFC6742 DNS RRs for ILNP are supported/deployed in the same sense as IPv6 AAAA RRs are supported and deployed - they are implemented but you only configure them for use when you need them.

How does it work when you have a WiFi where you do not have any clue which device is connected? How do you understand that that particular device that just connect supports ILNPv6?

If by "connected" and "connect" you mean a layer 2 association with a WiFi basestation, then you cannot tell if it supports ILNPv6 just from the layer 2 association, just like you cannot tell if the device supports IPv6 (or even if it supports IPv4).

If you can, do you need to create a dynamic DNS entry with the ILNP record? How can I tell other that they need to check that particular dynamic entry to contact me?

An ILNPv6 mobile node that uses DNS will have a L64 RR. When the mobile node moves, it learns its new Locator value (which is the IPv6 routing prefix learned from an IPv6 Router Advertisement), then it updates its Locator value held in the L64 record. The "other" correspondent node would use DNS as normal, and see that new Locator value in the L64 record when it looks up the FQDN for the mobile node to initiate a new communication connection or session.

However, if the mobile node and correspondent node already have a communication session in progress, e.g. a TCP connection, or UDP session, then the mobile node signals the correspondent node with the new Locator value using a Locator Update message (RFC6743).

Cheers,
--/Saleem

Thanks

Ciao

L.

Cheers,
--/Saleem

Regards,
Behcet
Cheers
Dave

-----Original Message-----
From: 5gangip <[email-masked]<mailto:[email-masked]>> On Behalf Of Saleem Bhatti
Sent: Wednesday, May 30, 2018 9:19 AM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: Luigi Iannone <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>; Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Tom;

Good catch - thanks.

Cheers,
--/Saleem

>>> tools.ietf.org<http://tools.ietf.org/>.
>>>
>>> The IETF Secretariat
>>>
>>>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Jun 2018 06:27:39 -0700

> ILNP is a "host-based" (end-system) solution and not a "network-based" solution. If the end-system is not updated to support ILNP, then ILNP cannot be used.

We will have the serialization problem establishing transport connections then. We had this with IPv4 and IPv6. 

To be specific, DNS returns both A and AAAA records. The local system sends a TCP SYN and it times out because there is not a complete IPv6 path to the destination. Then IPv4 is tried and used. Connection open latency of the time-out value.

The same problem happens here because the local system is doing ILNP and the destination is not, it takes a response to find out. Connection open latency 1 RTT.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Thu, 7 Jun 2018 07:56:57 -0700

On Thu, Jun 7, 2018 at 3:13 AM, Luigi Iannone <[email-masked]> 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).

>
>
> 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

> *From:* 5gangip <[email-masked]> *On Behalf Of *Luigi Iannone
> *Sent:* Tuesday, May 29, 2018 1:33 AM
> *To:* Saleem Bhatti <[email-masked]>
> *Cc:* 5GANGIP <[email-masked]>
> *Subject:* Re: [5gangip] New Version Notification for
> draft-xyzy-atick-gaps-00.txt
>
> Hi,
>
>
>
> On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked]> wrote:
>
> On 25 May 2018, at 15:50, Behcet Sarikaya <[email-masked]> wrote:
>
> Hi all,
>
> 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=>
> <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=>
> <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:
> 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
>
> <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=>
>
>
> <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=>
>
>
>

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 7 Jun 2018 15:24:40 +0000

Dino;

> On 07 Jun 2018, at 14:27, Dino Farinacci <[email-masked]> wrote:
> 

Agreed - an additional ~1 RTT connection latency when ILNPv6 is not supported.

Cheers,
--/Saleem

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 7 Jun 2018 19:39:42 +0000

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 <[email-masked]>
Sent: Thursday, June 07, 2018 7:57 AM
To: Luigi Iannone <[email-masked]>
Cc: FIGURELLE, TERRY F <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

On Thu, Jun 7, 2018 at 3:13 AM, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

On 6 Jun 2018, at 23:58, FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>> wrote:

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).

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

Ciao

L;

From: 5gangip <[email-masked]<mailto:[email-masked]>> On Behalf Of Luigi Iannone
Sent: Tuesday, May 29, 2018 1:33 AM
To: Saleem Bhatti <[email-masked]<mailto:[email-masked]>>
Cc: 5GANGIP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Hi,

----

and routers

Ciao

L.

Cheers,
--/Saleem

Hi all,

Regards,
Dirk& Behcet

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:

The IETF Secretariat

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 7 Jun 2018 20:27:25 +0000

Security that leverages/enforces GTP:

Many operators have GTP aware firewalls that track GTP-C and operate on GTP-C and GTP-U. They can detect and drop spoof packets, not allow access to EPC from unknown elements. Do IE filtering, translation or insertion to deal with 3GPP release deltas (often used with IPX). They may have IPS too (we do) for both GTP networks and APN/APN-IPX DNS. We have a specific APN DNS implementation towards IPX with several protection systems.

Most mobile operators have an isolated “Gn/S5 network” and an IPX DMZ approach for “Gp/S8”. Thus an inside and outside view of encapsulated mobility traffic. A lot can depend on their trust domains and how they handle or get transport. Many drop S1-U straight onto their “Gn/S5 network” and once you remove encapsulation the “security experts” come out of the woodwork to complain about stuff.

We still refer to our inside network as Gn-VRF but its really an MPLS VPN over our common backbone (CBB) network. I would assume we’d create another MPLS VPN just for mapped traffic and add interworking functions to go from backhaul to MMT•-VRF (Mobility Mapped Traffic)• and to EPC/5G-core elements. Normally we’d drop traffic straight onto CBB Internet after UPF/PGW-U for consumer general purpose APN but if there is mapping on this side too then I need to think about that towards services.

Just kidding around with the trade marks 😊

I or somebody else (I am retiring) would need to do a lot of work to duplicated functionality for our end-to-end CoS/QoS treatment. We currently can mark inside and outside GTP packet uniquely for treatment on transport, EPC, CBB and to/from services. We do have trust relationships with service partners and can honor ingress markings but also support other methods for managing service flows. We do support dedicated bearers and they can make before use.

We do a lot with roaming restrictions for both inbound and outbound roaming and we do learn roaming network capabilities.

We also use IPsec VPN for any untrusted backhaul.

From: Luigi Iannone <[email-masked]>
Sent: Thursday, June 07, 2018 3:14 AM
To: FIGURELLE, TERRY F <[email-masked]>
Cc: Saleem Bhatti <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Ciao

L;

Hi,

----

and routers

Ciao

L.

Cheers,
--/Saleem

Hi all,

Regards,
Dirk& Behcet

Abstract:

The IETF Secretariat

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Jun 2018 16:33:48 -0400

> 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.

Do you think this is a problem worth solving?

Dino

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 7 Jun 2018 21:12:06 +0000

The MTU mismatch?

We already have vendors working on auto-MTU adjust and working on device requirements so whenever it gets an updated MTU in PCO the device will honor it. We were told that this is something 3GPP would not be interested in since it is a temp deployment challenge not a long term challenge. Plus we require MRU>MTU so most elements can get a larger packet then they can send. We can set MTU per APN so the 5G APN is set to use full 1500 byte "Internet" MTU.

Thus you can have a network where legacy APN's stull do their thing then decide when/where to use larger MTU. IMS looks ripe for a larger than 1500 byte MTU. Those SIP messages can be huge. But we need to validate all the vendors can support this and work the details to get there.

Now if you can get the entire Internet to support more that 1500 byte MTU, you are better than me.

We worked a lot on MTU discovery but even for IPv6 this just doesn't pan out. I wish it did but realities sometimes suck and its taking way too long to get to all IPv6 ☹

Now if you meant something else please rephrase it concisely.

> From: Dino Farinacci <[email-masked]>
> Sent: Thursday, June 07, 2018 1:34 PM
> Cc: Tom Herbert <[email-masked]>; Luigi Iannone <[email-masked]>;
> 5GANGIP <[email-masked]>
> > 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.
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Jun 2018 15:17:33 -0700

> The MTU mismatch?

Yes, thanks for the explaination. But what are the other two issues: “between vendors” and “between address families”.

Dino

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 7 Jun 2018 23:07:55 +0000

Vendors do proprietary stuff on X2 so you can't do an X2 handoff between Nokia and Ericsson eNB's. You also can't use X2 between an IPv6 addressed eNB and an IPv4 addressed eNB. When you can't use X2 you are stuck with S1. Typically there is more latency to SGW and thus timing is tight.

The address family is only an issue if you migrate from IPv4 to IPv6 for transport and really it wasn't that big of a deal. Inter-vendor is a different story since there is always an edge somewhere when you use two or more vendors. We only need to keep the amount of S1 handoffs within bounds and know what issues can occur.

If you look at the 3GPP Inter-MME Inter-SGW S1 handoff with indirect forwarding call flow you will know what I mean. That’s a lot of stuff to happen in a short amount of time. Since its common for RAN-MME-SGW to be from same vendor on some networks (not ours) this means where that edge happens you better cross your fingers!

If there isn't active traffic flow or you can suspend  then resume: S1 isn't a problem. But when you get some of those IMS call flows where you have 5 dedicated bearers and some are GBR, things get a bit wild. As an FYI the UE chipsets only support 5-3 ack/un-ack or un-ack/ack (I forget which off top of my head) so you have to be careful how many bearers of what flavor you have.

So far the IMS services people have not shown any restraint on using up resources.

> Sent: Thursday, June 07, 2018 3:18 PM
> Yes, thanks for the explaination. But what are the other two issues:
> “between vendors” and “between address families”.
> 
> Dino
> 
> >
> > We already have vendors working on auto-MTU adjust and working on
> device requirements so whenever it gets an updated MTU in PCO the device
> will honor it. We were told that this is something 3GPP would not be
> interested in since it is a temp deployment challenge not a long term
> challenge. Plus we require MRU>MTU so most elements can get a larger
> packet then they can send. We can set MTU per APN so the 5G APN is set to
> use full 1500 byte "Internet" MTU.
> >
> > Thus you can have a network where legacy APN's stull do their thing then
> decide when/where to use larger MTU. IMS looks ripe for a larger than 1500
> byte MTU. Those SIP messages can be huge. But we need to validate all the
> vendors can support this and work the details to get there.
> >
> > We worked a lot on MTU discovery but even for IPv6 this just doesn't
> > pan out. I wish it did but realities sometimes suck and its taking way
> > too long to get to all IPv6 ☹
> >
> >> Subject: Re: [5gangip] New Version Notification for
> >> draft-xyzy-atick-gaps- 00.txt
> >>
> >> families they can’t go between MTU sizes. So we need to do all the
> >> tracking areas in a market to avoid S1 handovers.
> >>

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 07 Jun 2018 16:30:47 -0700

Dino,

Back in Ye Olde Days, MTU in radio nets was drastically smaller than in
wireline due to RF noise.  Bit error rate for radio is orders of
magnitude greater than, say, fiber.  Further, in lower-capacity links,
the number of bits in flight is a lot greater and too-large MTUs left
wannabes unable to wedge into the link, perhaps with high precedence
traffic.  There's a multi-variable optimization problem between bit
error rate, forward error correction and interruptability that is
complex enough that when WiFi appeared, it simply reused the MTU=1500
that ethernet had used.  
     And ethernet used 1500 because it was a round number and was big
enough to get at least one datagram in (datagram sizes were never
standardized but a convention number in the 700 byte territory was used
in early days because that was the max size of RAM available in an
early packet switch after the router programming was put in and
started.)  
     In radio, errors in frequencies below about 8MHZ are dominated by
lightning.  Refracted by ionosphere.  There's always a thunderstorm
going on somewhere in the world...  Above that frequency, you get less
lightning racket -- lightning  noise becomes a local phenomenon because
the higher freqs don't refract through ionosphere.  Rather, bit error
rate is more dominated by galactic noise.  And increasingly, man-made
racket.  

So before you and Terry go jacking up the MTUs, there are a couple 'yes
buts'.  

b

On Thu, 2018-06-07 at 15:17 -0700, Dino Farinacci wrote:
> > device requirements so whenever it gets an updated MTU in PCO the
> > device will honor it. We were told that this is something 3GPP
> > would not be interested in since it is a temp deployment challenge
> > not a long term challenge. Plus we require MRU>MTU so most elements
> > can get a larger packet then they can send. We can set MTU per APN
> > so the 5G APN is set to use full 1500 byte "Internet" MTU.
> > 
> > Thus you can have a network where legacy APN's stull do their thing
> > then decide when/where to use larger MTU. IMS looks ripe for a
> > larger than 1500 byte MTU. Those SIP messages can be huge. But we
> > need to validate all the vendors can support this and work the
> > details to get there.
> > 
> > We worked a lot on MTU discovery but even for IPv6 this just
> > doesn't pan out. I wish it did but realities sometimes suck and its
> > taking way too long to get to all IPv6 ☹
> > 
> > > Subject: Re: [5gangip] New Version Notification for draft-xyzy-
> > > atick-gaps-
> > > 00.txt
> > > 
> > > >

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 7 Jun 2018 23:57:05 +0000

I only want to be able to pass a UE 1500 IP packet thru the network without fragmentation even for small cell where you have GTP and IPsec headers. Using a transport MTU2000 on eNB and EPC data plane elements is more than enough to allow those encapsulations without needing fragmentation.

I also know way to much about bit error rates and feed forward error correction. When they started talking about feed forward error correction being sent from neighboring sectors that got my attention.

I once challenged somebody to do the math for beam forming. I think they gave up after a couple of weeks. He was complaining why we paid some people so much. I never got a chance to say because it doesn't take them a couple of weeks!

> From: Rex Buddenberg <[email-masked]>
> Sent: Thursday, June 07, 2018 4:31 PM
> To: Dino Farinacci <[email-masked]>; FIGURELLE, TERRY F
> <[email-masked]>
> Cc: Luigi Iannone <[email-masked]>; Tom Herbert <[email-masked]>;
> Back in Ye Olde Days, MTU in radio nets was drastically smaller than in wireline
> due to RF noise.  Bit error rate for radio is orders of magnitude greater than, say,
> fiber.  Further, in lower-capacity links, the number of bits in flight is a lot greater
> and too-large MTUs left wannabes unable to wedge into the link, perhaps with
> high precedence traffic.  There's a multi-variable optimization problem between
> bit error rate, forward error correction and interruptability that is complex
> enough that when WiFi appeared, it simply reused the MTU=1500 that ethernet
> had used.
>      And ethernet used 1500 because it was a round number and was big enough
> to get at least one datagram in (datagram sizes were never standardized but a
> convention number in the 700 byte territory was used in early days because
> that was the max size of RAM available in an early packet switch after the router
> programming was put in and
> started.)
> lightning.  Refracted by ionosphere.  There's always a thunderstorm going on
> somewhere in the world...  Above that frequency, you get less lightning racket --
> lightning  noise becomes a local phenomenon because the higher freqs don't
> refract through ionosphere.  Rather, bit error rate is more dominated by galactic
> noise.  And increasingly, man-made racket.
> 
> So before you and Terry go jacking up the MTUs, there are a couple 'yes buts'.
> 
> b
> 
> 
> > > device will honor it. We were told that this is something 3GPP would
> > > not be interested in since it is a temp deployment challenge not a
> > > long term challenge. Plus we require MRU>MTU so most elements can
> > > get a larger packet then they can send. We can set MTU per APN so
> > > the 5G APN is set to use full 1500 byte "Internet" MTU.
> > >
> > > pan out. I wish it did but realities sometimes suck and its taking
> > > way too long to get to all IPv6 ☹
> > >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_5gangip&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl
> >
> 2paJIf4zw&m=kEgRvI2s9tO3cGtRNOgWGjsXlDy18UBXS4gkFz9cMWY&s=JYVGc
> _lQt_62
> > X66D-1KYrqbqjOMSwSIytZMPe94JAms&e=

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Jun 2018 17:21:17 -0700

So to account for GTP headers, do you have the UEs send like 1400 byte max sized packets?

Dino

> On Jun 7, 2018, at 4:57 PM, FIGURELLE, TERRY F <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Jun 2018 17:22:51 -0700

Personally, I want to lower them. We can’t fragment. The performance of the system will go down as you guys know. 

A 1400 MTU is a sloppy max. Leaves room for other stuff you didn’t account or know about further downstream.

Dino

> On Jun 7, 2018, at 4:30 PM, Rex Buddenberg <[email-masked]> wrote:
> 
> Dino,
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 7 Jun 2018 18:53:17 -0700

> So to account for GTP headers, do you have the UEs send like 1400 byte max sized packets?
That would only account for UEs that are sending to other hosts, not
all the hosts on the Internet that are sending to UEs. Looks like
Terry is suggesting to use jumbo frames with 2000 MTU. That will work
in a closed network where everything is tightly managed, but isn't a
general solution (by IETF standards). See draft-ietf-intarea-tunnels.

Also note the problems of tunneling like encapsulation overhead,
diff-serv, hashing for ECMP, UDP checksum, fragmentation go away if
tunneling is not being done. This is mentioned in the draft. Sure, it
may be the case that over the years operators and vendors have
provided solutions to these problems, but if that entails a whole
bunch of complexity in both implementation (like protocol specific
logic) and deployment then that itself becomes the problem. In the
face of such complexity, that creates a high barrier of entry for
alternative solutions and innovation.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Jun 2018 19:57:00 -0700

> tunneling is not being done. This is

You heard what was said, GTP is not going away anytime soon. 

There is no diff-serv problem, hashing can always be improved, as was just said in this thread, no UDP checksum problem,  and fragmentation can be avoided. 

We’ve seen all of this with LISP deployment. These are not real problems. Just ones that are fabricated. 

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 8 Jun 2018 10:51:03 +0200

> On 7 Jun 2018, at 13:29, Saleem Bhatti <[email-masked]> wrote:
> 
> 

[snip]
> The RFC6742 DNS RRs for ILNP are supported/deployed in the same sense as IPv6 AAAA RRs are supported and deployed - they are implemented but you only configure them for use when you need them.

You are right, I was unclear. Let me rephrase it. How many people use ILNP out there? How many L64 RR are actually configured in DNS?

> If by "connected" and "connect" you mean a layer 2 association with a WiFi basestation, then you cannot tell if it supports ILNPv6 just from the layer 2 association, just like you cannot tell if th…

I was talking about L3. I connect to an open WiFi, How do they know I support ILNP?

> An ILNPv6 mobile node that uses DNS will have a L64 RR. When the mobile node moves, it learns its new Locator value (which is the IPv6 routing prefix learned from an IPv6 Router Advertisement), the…

My point was more about general management. In my work place they need to know whether my devices are ILNPv6 or not because I need to mangle with the DNS, right?

Thanks

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 8 Jun 2018 10:51:41 +0200

> On 7 Jun 2018, at 16:56, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jun 7, 2018 at 3:13 AM, Luigi Iannone <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 6 Jun 2018, at 23:58, FIGURELLE, TERRY F <[email-masked] <mailto:[email-masked]>> wrote:
>> 

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. 
> 
>> 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://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:

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 8 Jun 2018 10:57:09 +0200

> On 8 Jun 2018, at 04:57, Dino Farinacci <[email-masked]> wrote:
> 
> We’ve seen all of this with LISP deployment.

I agree with Dino that people using  LISP have a lot of experience on coping with these kind of issues  

Ciao

L.

> These are not real problems.

> Just ones that are fabricated. 
> 
> Dino

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 8 Jun 2018 10:56:59 +0000

Luigi;

On 08 Jun 2018, at 09:51, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

On 7 Jun 2018, at 13:29, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

[snip]

None outside the St Andrews testbed, as far as I know.

At layer 3, to spot a node that runs ILNPv6, a device would need to see packets from the ILNPv6 node that contain the Nonce Header (e.g. a TCP SYN for a connection set-up), or a DNS update for L64, or a Locator Update message.

Only if they expect the ILNP nodes to have incoming connections requiring DNS lookups would you need a DNS entry for the node, e.g. if the ILNP node was running a web server. If the ILNP node is a client system only, or it is using an application with its own presence/rendezvous mechanism, then it would not need a DNS entry.

Both the Nonce Header (RFC6744) and the Locator Update messages (RFC6743) have IANA-assigned codepoints, so firewall policies can be set-up as required. Other than that, the ILNPv6 packets look like IPv6 packets, on the wire.

Cheers,
--/Saleem

Thanks

Luigi

Cheers,
--/Saleem

Thanks

Ciao

L.

Cheers,
--/Saleem

Regards,
Behcet
Cheers
Dave

-----Original Message-----
From: 5gangip <[email-masked]<mailto:[email-masked]>> On Behalf Of Saleem Bhatti
Sent: Wednesday, May 30, 2018 9:19 AM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: Luigi Iannone <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>; Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Tom;

Good catch - thanks.

Cheers,
--/Saleem

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Fri, 8 Jun 2018 22:18:58 +0000

Sent from my iPhone

On Jun 7, 2018, at 7:57 PM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

That’s a bit harsh.

GTP encapsulation can increase fragmentation and fragmentation does cause problems.

It increases latency because layer4 (e.g. PCEF) has to buffer until it has full packet. Retransmits at RAN layer2 can cause out of order packets. That is really bad when one of the fragments is out of order and the number of packets between the fragments is larger than a layer4+ element is configured to handle or supports.

While AT&T has taken great efforts to address all of these issues, often blazing the trail, not all mobile operators have the knowledge and resources to do so.

However, there is plenty of info on the topic and vendors should do the right things for their mobile network operator customers.

Typically the easiest things to do is reduce MSS for TCP traffic and attempt to reduce device MTU. TCP can be the majority of traffic on mobile networks (Google YouTube can flip that due to QUIC).

An addressable or transparent proxy that can be a TCP proxy should be set not only for MSS that prevents fragmentation but you want SACK too. Since TCP latency can play a huge role in throughout (see Massey in wiki TCP) due to bit error rates causing retransmits. The split TCP sessions (inside and outside of proxy) reduces the apparent latency over the RAN for the inside TCP session.

While mobiles have gotten a bit creative with their TCP stacks, the user still feels the impact of stalls. It’s a very common complaint even when a MNO/ISP does everything right.

It can also help to reduce MTU in PCO but not all mobiles honor that 3GPP feature. That also didn’t help mobile WiFi hotspots or tethering.

Yes, larger transport MTU is probably worth pursing at least for RAN and backhaul for GTP-U. I would start with backhaul transport contracts by adding at least IP MTU 2000 or appropriate layer2 value. Then as contracts expire the new ones should support what you need. Make sure as any upgrades are done on network, EPC or RAN that it can support larger transport MTU and if possible set MRU>MTU. This takes planning and time to fix.

I do think we should focus more on the benefits mapping can have towards services. Particularly when those services are in more than one location and for devices that typically are moving or nomadic enough to cross wireless (tracking area changes that cause path changes) or service locations changes.

Apps are all over the place when it comes to how they deal with or tolerate lost sessions, lost transactions, periods of unavailability, location changes and other factors due to an access that is less reliable and more variable when compare to current fixed location ISP access.

How does mapping help for these types of problems?

It could support a better path to a service which could include migration to a new service location. It could obscure that from the service or it could enable the service to move to the new location.

Just my thoughts.

Dino
_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=o9ik5qSzFvRAmMSixdE24AXFFKxQ9Yy6D3o5JYG4MbE&s=iin_2H25Swh9BuuHKWfDWpES5-WhM3osr0TWrIg7HnA&e=

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Jun 2018 15:31:39 -0700

> On Jun 7, 2018, at 7:57 PM, Dino Farinacci <[email-masked]> wrote:
> 

Well maybe, but it is based on reality which some people, I believe, don’t believe. But enough with that.

> GTP encapsulation can increase fragmentation and fragmentation does cause problems.

Yes, but you avoid it.

> It increases latency because layer4 (e.g. PCEF) has to buffer until it has full packet. 

I am not arguing that fragmentation is okay to run with. I’m just saying its not that often and can be controlled that you DO NOT do fragmentation. The LISP RFC specifies 3 mechanisms to deal with MTU issues.

> Retransmits at RAN layer2 can cause out of order packets. That is really bad when one of the fragments is out of order and the number of packets between the fragments is larger than a layer4+ element is configured to handle or supports.
> 

The IP RFC states “fragmentation is considered harmful”. I think many, as I agree with this. So let’s not debate that.

> I do think we should focus more on the benefits mapping can have towards services. Particularly when those services are in more than one location and for devices that typically are moving or nomadi…

I agree 100% but topics continue to come up on the data-plane, both here and in DMM. Honestly, the data-plane really doesn’t matter as long as you can take the fewest hops from source to destination. Anything else is a non-starter.

The focus should ABSOLUTELY be on the control-plane. In particular how a sharded database can be DoS attack resilent, if any.

> How does mapping help for these types of problems?

When you have an overlay router close the source (or embedded at the source), and the overlay router has choices to select different paths (and not necessarily every hop in the underlay), there is more control and faster switch-over convergence then by injecting routes across a diameter.

And the mapping system can give you centralized policy controlled, versus the mess we have with ACLs spread across the entire Internet.

> It could support a better path to a service which could include migration to a new service location. It could obscure that from the service or it could enable the service to move to the new locatio…

100% agree. Overlays allow incremental deployment of services that you can try out in a few places that can be far away from each other.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Jun 2018 15:34:21 -0700

On Fri, Jun 8, 2018 at 3:18 PM, FIGURELLE, TERRY F <[email-masked]> wrote:

> There is no diff-serv problem, hashing can always be improved, as was just
> said in this thread, no UDP checksum problem,  and fragmentation can be
> avoided.
>
> It increases latency because layer4 (e.g. PCEF) has to buffer until it has
> full packet. Retransmits at RAN layer2 can cause out of order packets. That
> is really bad when one of the fragments is out of order and the number of
> packets between the fragments is larger than a layer4+ element is
> configured to handle or supports.
>
> Hi Terry,

That's interesting. I would assume that the typical fragmentation pattern
in the tunneling MTU scenario is precisely two fragments. I believe this is
usually one big fragment followed by one small one. I would expect fragment
loss to be a problem, but without loss it's a bit surprising that OOO would
be a major issue, maybe this is going through some middlebox that expects
fragments in order?. The general OOO problem between fragments and not
fragments is being solve in other IETF protocols either by fragmenting
within the encapsulation (like in GUE) or the basing ECMP in flow label and
not transport ports (i.e. transport ports only are in first fragment).

While AT&T has taken great efforts to address all of these issues, often
> blazing the trail, not all mobile operators have the knowledge and
> resources to do so.
>
> However, there is plenty of info on the topic and vendors should do the
> right things for their mobile network operator customers.
>
> Typically the easiest things to do is reduce MSS for TCP traffic and
> attempt to reduce device MTU. TCP can be the majority of traffic on mobile
> networks (Google YouTube can flip that due to QUIC).
>
> An addressable or transparent proxy that can be a TCP proxy should be set
> not only for MSS that prevents fragmentation but you want SACK too. Since
> TCP latency can play a huge role in throughout (see Massey in wiki TCP) due
> to bit error rates causing retransmits. The split TCP sessions (inside and
> outside of proxy) reduces the apparent latency over the RAN for the inside
> TCP session.
>
> While mobiles have gotten a bit creative with their TCP stacks, the user
> still feels the impact of stalls. It’s a very common complaint even when a
> MNO/ISP does everything right.
>
> It can also help to reduce MTU in PCO but not all mobiles honor that 3GPP
> feature. That also didn’t help mobile WiFi hotspots or tethering.
>
> Yes, larger transport MTU is probably worth pursing at least for RAN and
> backhaul for GTP-U. I would start with backhaul transport contracts by
> adding at least IP MTU 2000 or appropriate layer2 value. Then as contracts
> expire the new ones should support what you need. Make sure as any upgrades
> are done on network, EPC or RAN that it can support larger transport MTU
> and if possible set MRU>MTU. This takes planning and time to fix.
>
> I do think we should focus more on the benefits mapping can have towards
> services. Particularly when those services are in more than one location
> and for devices that typically are moving or nomadic enough to cross
> wireless (tracking area changes that cause path changes) or service
> locations changes.
>
> Apps are all over the place when it comes to how they deal with or
> tolerate lost sessions, lost transactions, periods of unavailability,
> location changes and other factors due to an access that is less reliable
> and more variable when compare to current fixed location ISP access.
>
> ILA eschews encapsulation, so that avoids the tunneling issues like this.

> It could support a better path to a service which could include migration
> to a new service location. It could obscure that from the service or it
> could enable the service to move to the new location.
>
> Just my thoughts.
>
>
> Dino
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_5gangip&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_
> sNxa2NTxwl2paJIf4zw&m=o9ik5qSzFvRAmMSixdE24AXFFKxQ9Yy6D3o5JYG4MbE&s=iin_
> 2H25Swh9BuuHKWfDWpES5-WhM3osr0TWrIg7HnA&e=
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Jun 2018 15:38:27 -0700

> That's interesting. I would assume that the typical fragmentation pattern in the tunneling MTU scenario is precisely two fragments. I believe this is usually one big fragment followed by one small one. 

My implementation fragments into two equal sizes, so one can avoid fragmentation again further downstream.

And I also have seen jumbo frames that needed to be fragmented into 1500 byte fragments. So I fragment into 6 fragments, not 3.

Dino