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

[Dino Farinacci <[e-mail]>]

> On Jun 7, 2018, at 7:57 PM, Dino Farinacci <[e-mail]> wrote:
> 
>>> 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
>> 
>> 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. 
> 
> That’s a bit harsh.

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

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 nomadic enough to cross wireless (tracking area changes that cause path changes) or service locations changes.

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.

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

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

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

> 
> Just my thoughts.
>> 
>> Dino
>> _______________________________________________
>> 5gangip mailing list
>> [e-mail]
>> 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=