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

From: <[email-masked]>
Date: Tue, 23 May 2017 09:53:26 +0000

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: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, SungHoon Seo <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, Dirk von Hugo <[email-masked]<mailto:[email-masked]>>, Satish Kanugovi <[email-masked]<mailto:[email-masked]>>

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<http://tools.ietf.org>.

The IETF Secretariat

---

From: Ca By <[email-masked]>
Date: Tue, 23 May 2017 08:51:45 -0700

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.

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, <[email-masked]> wrote:

> Please check whether we have addressed the comments correctly and continue
> to discuss this towards further improvement.
>
> From: <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>, Tom Herbert <[email-masked]>,
> Roland Schott <[email-masked]>, SungHoon Seo <[email-masked]>,
> Roland Schott <[email-masked]>, Dirk von Hugo <
> [email-masked]>, Satish Kanugovi <[email-masked]>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>

---

From: <[email-masked]>
Date: Tue, 23 May 2017 16:19:57 +0000

Various comments, agreements, disagreements <dl> in-line </dl>.  Plus I’m cc-ing the IDEAS BoF list as I think we have a degree of cross-over here.

D

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: 23 May 2017 16:52
To: [email-masked]
Cc: [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

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.

<dl> Not sure I agree with this statement.  In LTE, you can determine an exactl quality (QCI) and setup up both a radio bearer and an IP level transport profile to guarantee a defined throughput.  Today, this only goes as far as the IMS core, but that is because we have no mechanism to extend QoS policy and admission beyond the bounds of a single operator.  The UE works with the network, both IP and RAN, to maintain the QoE against the required level.   This then becomes a pure matter of coverage at sufficient density to ensure quality.

When you attach to WiFi, all bets are off.  The UE is unable to make any judgement as to the quality of ANY part of the transport, whether RAN or IP network and service degradation is not graceful.   More and more I am finding LTE much more reliable than local WiFi + wired Internet for voice calls (plus cheaper – LTE service plans are tending towards free in many geographies whereas hotels still seem to want to charge HUGE amounts for bad WiFi). </dl>

<dl> Separate item.  On the YouTube/CDN side, many operators would like the ability to be able to offer defined service levels based on content – we have 9 QCIs in LTE (and more in 5GNR) but we currently only use 2.   If we had the ability to expose the mechanism by which content providers could offer a better service level across the air-interface, then you could see the way to a revenue-sharing model between OTTs and MNOs through a settlement system (much as happens in many other shared networks such as rail, electricity, gas, water). </dl>

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.

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.

<dl> The 5G NR ship may have sailed, but 23.501 is FULL of holes when it comes to the core network.  In fact, 23.501 is proposing using the SAME protocols and the SAME anchor as in current LTE EPC.  My guess is that we’ll see a 2-step approach to 5G – 5GNR introduced for 2018/2020 time-frame; 5G New Core in the 2020/2025 time-frame.  PLENTY of time for IETF and 3GPP to fix some of the anchor/latency issues.  </dl>

<dl> We should also not lose sight that the things which current EPC does well (streaming with large packets from centralised CDNs) are in violent opposition to a number of 5G use-cases such as the transport of very infrequent, small-sized data such as in IoT.  When you have a video segment comprising many ~1500 Byte payloads, addressing overhead length is negligible.  When you are sending a 2 Byte temperature reading once every 2 hours and there are 9 or 10 layers of addressing, this becomes very inefficient. </dl>

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

<dl> Side Comment.   There is much work here in IDEAS, 5gangip and netslices which seems to be inter-related and VERY relevant.  Somehow, we need to ensure that the groups work together.  I actually think this problem space is broader than the thee BoFs currently being planned… </dl>

On Tue, May 23, 2017 at 2:53 AM, <[email-masked]<mailto:[email-masked]>> 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: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, SungHoon Seo <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, Dirk von Hugo <[email-masked]<mailto:[email-masked]>>, Satish Kanugovi <[email-masked]<mailto:[email-masked]>>

Name:           draft-xyx-5gip-ps
Revision:       01

Abstract:

The IETF Secretariat

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 May 2017 11:42:00 -0500

Hi Cameron,

As always, you are a bit harsh on critism but we are used to that :)

My comments in line.

On Tue, May 23, 2017 at 10:51 AM, Ca By <[email-masked]> wrote:

> way.

>   In fact, MAMS as a proxy

This one I'll let Satish say something.
My view is that as we clarified in Rev. 01, MAMS was originally designed
for 4G. 5G work is what we want to do in this group and your input
is welcome.

> 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.
>
>
You are talking about proxy mode. I agree with that. But we have also ILNP
like host based mode which we want to concentrate.

> in the best position to determine network quality and user experience.
That is fine.

> I think we said similar things in Rev.01, the network can not trust UE.

> carry on the effort at 6G to avoid folks getting confused.
See David Lake's comments.

> signalling and user-plane modification from the 3GPP steady state?  How is
This is where we want to go provided that we don't deal much with legacy
hosts.

Regards,

Behcet

>> Please check whether we have addressed the comments correctly and
>> continue to discuss this towards further improvement.
>>

---

From: Ca By <[email-masked]>
Date: Tue, 23 May 2017 09:50:49 -0700

Thanks for the feedback, inline.

On Tue, May 23, 2017 at 9:19 AM, <[email-masked]> wrote:

> Various comments, agreements, disagreements <dl> in-line </dl>.  Plus I’m
> cc-ing the IDEAS BoF list as I think we have a degree of cross-over here.
>
>
>
> D
>
>
>
> *From:* 5gangip [mailto:[email-masked]] *On Behalf Of *Ca By
> *Sent:* 23 May 2017 16:52
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [5gangip] FW: New Version Notification for
> draft-xyx-5gip-ps-01.txt
>
>
>
> Folks,
>
>
>
> <dl> Not sure I agree with this statement.  In LTE, you can determine an
> exactl quality (QCI) and setup up both a radio bearer and an IP level
> transport profile to guarantee a defined throughput.  Today, this only goes
> as far as the IMS core, but that is because we have no mechanism to extend
> QoS policy and admission beyond the bounds of a single operator.  The UE
> works with the network, both IP and RAN, to maintain the QoE against the
> required level.   This then becomes a pure matter of coverage at sufficient
> density to ensure quality.
>

You cannot define throughput in the real world.  You can ask for 100mb/s,
but if there is only 5mb/s available (for whatever reason), you get 5mb/s.
 3GPP is only capable of setting a ceiling QoS, it can never set a floor,
because RF is hard.  Very hard, so hard that is not reasonable to ever
state you can set a quality / speed floor in a terms of service.

>
>
> When you attach to WiFi, all bets are off.  The UE is unable to make any
> judgement as to the quality of ANY part of the transport, whether RAN or IP
> network and service degradation is not graceful.   More and more I am
> finding LTE much more reliable than local WiFi + wired Internet for voice
> calls (plus cheaper – LTE service plans are tending towards free in many
> geographies whereas hotels still seem to want to charge HUGE amounts for
> bad WiFi). </dl>
>

This is not correct, the UE absolutely makes actionable quality judgement
on network paths today

See Apple Wi-Fi assist https://support.apple.com/en-us/HT205296

Or selecting based on destination address performance available in DNS with
Happy Eyeballs https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00

MP-TCP https://www.ietfjournal.org/multipath-tcp-deployments/

>
>
> <dl> Separate item.  On the YouTube/CDN side, many operators would like
> the ability to be able to offer defined service levels based on content –
> we have 9 QCIs in LTE (and more in 5GNR) but we currently only use 2.   If
> we had the ability to expose the mechanism by which content providers could
> offer a better service level across the air-interface, then you could see
> the way to a revenue-sharing model between OTTs and MNOs through a
> settlement system (much as happens in many other shared networks such as
> rail, electricity, gas, water). </dl>
>

This functionality is already treated by 3GPP PCC functions and deployed
broadly.

> <dl> The 5G NR ship may have sailed, but 23.501 is FULL of holes when it
> comes to the core network.  In fact, 23.501 is proposing using the SAME
> protocols and the SAME anchor as in current LTE EPC.  My guess is that
> we’ll see a 2-step approach to 5G – 5GNR introduced for 2018/2020
> time-frame; 5G New Core in the 2020/2025 time-frame.  PLENTY of time for
> IETF and 3GPP to fix some of the anchor/latency issues.  </dl>
>
>
>
> <dl> We should also not lose sight that the things which current EPC does
> well (streaming with large packets from centralised CDNs) are in violent
> opposition to a number of 5G use-cases such as the transport of very
> infrequent, small-sized data such as in IoT.  When you have a video segment
> comprising many ~1500 Byte payloads, addressing overhead length is
> negligible.  When you are sending a 2 Byte temperature reading once every 2
> hours and there are 9 or 10 layers of addressing, this becomes very
> inefficient. </dl>
>
>
>

I do not believe this use case is new or under-served.   It would be more
helpful to specifically quantify a problem. The description you gave needs
a tighter and more specific problem to solve, and it would be helpful to
understand how existing approachs (NB-IOT) are insufficient

> <dl> Side Comment.   There is much work here in IDEAS, 5gangip and
> netslices which seems to be inter-related and VERY relevant.  Somehow, we
> need to ensure that the groups work together.  I actually think this
> problem space is broader than the thee BoFs currently being planned… </dl>
>
>
>
>
>
>
>

---

From: <[email-masked]>
Date: Tue, 23 May 2017 17:18:17 +0000

And more <dl>in-line </dl> ☺

From: Ca By [mailto:[email-masked]]
Sent: 23 May 2017 17:51
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

On Tue, May 23, 2017 at 9:19 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Various comments, agreements, disagreements <dl> in-line </dl>.  Plus I’m cc-ing the IDEAS BoF list as I think we have a degree of cross-over here.

D

From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ca By
Sent: 23 May 2017 16:52
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

Folks,

You cannot define throughput in the real world.  You can ask for 100mb/s, but if there is only 5mb/s available (for whatever reason), you get 5mb/s.  3GPP is only capable of setting a ceiling QoS, it can never set a floor, because RF is hard.  Very hard, so hard that is not reasonable to ever state you can set a quality / speed floor in a terms of service.

<dl> Not sure I agree.   The ability to make different grades of voice call quality in LTE is determined by the radio coverage – the modulation method chosen asserts that.   If your RAN quality drops below a threshold, you will be dropped to a circuit-switched voice session.

You can define SLA in RF – look at DAB which offers defined service which varies by multiplex and offers absolute fixed bit-rates (which change according to the programme being transmitted).  This IS possible in planned RF systems such as cellular, DMB, DAB, DTT, etc.  It is not possible in shared/unmanaged spectrum systems such as WiFi. </dl>

This is not correct, the UE absolutely makes actionable quality judgement on network paths today

Or selecting based on destination address performance available in DNS with Happy Eyeballs https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00

<dl> But you still cannot set an end-to-end quality with any of these methods.  You can second-guess the possible path from the content to you, but at-best, it is a guess.  In VoLTE, I have a dedicated bearer, with packets associated with voice placed over specific modulation portions.  It is more like defining and policing Enterprise-class voice in a campus network with an admission engine and placing voice packets into queues with defined drop/latency.  It is possible to do that in 9 different structures in LTE and theoretically possible to associate different services with those constructs. </dl>

This functionality is already treated by 3GPP PCC functions and deployed broadly.

<dl> CDNs do not make use of anything other than the Default Bearer.  What I’d like to see is, for example, BBC iPlayer traffic coming to my mobile over a “video” bearer which gives an SLA better than Default, but not as good as the IMS bearer. </dl>

I do not believe this use case is new or under-served.   It would be more helpful to specifically quantify a problem. The description you gave needs a tighter and more specific problem to solve, and it would be helpful to understand how existing approachs (NB-IOT) are insufficient

<dl> If by NB-IoT you mean one of the LTE CAT-Mx, then they use the same NAS as regular LTE.   So, between UE and SGi on the S1 interface, I will see at least two, possibly three layers of IP addressing, two possibly three layer of GTP, an application addressing structure and at least one transport header (MPLS).   Observation taken from a large MNO showed that on-the-fibre between an eNB and an S-GW, at some points 10 addressing layers were seen. </dl>

CB

Best Regards
Dirk

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, SungHoon Seo <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, Dirk von Hugo <[email-masked]<mailto:[email-masked]>>, Satish Kanugovi <[email-masked]<mailto:[email-masked]>>

Name:           draft-xyx-5gip-ps
Revision:       01

Abstract:

The IETF Secretariat

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 May 2017 13:34:33 -0500

agree with David.

On Tue, May 23, 2017 at 12:18 PM, <[email-masked]> wrote:

> And more <dl>in-line </dl> J
>
>
>
> *From:* Ca By [mailto:[email-masked]]
> *Sent:* 23 May 2017 17:51
> *To:* Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> <dl> Not sure I agree.   The ability to make different grades of voice
> call quality in LTE is determined by the radio coverage – the modulation
> method chosen asserts that.   If your RAN quality drops below a threshold,
> you will be dropped to a circuit-switched voice session.
>
>
>
> You can define SLA in RF – look at DAB which offers defined service which
> varies by multiplex and offers absolute fixed bit-rates (which change
> according to the programme being transmitted).  This IS possible in planned
> RF systems such as cellular, DMB, DAB, DTT, etc.  It is not possible in
> shared/unmanaged spectrum systems such as WiFi. </dl>
>
>
>
>
>
> Or selecting based on destination address performance available in DNS
> with Happy Eyeballs https://tools.ietf.org/html/draft-ietf-v6ops-
> rfc6555bis-00
>
>
>
> <dl> But you still cannot set an end-to-end quality with any of these
> methods.  You can second-guess the possible path from the content to you,
> but at-best, it is a guess.  In VoLTE, I have a dedicated bearer, with
> packets associated with voice placed over specific modulation portions.  It
> is more like defining and policing Enterprise-class voice in a campus
> network with an admission engine and placing voice packets into queues with
> defined drop/latency.  It is possible to do that in 9 different structures
> in LTE and theoretically possible to associate different services with
> those constructs. </dl>
>
>
>
>
>
> <dl> CDNs do not make use of anything other than the Default Bearer.  What
> I’d like to see is, for example, BBC iPlayer traffic coming to my mobile
> over a “video” bearer which gives an SLA better than Default, but not as
> good as the IMS bearer. </dl>
>
>
>
>
>
> <dl> If by NB-IoT you mean one of the LTE CAT-Mx, then they use the same
> NAS as regular LTE.   So, between UE and SGi on the S1 interface, I will
> see at least two, possibly three layers of IP addressing, two possibly
> three layer of GTP, an application addressing structure and at least one
> transport header (MPLS).   Observation taken from a large MNO showed that
> on-the-fibre between an eNB and an S-GW, at some points 10 addressing
> layers were seen. </dl>
>
>
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 May 2017 13:32:27 -0700

On Tue, May 23, 2017 at 8:51 AM, Ca By <[email-masked]> 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.
>
> 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.
>
> 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

> 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.
>
>> To: Behcet Sarikaya <[email-masked]>, Tom Herbert
>> <[email-masked]>, Roland Schott <[email-masked]>, SungHoon
>> Seo <[email-masked]>, Roland Schott <[email-masked]>, Dirk von Hugo
>> <[email-masked]>, Satish Kanugovi <[email-masked]>
>>
>>
>>
>> URL:
>> https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-01.txt

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 May 2017 15:45:21 -0500

On Tue, May 23, 2017 at 3:32 PM, Tom Herbert <[email-masked]> wrote:

> protocols.
> telco
> streaming
I think the point here is ILA with encapsulation. Otherwise we can not use
ILA as in the datacenters, as we discussed before.

Behcet

> carry
> >> We have updated the PS draft on 5G IP issues regarding the planned BoF
> in
> >> Prague.
> >>
> continue

---

From: <[email-masked]>
Date: Wed, 24 May 2017 08:44:41 +0000

Dear all,
Valid discussion points raised, thanks for that ;-)

Regarding ongoing 3GPP work (23.501, 23.502) towards 5G solution standardization the vision of a revolutionary new flexible converged system is currently not yet addressed IMO. Yet representing valid steps in that direction acknowledged by 5G IP proposal instead of trying to replace it, we see that complementary work in several new areas is needed (e.g. true technology independence, maximum flexibility to assign and share resources for services demanding specific performance etc.).

More comments inline!
Thanks!
Best Regards
Dirk
From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Dienstag, 23. Mai 2017 20:35
To: [email-masked]
Cc: [email-masked]; Cameron Byrne
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

agree with David.

On Tue, May 23, 2017 at 12:18 PM, <[email-masked]<mailto:[email-masked]>> wrote:
And more <dl>in-line </dl> ☺

From: Ca By [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 23 May 2017 17:51
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

D

Folks,

You can define SLA in RF – look at DAB which offers defined service which varies by multiplex and offers absolute fixed bit-rates (which change according to the programme being transmitted).  This IS possible in planned RF systems such as cellular, DMB, DAB, DTT, etc.  It is not possible in shared/unmanaged spectrum systems such as WiFi. </dl>
 DH> The key issue IMO is to utilize available (spectrum) resources more efficiently like not ‘waste’ real-time capacity for best effort traffic etc. Of course an absolute grant of data rate and latency is and remains difficult in RF.

MP-TCP https://www.ietfjournal.org/multipath-tcp-deployments/
<dl> But you still cannot set an end-to-end quality with any of these methods.  You can second-guess the possible path from the content to you, but at-best, it is a guess.  In VoLTE, I have a dedicated bearer, with packets associated with voice placed over specific modulation portions.  It is more like defining and policing Enterprise-class voice in a campus network with an admission engine and placing voice packets into queues with defined drop/latency.  It is possible to do that in 9 different structures in LTE and theoretically possible to associate different services with those constructs. </dl>
 DH> … and what the UE always will miss is the ‘global’ view which only the network can have and use for proper decisions (more efficiently IMO and in close cooperation with the UE where possible).

DH> IMO it is never an either or decision but there are scenarios for each technology to serve best … and the universal core may help to find and decide on them
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

Best Regards
Dirk

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, SungHoon Seo <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, Dirk von Hugo <[email-masked]<mailto:[email-masked]>>, Satish Kanugovi <[email-masked]<mailto:[email-masked]>>

Name:           draft-xyx-5gip-ps
Revision:       01

Abstract:

The IETF Secretariat

---

From: Ca By <[email-masked]>
Date: Wed, 24 May 2017 12:32:00 +0000

> than encapsulation in both on the wire overhead and processing

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.

> >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-01

---

From: <[email-masked]>
Date: Wed, 24 May 2017 12:57:03 +0000

Ca

This is an interesting comment from you:

“Tom -- as a network operator, my ideal scenario just moves the packets.  To that end, i would like to remove the anchor / touchpoint.”

What I’m hearing from many operators is that they want to be MORE than just moving packets as moving packets is commodity/utility.

They are looking for mechanisms where they can deliver specific content and find new revenue streams especially as they try to finance new-build of 5G.

My own (very personal) thought is that we are probably moving back to single-infrastructure models with multiple content providers (exact ownership model is unimportant in this context) where the customer interaction is with the service/content owner (which could be a Telco/SP) and there is a settlement between the content owners/providers and the transport provider.

There is certainly a lot of concern about the long-term viability of Telco businesses in the current model as ARPUs tends lower.

Is this state-of-affairs different to what you’re seeing?

Thanks

David

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: 24 May 2017 13:32
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

On Tue, May 23, 2017 at 1:32 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ca,

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.

>> To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert
>> <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, SungHoon
>> Seo <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, Dirk von Hugo
>> <[email-masked]<mailto:[email-masked]>>, Satish Kanugovi <[email-masked]<mailto:[email-masked]>>
>>
>>
>>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 May 2017 08:32:24 -0700

> 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 25 May 2017 00:22:58 -0700

On Wed, May 24, 2017 at 8:32 AM, Tom Herbert <[email-masked]> wrote:

> ILA is a super set of ILNP use cases. ILA can be used end to end
>

ILA can't be used end-to-end on general purpose hosts because it doesn't
meet IPv6 addressing best practices.

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 25 May 2017 08:48:09 +0000

Tom;

On 24 May 2017, at 16:32, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 24, 2017 at 5:32 AM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:

Ca,

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

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.

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

Dear all,

Best Regards
Dirk

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert
<[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>,
SungHoon
Seo <[email-masked]<mailto:[email-masked]>>, Roland Schott <[email-masked]<mailto:[email-masked]>>, Dirk von
Hugo
<[email-masked]<mailto:[email-masked]>>, Satish Kanugovi <[email-masked]<mailto:[email-masked]>>

Name:           draft-xyx-5gip-ps
Revision:       01

Abstract:

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 08:31:52 -0700

On Thu, May 25, 2017 at 1:48 AM, Saleem Bhatti <[email-masked]> wrote:
> Tom;
>
> On 24 May 2017, at 16:32, Tom Herbert <[email-masked]> wrote:
>
> 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):
>
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

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 25 May 2017 17:12:49 +0000

Tom;

On 25 May 2017, at 16:31, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 25, 2017 at 1:48 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Tom;

Ca,

- options for datacentres, including wide-area virtual machine image
migration

Hi Saleem,

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.

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

Cheers,
--/Saleem

Thanks,
Tom

Cheers,
--/Saleem

Tom

CB

Dear all,

Best Regards
Dirk

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert

Name:           draft-xyx-5gip-ps
Revision:       01

Abstract:

The IETF Secretariat

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 25 May 2017 18:05:51 +0000

[Uma]:  I would see 64-bit  stable identifier in the data plane as a restriction. As it’s possible for some of the ID control plane protocols will have harder time to get over
             with this restriction (for identifier length of 96-bits/HIT or control planes with full 128 bits identifier).
             Not sure what this restriction will  have on a truly anonymous global communication requirement discussed earlier.

BR,
--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 11:39:28 -0700

On Thu, May 25, 2017 at 10:12 AM, Saleem Bhatti <[email-masked]> wrote:
> Tom;
>
> On 25 May 2017, at 16:31, Tom Herbert <[email-masked]> wrote:
>
> 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).
>
> 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.
>
> I am not sure I understand what you mean here, but I would imagine it
> depends on the type/purpose of the tunnel.
>
>
> A /64 assigned to an ILNPv6 host would be treated as a Locator value - a L64
> value. Locator values in ILNPv6 are 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.
>

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? A ::1 identifier is not unique in
the network, 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.

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 25 May 2017 19:21:10 +0000

Tom;

On 25 May 2017, at 19:39, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 25, 2017 at 10:12 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Tom;

On Thu, May 25, 2017 at 1:48 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>>
wrote:

Tom;

Ca,

Hi Saleem,

Agreed.

I'm not

Overall, moving from IPv6 to ILNPv6 will be much less work that moving from
IPv4 to IPv6, in terms of lines of code.

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.

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

CB

Dear all,

Best Regards
Dirk

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>, Tom Herbert

Name:           draft-xyx-5gip-ps
Revision:       01

Abstract:

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 16:54:53 -0700

On Thu, May 25, 2017 at 12:21 PM, Saleem Bhatti <[email-masked]> wrote:
> Tom;
>
> On 25 May 2017, at 19:39, Tom Herbert <[email-masked]> wrote:
>
> 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.
>
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

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

---

From: Ca By <[email-masked]>
Date: Fri, 26 May 2017 00:07:49 +0000

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

> > On Thu, May 25, 2017 at 10:12 AM, Saleem Bhatti <[email-masked]
> >
> > wrote:
> >
> > Tom;
> >
> > 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.
> >

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.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 17:31:54 -0700

On Thu, May 25, 2017 at 5:07 PM, Ca By <[email-masked]> wrote:
>> > On Thu, May 25, 2017 at 10:12 AM, Saleem Bhatti
>> > <[email-masked]>
>> > wrote:
>> >
>> > Tom;
>> >
> 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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 25 May 2017 19:41:41 -0700

> assuming /64 bit assignment. That seems too little UEs for an ID/loc

This is why an encapsulation data-plane should be considered, even with additional packet overhead, you get flexibility with the 128-bit EID and 128-bit Locator so you don’t have to make the tradeoffs above. 

And you’ll see other benefits at the same time.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 26 May 2017 10:36:56 -0500

> meet IPv6 addressing best practices.
Neither does ILNP, right?

So we need some work.