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

[Tom Herbert <[e-mail]>]

On Thu, May 25, 2017 at 5:07 PM, Ca By <[e-mail]> wrote:
>
> 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.
>
Thanks. So in that case if we let the locator becomes 48 bits which
means we can have 65K UEs in the network with 80 bit identifier and
assuming /64 bit assignment. That seems too little UEs for an ID/loc
split addressing.

Tom

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