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

[Ca By <[e-mail]>]

On Thu, May 25, 2017 at 4:54 PM Tom Herbert <[e-mail]> wrote:

> On Thu, May 25, 2017 at 12:21 PM, Saleem Bhatti <[e-mail]>
> wrote:
> > Tom;
> >
> > On 25 May 2017, at 19:39, Tom Herbert <[e-mail]> wrote:
> >
> > On Thu, May 25, 2017 at 10:12 AM, Saleem Bhatti <[e-mail]
> >
> > wrote:
> >
> > Tom;
> >
> > On 25 May 2017, at 16:31, Tom Herbert <[e-mail]> wrote:
> >
> > 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.
> >
> >
> > Agreed.
> >
> > I'm not
> > sure it's feasible to require all transport implementations are
> > updated to understand ILNP.
> >
> >
> > For ILNP, any protocol state that uses address bits directly potentially
> > needs to change, e.g. end-to-end state for TCP or UDP. However, I would
> not
> > expect application protocols (apart from specific systems
> > management/control/configuration applications) to use address bits
> directly
> > (but lots do).
> >
> > Overall, moving from IPv6 to ILNPv6 will be much less work that moving
> from
> > IPv4 to IPv6, in terms of lines of code.
> >
> > Of course, if there is a requirement for not refactoring transport layer
> > code for 5G and onwards, then the solution chosen must have someway of
> > dealing with that concern in an acceptable way. As far as I know, there
> is
> > no such requirement. I totally agree, however, that aiming to minimise
> > implementation pain is a good goal to aim for.
> >
> > Also, this requirement probably makes
> > tunneling hard to do in ILNP without proxying.
> >
> >
> > I am not sure I understand what you mean here, but I would imagine it
> > depends on the type/purpose of the tunnel.
> >
> >
> > 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.
> >
> >
> > A /64 assigned to an ILNPv6 host would be treated as a Locator value - a
> L64
> > value. Locator values in ILNPv6 are 64 bits.
> >
> > ILNPv6 Identifier values - Node ID (NID) values - are also 64 bits.
> >
> > So, I am not sure why an assignment of a /64 to an ILNPv6 end-node would
> > require the identifier to be longer than 64 bits.
> >
> > (My apologies if I have misunderstood your question.)
> >
> >
> > I think the problem is that there is no single global 64 bit
> > identifier space in this scenario. So for example, if two UEs get a
> > /64 address assignment they could each assign </64 prefix>::1 to their
> > nodes. So if an external node wants to communicate by ILNP for each of
> > these nodes, what is the identifier?
> >
> >
> > 1 (or ::1 as you have it above).
> >
> > A ::1 identifier is not unique in
> > the network,
> >
> >
> > A NID value MUST be unique within the scope of the Locator (the /64
> vlaue),
> > which is all that is required for ILNP.
> >
> > That is, no two nodes would have the NID value of 1 *and* the same value
> for
> > the Locator.
> >
> > For ILNPv6, as for ILNPv6, only the /64 - top 64 bits, the routing
> prefix,
> > the Locator - is used for routing, so that is enough to get the packet to
> > the correct UE.
> >
> > Once the packet is at the UE, the UE can then forward the packet to the
> > correct node.
> >
> Right, but the question is how the packet got to the UE in the first
> place. Consider that is it is the UE that moves around in the network
> and pulls its /64 address space along with. The locator is for the UE,
> that could refer to an eNodeB. Now in the example above suppose
> someone send a packet to node with identifier "1" and there are two
> UEs in the network that have assigned a node with "1" in the lower
> order 64 bits of their respective address spaces. How is the locator,
> i.e. eNodeB determined? It seems like  "1" as an identifier is not
> unique so there are two possible locators (one for each UE).
>
> Tom
>

Hi Tom,

An eNB today is strictly an L2 device today.

Assuming we change that, it may be more fit to say the eNB has a /48 and
assigns /64 to a UE per pdp / radio access bearer , that would align more
closely with today's architecture, and assuming each UE has exclusive
access to the /64, then rfc7238 may be relevant, as it is today.



> > more information is needed (probably about the UEs) to
> > differentiate them. In other words the logical node is identified by
> > both its UE and the address that UE assigned it within its
> > allocation-- that's more than 64 bits of information in the case a UE
> > is assigned a /64.
> >
> >
> > That is a L64<->NID binding issue handled locally at the correspondent
> node
> > (please see RFC6741, Section 5, specifically Section 5.4).
> >
> > Cheers,
> > --/Saleem
> >
> >
> >
> > Tom
> >
> > Cheers,
> > --/Saleem
> >
> >
> >
> > 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
> >
> >
>