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

[Tom Herbert <[e-mail]>]

On Thu, May 25, 2017 at 1:48 AM, Saleem Bhatti <[e-mail]> wrote:
> Tom;
>
> On 24 May 2017, at 16:32, Tom Herbert <[e-mail]> wrote:
>
> On Wed, May 24, 2017 at 5:32 AM, Ca By <[e-mail]> wrote:
>
>
> 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.
>
>
> ILNP does not define an overlay mechanism or a tunnelling mechanism.
> However, I do not know a reason that ILNP could not be tunnelled, if
> tunnelling was required (for whatever reason).
>
> While ILNP is designed to be end-to-end, it also supports various use-cases
> with the deployment of an ILNP-capable site-border router (SBR), e.g. a
> router at the edge of a radio (access) network. Such a SBR could be used as
> a control and management point for a radio (access) network.
>
> RFC6748 gives an outline of some of the various use cases with an
> ILNP-capable SBR (perhaps not all of them are of interest to this list,
> however):
>
> - localised numbering (localised addressing)
> - site-multihoming
> - mobility of whole networks/sites
> - traffic engineering options
> - options for datacentres, including wide-area virtual machine image
> migration
> - identity privacy and location privacy
>
Hi Saleem,

My primary concern about ILNP is this statement from section 4,
RFC6741: "So, transport protocol implementations MUST be modified in
order to operate over ILNP." There are lot of transport protocol
implementations, some of these are not even in the kernel (like QUIC),
and some may be proprietary that we don't even know about. I'm not
sure it's feasible to require all transport implementations are
updated to understand ILNP. Also, this requirement probably makes
tunneling hard to do in ILNP without proxying.

> These are all possible without the loss of end-to-end state, and so can all
> be used together. For ILNPv6, they also preserve the current IPv6 addressing
> and numbering practises.
>
How does ILNP solve the /64 assignment to UEs problem? In this case it
seems the identifier needs to be longer than 64 bits.

Thanks,
Tom

> Cheers,
> --/Saleem
>
>
>
> 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
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>