Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

["FIGURELLE, TERRY F" <[e-mail]>]

Just had procedure in hospital. So a bit loopy and I tend to jump around and be long winded on my best days. So forgive my brain dump ;)

We use both widely and in many ways. More than even I know ;)

We widely use LAG and had a bit of learning experience on hashing plus port combinations which we had to accommodate into our overall design.

We get great distribution with two links, really good with four (great for 3 links and good for fourth plus improving). Depending on the vendor and line card the distribution on some of the links can be unbalance unless you work closely with that vendor. We have both box and box-cross (box-X, bow-box, pick your term). Within facility. All facilities are dual entry and we try to be unique path (not any same vault).

Depending on the link we detect or detect&correct in 1-5 seconds. We have a ton of live metrics and some amazing engineering on the MPLS backbone but I can’t share that information. Convergence is optimize and we get some really good numbers but I can’t share that either.

We have some pretty slick smartphone Apps which support controlled need to know information. Plus we enable our employees to be field testers and to report issues for all of our services.

We tend to overkill on design so things can run at capacity with any complete line card failure, supervisor failure, compute failure, etc. Site failures are split to at least two other sites by tracking area at same topology label length. Plus three major region IXC locations can handle both any in region site failure and any IXC site failure.

We also have an adaptive APN DNS that has configured topology and near-real-time GSN latency, utilization and health information. We are extending this to become our VSSF in 5G mobile core. For the MPLS VPN routing we have configured three region failover (east, central, west) which aligns with our three IXC zones that connect to IPX (Syniverse). We also use this for regional failover on APN’s with that feature where we have two or more connections to corporate data centers (Intranet). We have three sub regions per major region for SGW:PGW selection.

We exchange info with IPX who matches our regional routing failover design. This is critical for our Auto VoLTE (Connect Car) solution with other North American countries.

We set contestants like total latency budget for VoLTE but it turns out top bandwidth requires even tighter latency budget.

I feel that we need < 5ms cell site to Internet interface on UPF/SAE-GW. AT&T backbone carries ~60% of US Internet traffic. Rest is via tier1 ISP connections or direct data center connections (MIS, GMIS, AVPN). We have on-site equipment in all the big players US data centers (Apple, Amazon, Facebook, Google, IBM, video content {Netflix, HBO, STARZ,...}, Microsoft,...).

Sent from my iPhone

On Jan 30, 2018, at 1:06 PM, AshwoodsmithPeter <[e-mail]<mailto:[e-mail]>> wrote:

Terry,

How has your experience been with entropy and ECMP/LAG ? Are you generally getting enough diversity from ECMP and/or LAG ?

Peter

From: 5gangip [mailto:[e-mail]] On Behalf Of FIGURELLE, TERRY F
Sent: Tuesday, January 30, 2018 3:47 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Tom Herbert <[e-mail]<mailto:[e-mail]>>; 5GANGIP <[e-mail]<mailto:[e-mail]>>
Subject: Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

At least in the context of 3GPP 5G the PCF/PCRF knows the user identity (IMSI & MSISDN) and can know the mobile location (ULI) when starting any new service that may need unique routing (not default routing to TAI selected UPF). When PCF/PCRF creates flow rules it can do so by adapting IP header information particularly when using IPv6 UE addressing. We can also use dynamic DNS FQDN matches to create PCC rules. Leveraging CDN’s and anycast for key services can greatly improve resilience and closest service endpoint.

Since we know fiber topology and back haul locations; plus we know the locations of all on-net UPF’s/SAE-GW’s; there can be only a small number of alternate routes to best service location when the default location is not the best.

At least for 3GPP operators I am familiar with; they all have some regionalized topology that aligns with L1/L2 topology. Labels can be used to select next P/PE when using MPLS VPN for backbone which is common in North America and other parts of the world. Plus default routes are often managed using a dynamic routing protocol like BGP. These operators are all moving towards UPF/SAE-GW located in top markets. When small it was common to have at least two locations for disaster handling. The number of locations grew as these operators grew and as more capacity was needed.

Thus it always amounts to a spoke and hub topology and it’s always best to locate at least in each major hub location. The top 4 mobile operators in US have been 8-50 hub locations and 16-60 mobile core locations. So for bigger markets that aren’t already a hub it makes sense to locate a mobile core in a market aligned with fiber topology and content locations (e.g. host locations).

This network architecture must align with peering locations and with on-net paths to content. It also should align with IPX interconnect locations but only very big players optimize path to roaming PLMN thru multiple advertised routing locations. The IPX provided may optimized but for the most part the visited network has no visibility into the home network.

In any solution, we desire the default path to be the optimal path the majority of the time. We also want to select the optimal UPF for any given network/APN. Looking at the top 100 sites for mobile Internet traffic, AT&T only needs one or two alternate routes to/from UPF to cover 90% of the home mobile traffic. If AT&T executes to plan thru 2023 then default may cover 78% of traffic. This holds true even as more traffic switches from HTTP|HTTPS to QUIC.

Food for thought but I doubt we need the ability to define many unique service paths. UE’s leveraging the same cp
Sent from my iPhone

On Jan 30, 2018, at 7:46 AM, Behcet Sarikaya <[e-mail]<mailto:[e-mail]>> wrote:
Hi Tom,

Thanks Tom for your detailed review.
We need more of these.

Folks please read and comment!


On Mon, Jan 29, 2018 at 4:16 PM, Tom Herbert <[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jan 29, 2018 at 12:39 PM, Behcet Sarikaya
<[e-mail]<mailto:[e-mail]>> wrote:
> Hi all,
> Dirk and I submitted this PS draft.
> We need this to be discussed and improved. Please read and comment.

Hi Behcet,

Thanks for posting the draft. A few comments...

"However it can be argued that it is difficult to derive globally
unique identifiers only using 64 bits.  So it is better to use longer
identifiers, e.g. 80 bits or longer"

Can you elaborate on this?

I think it also say cryptographically generated ids. Otherwise administratively assigned ids could be unique and shorter, e.g.
IEEE 48 bit and 64 MAC addresses, 3GPP assigned IMSI, etc.
Thanks for pointing this.


I think the Privacy issues should be it's own section.
Identifier/locator has both pitfalls and give opportunities to improve
privacy.

"The use of identifiers unique for each user brings privacy issues. If
the identifier is stolen then your traffic can be unlawfully tracked,
there could be serious implications of it."

This is true today when devices have address or assigned a single /64.
One alternative is gives users thousands or millions of addresses
(identifier). Identifier/locator split should facilitate that.

Please suggest some text.

Note
that this effect is already provided by NAT since every connection
through a NAT is translated to non-trackable address/port. NAT has
some law enforcement agencies freaking out because of its strong
(inadvertent) privacy!
This reminds me some people say ILA is a NAT.

"Privacy of identifiers is especially an issue for a UE communication
with a server like Google, Facebook, LinkedIn, etc."

You might want to mention that simple identifier rotation [RFC4914] is
not enough these days..
Sure.

"Privacy issue can be mitigated only if Id-Loc system has proxy mode
of operation.  In proxy mode, user traffic is intercepted by a proxy.
Proxy node which could be placed at the subnet router or site border
router.  The router tunnels the traffic to the server.  In the process
UE identifier becomes hidden and this hopefully removes privacy
issues."

I'm not sure what this means. Multiple identifiers per deivce should
address the privacy issue, Maybe a proxy would have the same effect?
Again please provide some text.

"5G specific identifiers can also used to deal with privacy issues.
IMSI is known to be 64 bit and unique for each UE.  IMSI should not be
exposed to any entities.  It is like 64-identifier.  Instead
identifiers like 5G-GUTI can be used"

I think this is two levels. An identifier in IP identifies a node for
the purpose of being the endpoint of the communication. Something like
IMSI identifies a specific device (and hence user). In the best case
scenario, IP identifiers don't reveal the identity of users and they
can be made externally visible.

How?

IMSI is by its nature sensitive
information and only visible in a trusted domain. A mapping system
will need to map identifiers to identities (like an IMSI) so the
system needs to be secured.

When do you need to access the mapping system is the issue I think.
We did not want to get into this a lot in the draft it is more control plane.

A big item missing in this section is locator security. Fine grained
locators used in cellular system could be used to infer the
geo-location of devices and hence users, thus enabling stalkers
everywhere.  So locators need restricted visibility somehow..

Good point. But how? Again, some text please.

Behcet

Tom


> Also we are soliciting co-authors, please let us know.
>
> Regards,
> Dirk & Behcet
>
>
> A new version of I-D, draft-hspab-5gangip-atticps-00.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Name:           draft-hspab-5gangip-atticps
> Revision:       00
> Title:          IP Issues and Associated Gaps in Fifth Generation Wireless
> Networks
> Document date:  2018-01-28
> Group:          Individual Submission
> Pages:          7
> URL:
> https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dhspab-2D5gangip-2Datticps-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=7dyEB2UFH7E1g1h6pcV8s3QyJs1bENkBx8yjCVlRrEA&e=>
> Status:
> https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhspab-2D5gangip-2Datticps_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=MH8iYJXADVHjnJbj01V7pAdz2ilNoW_ycyduJYrgTEQ&e=>
> Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dhspab-2D5gangip-2Datticps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=vIZMCC0M5mLj9LDfZaEWn02ZE0IPlISdgkAtsuZP1Kw&e=>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dhspab-2D5gangip-2Datticps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=EloR12uUIk3R7PPOE_64kRzs1ThFDB9wKRuhPU6fP2w&e=>
>
>
> Abstract:
>    This document attempts to make the case for new work that need to be
>    developed to be used among various virtualized functions and the end
>    user which may be moving.  First a set of use cases on tunneling,
>    charging, mobility anchors are developed and then the steps of
>    proposed new work is described next.
>
>
>
>
> 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=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=1hqo0Z8nUbNsD-WYGkTPTRQjOxvWbUDn160TLBZVJgs&e=>.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]<mailto:[e-mail]>
> 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=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=lTpbqlECzLv3MxdsjJnvl_vKg51Ho8w8Zi1zW4LMf1s&e=>
>

_______________________________________________
5gangip mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=lTpbqlECzLv3MxdsjJnvl_vKg51Ho8w8Zi1zW4LMf1s&e=