Subject: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 25 May 2018 09:50:33 -0500

Hi all,

We have submitted the gaps draft. Those who have contributed text are
listed as co-authors.
Please send your comments to the list.

Regards,
Dirk& Behcet

A new version of I-D, draft-xyzy-atick-gaps-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-xyzy-atick-gaps
Revision:       00
Title:          Gap and Solution Space Analysis for End to End Privacy
Enabled Mapping System
Document date:  2018-05-25
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-
00.txt
Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/
Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps

Abstract:
   This document presents a gap and solution analysis for end-to-end
   privacy enabled mapping systems.  Each of the identifier locator
   separation system has its own approach to mapping identifiers to the
   locators.  We analyse all these approaches and identify the gaps in
   each of them and do a solution space analysis in an attempt to
   identify a mapping system that can be end to end privacy enabled.

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: <[email-masked]>
Date: Fri, 25 May 2018 14:55:24 +0000

Dear all,
as already announced we plan to apply for a BoF in Montreal on the privacy issues of Id-Loc systems for 5G.
We would like to see your comments and proposals for refinement – since the deadline is next Friday!
We think that now there is a window of opportunity for IETF to start new work in the framework of 5G.
Best Regards – also on behalf of Behcet
Dirk

From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Freitag, 25. Mai 2018 16:51
To: 5GANGIP <[email-masked]>
Subject: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Hi all,

We have submitted the gaps draft. Those who have contributed text are listed as co-authors.
Please send your comments to the list.

Regards,
Dirk& Behcet

Name:           draft-xyzy-atick-gaps
Revision:       00
Title:          Gap and Solution Space Analysis for End to End Privacy Enabled Mapping System
Document date:  2018-05-25
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/
Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps

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

The IETF Secretariat

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 28 May 2018 17:16:42 +0000

There is some text which is incorrect - on page 4:

----
   Furthermore, ILNP demands a change in the way local (e.g., within a
   LAN) communication is carried out, needing all of the devices to
   support ILNP.  This in turn may raise heavy deployability issues.
----

This is not true - "all devices" do *not* need to be updated, but only those end-systems that wish to use ILNPv6. Switches and routers do not need to be updated, as ILNPv6 is backwards compatible with IPv6. It is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.

Cheers,
--/Saleem

On 25 May 2018, at 15:50, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Regards,
Dirk& Behcet

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

The IETF Secretariat

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

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 29 May 2018 10:32:33 +0200

Hi,

> On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked]> wrote:
> 
> This is not true - "all devices" do *not* need to be updated, but only those end-systems that wish to use ILNPv6. Switches

Switches clearly do not need to be changed since they are L2. 

> and routers

You need to implement the ILCC in your first hop router. 

Then you need new ICMP messages, and few other tricks here and there in existing stuff.
Other solutions are more clear because introduce new entities and protocol, so either you have it or you don’t.

Yet, may be the last sentence can be soften deleting  “heavy”.

Ciao

L.

> do not need to be updated, as ILNPv6 is backwards compatible with IPv6. It is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.
> 
> Cheers,
> --/Saleem
> 
> 
>> On 25 May 2018, at 15:50, Behcet Sarikaya <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt <https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/ <https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/>
>> Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00 <https://tools.ietf.org/html/draft-xyzy-atick-gaps-00>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps <https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps>
>> 
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 29 May 2018 10:03:21 +0000

Hello Luigi;

Thanks for your comments - my responses are inline, below.

On 29 May 2018, at 09:32, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

----

Agreed.

However, the text clearly says "all of the devices", which is incorrect.

and routers

No, that is not required. I have a testbed at St Andrews and we run Linux routers that are not modified, and are not ILNP-aware. For example, please see the testbed experiment described in this paper:

  IP without IP addresses
  https://dl.acm.org/citation.cfm?doid=3012695.3012701

The new ICMP messages, e.g. Locator Updates for ILNPv6, RFC6743, are end-to-end - only the end hosts needs to be updated to generate these messages.

If any on-path routers wish to examine such messages, then yes, they would need to be updated, but that is not required for ILNPv6 to work.

All new solutions will incur some sort of deployment overhead, so I am not sure why such a comment should apply specifically and only to ILNP.

For ILNP the basic deployment requires end-systems to be updated. Such updates would be deployed through over-the-air updates, as is common today with many operating systems. DNS entries for ILNP nodes would also be needed, and the new DNS RRs for ILNP (RFC6742) are supported commercially (e.g. by BIND, NSD, and KnotDNS, and possibly others).

For other solutions, other deployment issues exist, e.g. for ILA and LISP, new network entities/functions need to be deployed and managed for routing, and so, I guess, the existing network will need to be reconfigured to integrate the new functionality. I am guessing some operators may find that a "heavy" deployment burden, but it is best that those operators comment on whether or not they see that is a problem, as I have no experience with running large networks.

Cheers,
--/Saleem

Ciao

L.

Cheers,
--/Saleem

Hi all,

Regards,
Dirk& Behcet

Abstract:

The IETF Secretariat

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 29 May 2018 14:25:08 +0200

Hi Saleem,

> On 29 May 2018, at 12:03, Saleem Bhatti <[email-masked]> wrote:
> 
> Hello Luigi;
> 
>> On 29 May 2018, at 09:32, Luigi Iannone <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> 
>>> On 28 May 2018, at 19:16, Saleem Bhatti <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

Agreed.

>   https://dl.acm.org/citation.cfm?doid=3012695.3012701 <https://dl.acm.org/citation.cfm?doid=3012695.3012701>
Thanks for the pointer. :-)

> If any on-path routers wish to examine such messages, then yes, they would need to be updated, but that is not required for ILNPv6 to work.

Ack.

> For other solutions, other deployment issues exist, e.g. for ILA and LISP, new network entities/functions need to be deployed and managed for routing, and so, I guess, the existing network will nee…

Updating end-systems is IMHO a real nightmare. You have no control on who will update and when. Network history is full of such examples.
Yes, ILA and LISP has to be deployed by operators, but they can have full control of what will happen in their own network (which they usually like).
YMMV.

In general, I may agree that deployment considerations for all of the considered solutions can be improved and corrected.

Thanks

L.

>>>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
>>> 
>>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 29 May 2018 13:20:11 +0000

Luigi;

On 29 May 2018, at 13:25, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:

Hi Saleem,

On 29 May 2018, at 12:03, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

Hello Luigi;

Hi,

 [ ... ]

Updating end-systems is IMHO a real nightmare.
You have no control on who will update and when. Network history is full of such examples.

I agree deployment can be troublesome - deployment issues, in general, especially with heterogenous systems, can cause difficulty.

However, enterprise-wide solutions to such things exists today, and work successfully. For example, thinking about my own workplace (a university campus), hundreds (even thousands) of devices can be update in a coordinated manner using centrally-controlled management systems, for Windows and Linux. For individual users, yes, that is up to them, but for Linux/Mac/Windows/Android/IOS (at least) there are the various notifications to pester users to upgrade. :-)

ILNP would allow incremental upgrades for a site, as only those nodes that need to use ILNP need to be updated.

Agreed.

However, that does not mean that the deployment will be easy, quick, or trouble-free, just that they (should) have administrative control. As I wrote previously, comments from an operator would be useful here, rather than an ungrounded opinion from me.

Agreed.

Cheers,
--/Saleem

Thanks

L.

Cheers,
--/Saleem

Ciao

L.

Cheers,
--/Saleem

Hi all,

Regards,
Dirk& Behcet

Abstract:

The IETF Secretariat

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 May 2018 09:20:10 -0500

Luigi, Saleem,

What is the agreement now as to the revision of the draft?

I had already added some text regarding UE being alone on the link, i.e.
point-to-point link in wireless networks, that should make both sides happy?

Regards,
Behcet

On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[email-masked]> wrote:

> On 29 May 2018, at 09:32, Luigi Iannone <[email-masked]> wrote:
>
> Hi,
>
>
> This is not true - "all devices" do *not* need to be updated, but only
> those end-systems that wish to use ILNPv6. Switches
>
>
> No, that is not required. I have a testbed at St Andrews and we run Linux
> routers that are not modified, and are not ILNP-aware. For example, please
> see the testbed experiment described in this paper:
>
>   IP without IP addresses
> The new ICMP messages, e.g. Locator Updates for ILNPv6, RFC6743, are
> end-to-end - only the end hosts needs to be updated to generate these
> messages.
>
> If any on-path routers wish to examine such messages, then yes, they would
> need to be updated, but that is not required for ILNPv6 to work.
>
>
> Ack.
>
>
> Other solutions are more clear because introduce new entities and
> protocol, so either you have it or you don’t.
>
>
> All new solutions will incur some sort of deployment overhead, so I am not
> sure why such a comment should apply specifically and only to ILNP.
>
> For ILNP the basic deployment requires end-systems to be updated. Such
> updates would be deployed through over-the-air updates, as is common today
> with many operating systems. DNS entries for ILNP nodes would also be
> needed, and the new DNS RRs for ILNP (RFC6742) are supported commercially
> (e.g. by BIND, NSD, and KnotDNS, and possibly others).
>
> For other solutions, other deployment issues exist, e.g. for ILA and LISP,
> new network entities/functions need to be deployed and managed for routing,
> and so, I guess, the existing network will need to be reconfigured to
> integrate the new functionality. I am guessing some operators may find that
> a "heavy" deployment burden, but it is best that those operators comment on
> whether or not they see that is a problem, as I have no experience with
> running large networks.
>
>
> Updating end-systems is IMHO a real nightmare. You have no control on who
> will update and when. Network history is full of such examples.
> Yes, ILA and LISP has to be deployed by operators, but they can have full
> control of what will happen in their own network (which they usually like).
> YMMV.
>
> In general, I may agree that deployment considerations for all of the
> considered solutions can be improved and corrected.
>
> Thanks
>
> L.
>
>
>
>
>
> Cheers,
> --/Saleem
>
>
> Ciao
>
> L.
>
>
> do not need to be updated, as ILNPv6 is backwards compatible with IPv6. It
> is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.
>
> Cheers,
> --/Saleem
>
>
> On 25 May 2018, at 15:50, Behcet Sarikaya <[email-masked]> wrote:
>
> Hi all,
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 May 2018 08:44:50 -0700

Behcet,

The statement "For ILNP the basic deployment requires end-systems to
be updated." is unscoped. As written, this would imply that all hosts
on the Internet need to be updated to support ILNP. That is simply a
non-starter. If the idea is that ILNP can be deployed by networks then
hosts within that network can be updated. But, then the question
becomes how ILNP hosts are going to be able to talk non ILNP hosts
(say servers on the Internet). For that the an ILNP gateway or proxy
also must be deployed in the network.

Tom

On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <[email-masked]> wrote:
>> (e.g. by BIND, NSD, and KnotDNS, and possibly others)..
>>
>> URL:
>> https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps
>>
>>
>> Abstract:

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 30 May 2018 16:12:06 +0000

Behcet;

On 30 May 2018, at 15:20, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Luigi, Saleem,

I had already added some text regarding UE being alone on the link, i.e. point-to-point link in wireless networks, that should make both sides happy?

The whole paragraph should be removed.

Cheers,
--/Saleem

Regards,
Behcet

On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[email-masked]<mailto:[email-masked]>> wrote:
Hi Saleem,

Hello Luigi;

Hi,

----

Agreed.

Agreed.

and routers

  IP without IP addresses

Ack.

Thanks

L.

Cheers,
--/Saleem

Ciao

L.

Cheers,
--/Saleem

Hi all,

Regards,
Dirk& Behcet

Abstract:

The IETF Secretariat

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 30 May 2018 16:19:20 +0000

Tom;

> On 30 May 2018, at 16:44, Tom Herbert <[email-masked]> wrote:
> 
> Behcet,
> 
> non-starter.

Good catch - thanks.

> If the idea is that ILNP can be deployed by networks then
> hosts within that network can be updated.

Only those end-systems that need to use ILNP need to be updated. ILNP nodes can work in networks with non-ILNP nodes - see Section 10.4 of RFC6741.

> But, then the question

A gateway or proxy is not required.

ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6 when required - the process is described in Section 10.6 of RFC6741.

Cheers,
--/Saleem

---

From: David Allan I <[email-masked]>
Date: Wed, 30 May 2018 18:28:29 +0000

The only network upgrade for ILNP is DNS support for RFC 6742, which is believe is already deployed.

Cheers
Dave

-----Original Message-----
From: 5gangip <[email-masked]> On Behalf Of Saleem Bhatti
Sent: Wednesday, May 30, 2018 9:19 AM
To: Tom Herbert <[email-masked]>
Cc: Luigi Iannone <[email-masked]>; 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Tom;

Good catch - thanks.

> If the idea is that ILNP can be deployed by networks then hosts within 
> that network can be updated.

Cheers,
--/Saleem

>>> This is not true - "all devices" do *not* need to be updated, but 
>>> only those end-systems that wish to use ILNPv6. Switches
>>> 
>>> 
>>> No, that is not required. I have a testbed at St Andrews and we run 
>>> Linux routers that are not modified, and are not ILNP-aware. For 
>>> example, please see the testbed experiment described in this paper:
>>> 
>>>  IP without IP addresses
>>> end-to-end - only the end hosts needs to be updated to generate 
>>> these messages.
>>> 
>>> If any on-path routers wish to examine such messages, then yes, they 
>>> would need to be updated, but that is not required for ILNPv6 to work.
>>> 
>>> 
>>> Ack.
>>> 
>>> 
>>> All new solutions will incur some sort of deployment overhead, so I 
>>> am not sure why such a comment should apply specifically and only to ILNP.
>>> 
>>> For ILNP the basic deployment requires end-systems to be updated. 
>>> Such updates would be deployed through over-the-air updates, as is 
>>> common today with many operating systems. DNS entries for ILNP nodes 
>>> would also be needed, and the new DNS RRs for ILNP (RFC6742) are 
>>> supported commercially (e.g. by BIND, NSD, and KnotDNS, and possibly others)..
>>> 
>>> For other solutions, other deployment issues exist, e.g. for ILA and 
>>> LISP, new network entities/functions need to be deployed and managed 
>>> for routing, and so, I guess, the existing network will need to be 
>>> reconfigured to integrate the new functionality. I am guessing some 
>>> operators may find that a "heavy" deployment burden, but it is best 
>>> that those operators comment on whether or not they see that is a 
>>> problem, as I have no experience with running large networks.
>>> 
>>> 
>>> Updating end-systems is IMHO a real nightmare. You have no control 
>>> on who will update and when. Network history is full of such examples.
>>> Yes, ILA and LISP has to be deployed by operators, but they can have 
>>> full control of what will happen in their own network (which they usually like).
>>> YMMV.
>>> 
>>> In general, I may agree that deployment considerations for all of 
>>> the considered solutions can be improved and corrected.
>>> 
>>> Thanks
>>> 
>>> L.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Cheers,
>>> --/Saleem
>>> 
>>> 
>>> Ciao
>>> 
>>> L.
>>> 
>>> 
>>> do not need to be updated, as ILNPv6 is backwards compatible with 
>>> IPv6. It is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.
>>> 
>>> Cheers,
>>> --/Saleem
>>> 
>>> 
>>> A new version of I-D, draft-xyzy-atick-gaps-00.txt has been 
>>> successfully submitted by Behcet Sarikaya and posted to the IETF 
>>> repository.
>>> 
>>> 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: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 May 2018 13:35:51 -0500

> believe is already deployed.
I am not sure about deployed but maybe defined is better.
However, DNS is not privacy enabled which is our main issue here.

Regards,
Behcet

> Only those end-systems that need to use ILNP need to be updated. ILNP
> nodes can work in networks with non-ILNP nodes - see Section 10.4 of
> RFC6741.
>
>
> > But, then the question
> ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6 when
> required - the process is described in Section 10.6 of RFC6741.
>
> Cheers,
> --/Saleem
>
>
> >
> > Tom
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 May 2018 13:36:29 -0500

> required - the process is described in Section 10.6 of RFC6741.
So then it is no longer ILNP.

Regards,
Behcet

> Linux
> would
> LISP,
> full
> IPv6. It
> >>> submission

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 30 May 2018 18:48:39 +0000

Behcet;

On 30 May 2018, at 19:35, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 30, 2018 at 1:28 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
The only network upgrade for ILNP is DNS support for RFC 6742, which is believe is already deployed.

If you are running the most recent version of BIND, KnotDNS, or NSD, then they support RFC6742 out-of-the-box, as far as I know.

Cheers,
--/Saleem

Regards,
Behcet
Cheers
Dave

-----Original Message-----
From: 5gangip <[email-masked]<mailto:[email-masked]>> On Behalf Of Saleem Bhatti
Sent: Wednesday, May 30, 2018 9:19 AM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: Luigi Iannone <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>; Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Tom;

> On 30 May 2018, at 16:44, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>
> Behcet,
>

Good catch - thanks.

Cheers,
--/Saleem

>
> Tom
>
> On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
>> Luigi, Saleem,
>>
>>> tools.ietf.org<http://tools.ietf.org/>.
>>>
>>> The IETF Secretariat
>>>
>>>

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 30 May 2018 18:52:25 +0000

Behcet;

On 30 May 2018, at 19:36, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:
Tom;

Good catch - thanks.

To talk to an IPv6 host that does not talk ILNPv6, the easiest method is to talk IPv6.

Cheers,
--/Saleem

Regards,
Behcet
Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 May 2018 12:01:54 -0700

On Wed, May 30, 2018 at 11:48 AM, Saleem Bhatti <[email-masked]> wrote:
> Behcet;
>
> On 30 May 2018, at 19:35, Behcet Sarikaya <[email-masked]> wrote:
>
>
>
> If you are running the most recent version of BIND, KnotDNS, or NSD, then
> they support RFC6742 out-of-the-box, as far as I know.
>
The more relevant question would be which host OSes support ILNP.

Tom

>> >>> Status:
>> >>> https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 30 May 2018 19:08:25 +0000

> On 30 May 2018, at 20:01, Tom Herbert <[email-masked]> wrote:
> 

Currently, probably about the same number as the networks that support ILA ;-)

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 May 2018 12:23:50 -0700

> Currently, probably about the same number as the networks that support ILA ;-)
Saleem,

I'm not sure how to interpret your response. ILA has been in upstream
for a while and is begin deployed. I know that ILNP is not in Linux,
but I don't know about other OSes.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 May 2018 12:38:00 -0700

And its irrelevant for LISP, because it can run in user-space.

Dino

> On May 30, 2018, at 12:08 PM, Saleem Bhatti <[email-masked]> wrote:
> 
> 
>

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 30 May 2018 19:40:50 +0000

Tom;

> On 30 May 2018, at 20:23, Tom Herbert <[email-masked]> wrote:
> 

Apologies - please excuse my flippant response. 

(I believe we may have had some version of this discussion before on the list.)

I have a Linux testbed at St Andrews, code written mainly by PhD students, Linux kernel version 3.9 - an old kernel, no longer supported. I have students working on porting the code to a newer kernel (version 4.x, hopefully 4.9 or 4.14).

The code is not yet in the upstream Linux repositories. As the ILNPv6 code makes changes to the main/core kernel code, it will take a while for this to make its way into the upstream code - it is harder to get changes in to the core kernel than to be added to the repo as a module.

I do not know of ILNP code existing in any other OSs.

Cheers,
--/Saleem

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 May 2018 16:48:23 -0500

Again trimming the cc list.

On Wed, May 30, 2018 at 1:52 PM, Saleem Bhatti <[email-masked]>
wrote:

> Behcet;
>
> On 30 May 2018, at 19:36, Behcet Sarikaya <[email-masked]> wrote:
>
>
>
Maybe a better reply is this feature could be added to ILNP.

>> >>> Then you need new ICMP messages, and few other tricks here and there
>> in
>> >>> existing stuff.
>> >>>
>> >>>
>> am not

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 May 2018 16:51:30 -0500

Hi Dino,

In this group we love all Id-Loc protocols, we strive for them to get
better and hopefully one day that will pay off.

Behcet

On Wed, May 30, 2018 at 2:38 PM, Dino Farinacci <[email-masked]> wrote:

> >>>> The only network upgrade for ILNP is DNS support for RFC 6742, which
> is
> >>>> believe is already deployed.
> >>>>
> >>>
> >>>>>> point-to-point link in wireless networks, that should make both
> sides
> >>>>>> happy?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Behcet
> >>>>>>
> >>>>>>> in existing stuff.
> >>>>>>> am not sure why such a comment should apply specifically and only
> to
> >>>>>>> ILNP.
> >>>>>>>
> >>>>>>> supported commercially (e.g. by BIND, NSD, and KnotDNS, and
> possibly
> >>>>>>> others)..
> >>>>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 30 May 2018 15:12:10 -0700

The reason I sent the note was because there was a comparison between ILA and ILNP. So I threw LISP in for completeness.

Dino

> On May 30, 2018, at 2:51 PM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi Dino,
> 
> In this group we love all Id-Loc protocols, we strive for them to get better and hopefully one day that will pay off.
> 
> Behcet
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 May 2018 15:31:08 -0700

> The reason I sent the note was because there was a comparison between ILA and ILNP. So I threw LISP in for completeness.
ILA can run either in kernel or in userspace (over something like
VPP). In the case that ILA is run on an end host there are distinct
performance advantages being in the kernel since the whole data path
can be integrated.

Tom