Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

[Tom Herbert <[e-mail]>]

On Wed, May 24, 2017 at 5:32 AM, Ca By <[e-mail]> wrote:
>
> On Tue, May 23, 2017 at 1:32 PM Tom Herbert <[e-mail]> wrote:
>>
>> On Tue, May 23, 2017 at 8:51 AM, Ca By <[e-mail]> wrote:
>> > Folks,
>> >
>> > I remain very skeptical about the value of this group's collected
>> > protocols.
>> > The scope overlaps with work in the 3GPP, contradicts work in the 3GPP,
>> > and
>> > the proposed ideas here are not obviously high value or fit for the
>> > internet
>> > or mobile networks.
>> >
>> > Don't get me wrong, i am not in love with the 3GPP and i think there is
>> > a
>> > lot to improve on many fronts.  But,  MAMS and LISP and ILA are not on
>> > the
>> > short list of approaches i would hold up the 3GPP and say this is a
>> > better
>> > way.  In fact, MAMS as a proxy and ILA as a NAT are exactly the legacy
>> > telco
>> > stuff i would expect the IETF to work against in favor of a more secure,
>> > more salable, and more end-to-end internet.
>> >
>> > AFAIK, FMC is already solved today.  My very own iPhone can make calls
>> > on
>> > WiFi, LTE, and switch between the 2 -- this is all standard 3GPP work
>> > from
>> > IMS. When i sit outside my house with bad wifi, the UE bounces between
>> > WiFi
>> > and LTE endlessly, but this unstable network does not interrupt me
>> > streaming
>> > Youtube.  So, i just don't see a problem to be solved here, especially
>> > if it
>> > incurs a great deal of complexity and state and signalling.  That said,
>> > MIF
>> > and Happy Eyeballs both address this issue of performance and network
>> > selection -- and i would strongly suggest the UE is in the best position
>> > to
>> > determine network quality and user experience.
>> >
>> > I can't get over it this reduction: MAMs adds a proxy and ILA adds a
>> > NAT.  I
>> > just don't think that is architecturally wise in 4G or 5G.   They just
>> > can't
>> > scale in a gigabit broadband 5G usecase [which is the usecase that pays
>> > the
>> > bills, not the pie in the sky stuff], and don't add meaningful value,
>> > and
>> > simply detract value at scale.  Also, ILA and MAMs takes a lot of work
>> > on
>> > the UE.  Getting changes into the UE is very hard, it took 10 years from
>> > the
>> > standardization of IMS to get functional IMS client (VoLTE) deployed at
>> > scale.
>>
>> Hi Ca,
>>
>> Can you explain why you think ILA doesn't scale to gigabit broadband?
>>
>> ILA requires no changes to UEs and it's already being deployed in
>> datacenters at higher bandwidths than gigabit. It's more efficient
>> than encapsulation in both on the wire overhead and processing
>> overhead.
>>
>> Tom
>
>
> Tom -- as a network operator, my ideal scenario just moves the packets.  To
> that end, i would like to remove the anchor / touchpoint.
>
> The scaling comment is that any anchor needs to scale to N where N is some
> set of users total throughput. This is why ILNP appeals to me and ILA looks
> like more of what we already have today with less functionality.
>
Ca,

ILA is a super set of ILNP use cases. ILA can be used end to end or as
a means to implement an overlay within the network or something in
between. The typical deployment is a hybrid approach. If a non-ILA
enable node is talking to a mobile node communications can go through
a router; else if the node is ILA capable then it can get the ILA
mapping to speak directly to the mobile node and eliminate the
triangular routing.

Tom

>>
>> > Finally, the 5G ship has already sailed.  Many network are "launching
>> > 5G"
>> > this year, and more networks (including the one i work at ) are
>> > committed to
>> > launching "real 5G" in the next 2 to 3 years.  None of the work in this
>> > group is within that 5G scope AFAIK. So, it may be most appropriate to
>> > carry
>> > on the effort at 6G to avoid folks getting confused.
>> >
>> > I still hold out hope for ILNP to replace the mobility core at some
>> > future
>> > date, the radio network just does a simple authentication and that is
>> > all.
>> > But, that is my own dream of a simpler world :)  I would suggest the
>> > standard we look for in this group is:  what can we remove from 3GPP 5G
>> > /
>> > 6G, not what we can add.  How does the work in this group reduce NET
>> > signalling and user-plane modification from the 3GPP steady state?  How
>> > is
>> > that quantified?
>> >
>> > CB
>> >
>> >
>> >
>> > On Tue, May 23, 2017 at 2:53 AM, <[e-mail]> wrote:
>> >>
>> >> Dear all,
>> >>
>> >> We have updated the PS draft on 5G IP issues regarding the planned BoF
>> >> in
>> >> Prague.
>> >>
>> >> Please check whether we have addressed the comments correctly and
>> >> continue
>> >> to discuss this towards further improvement.
>> >>
>> >> Thanks a lot – also on behalf of Roland, SungHoon, and Behcet
>> >>
>> >>
>> >>
>> >> Best Regards
>> >> Dirk
>> >>
>> >>
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: <[e-mail]>
>> >> Date: Mon, May 22, 2017 at 1:22 PM
>> >> Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
>> >> To: Behcet Sarikaya <[e-mail]>, Tom Herbert
>> >> <[e-mail]>, Roland Schott <[e-mail]>,
>> >> SungHoon
>> >> Seo <[e-mail]>, Roland Schott <[e-mail]>, Dirk von
>> >> Hugo
>> >> <[e-mail]>, Satish Kanugovi <[e-mail]>
>> >>
>> >>
>> >>
>> >> A new version of I-D, draft-xyx-5gip-ps-01.txt
>> >> has been successfully submitted by Behcet Sarikaya and posted to the
>> >> IETF repository.
>> >>
>> >> Name:           draft-xyx-5gip-ps
>> >> Revision:       01
>> >> Title:          5G IP Access and Session Management Protocols
>> >> Document date:  2017-05-22
>> >> Group:          Individual Submission
>> >> Pages:          14
>> >> URL:
>> >> https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-01.txt
>> >> Status:         https://datatracker.ietf.org/doc/draft-xyx-5gip-ps/
>> >> Htmlized:       https://tools.ietf.org/html/draft-xyx-5gip-ps-01
>> >> Htmlized:
>> >> https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-01
>> >> Diff:           https://www.ietf.org/rfcdiff?url2=draft-xyx-5gip-ps-01
>> >>
>> >> Abstract:
>> >>    This document builds upon 5G IP issues work and - based on a
>> >>    simplified 5G system architecture - attempts to make the case for a
>> >>    possible set of new protocols that need to be developed to be used
>> >>    among various virtualized functions in a 5G network.
>> >>
>> >>
>> >>
>> >>
>> >> 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.
>> >>
>> >> The IETF Secretariat
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 5gangip mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/5gangip
>> >>
>> >
>> >
>> > _______________________________________________
>> > 5gangip mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/5gangip
>> >