Subject: Re: [rrg] Proposal for recommendation language

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Apr 2010 11:31:01 -0400 (EDT)

> From: Tony Li <[email-masked]>

    > I promised to draft some text including some rationale for the
    > recommendation. I'm attaching a first draft here.
    > ...
    >    On behalf of the routing research group

Someone pointed this phrasing out to me (I hadn't noticed it), and I really
don't like it. If nothing else, it can sound patronizing, like the rest of us
are a bunch of small kids, and the grown-ups are acting on our behalf.

Look, you and Lixia didn't wind up as co-chairs because you're 2 times
smarter than the rest of us, you wound up as co-chairs because, well, I'm not
sure how, but not because you're more likely to have the correct answer.

I understand that the rules of the RRG mean you get to put whatever you want
in the document, but this entire recommendation section needs to avoid _any_
suggestion that it's _anything but_ the opinion of the two people who
happened to wind up as co-chairs. It's certainly not on _my_ behalf.

	Noel

---

From: Tony Li <[email-masked]>
Date: Thu, 22 Apr 2010 08:35:49 -0700

Noel,

I've compromised on this wording.  Please see the next version, as soon as I
can get to it.

We ended up as co-chairs because we were the ones who kept complaining to
the IAB that we needed to do something.  The squeaky wheel, and all that...

Tony

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Apr 2010 09:16:31 -0700

> the IAB that we needed to do something.  The squeaky wheel, and all that...

	Actually, no. 

	I don't know how you and Lixia wound up as chairs (I
	wasn't privy to any of that) but the reason the IAB did
	something wes because I personally pushed for them to do
	so when I was on the IAB.  Here's where I proposed the
	IAB do something about the Routing and Addressing issues
	facing us, which led to the to the current RRG activity:

	http://www.1-4-5.net/~dmm/IETF/IETF65/raws

	Please don't revise history.

	Dave

---

From: Tony Li <[email-masked]>
Date: Thu, 22 Apr 2010 09:27:36 -0700

> Please don't revise history.

I'm not, Dave.  You were certainly the one who pushed and drove for RAWS.
No question there and all credit to you for that.  That sparked the work
item within RRG.  Then they looked for a researcher and a developer who
could drive the group.  I assume that my name came up because I had been
banging the gong since ROAD & CIDR.

Regards,
Tony

---

From: David Meyer <[email-masked]>
Date: Thu, 22 Apr 2010 09:31:22 -0700

> banging the gong since ROAD & CIDR.

	Fair enough. As I said I wasn't privy (and am not) to
	any of how the IRTF works.

	Dave

---

From: Robin Whittle <[email-masked]>
Date: Fri, 23 Apr 2010 03:02:12 +1000

Hi Tony,

When revising your text, can you add something to indicate that ILNP
is not suitable for widespread adoption in IPv4?

Even if it was not constrained by the 32 bit address bits in terms of
the number of Locators and Identifiers it could provide, each
multihomed end-user network would chew at least 3 times its current
amount of global unicast space, as I wrote:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06473.html
  http://www.ietf.org/mail-archive/web/rrg/current/msg06489.html

Since the RRG's charter contains nothing which diminishes the
importance of solving the IPv4 scaling problem, in the absence of a
note about ILNP's unsuitability for IPv4, readers would get the
impression from your text that you think ILNP could contribute to the
solution of the IPv4 scaling problem.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Thu, 22 Apr 2010 13:52:08 -0700

Hi Robin,

> is not suitable for widespread adoption in IPv4?

This seems like this is more suitable for the section on the ILNP critique.
Perhaps you should collaborate with those authors?

Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 23 Apr 2010 13:22:27 +1000

Hi Tony,

Do you think ILNP can be widely enough deployed in the IPv4 Internet
to solve its scaling problem?  If so, how could this be true since a
dual-homed network would chew 3 times the amount of global unicast
space it actually uses?

I understand you don't care at all about solving the IPv4 scaling
problem (msg06192 2010-03-08), but most other people do.  Your and
Lixia's current text:

   We recommended ILNP because we find it to be a clean solution for
   the architecture.  It separates location from identity in a clear,
   straightforward way that is consistent with the remainder of the
   Internet architecture and makes both first-class citizens.  Unlike
   the many map-and-encap proposals, there are no complications due
   to tunneling, indirection, or semantics that shift over the
   lifetime of a packets delivery.

implies that there is a single "architecture".  Yet the IPv4 and IPv6
Internets have significant differences, whether these are
characterised as "architectural", "practical" or whatever.

Your "clean solution" and lack of mention of any complications would
lead readers to believe that ILNP is useful for solving the IPv4
scaling problem.  But it isn't.

> Perhaps you should collaborate with those authors?

In early January I wrote critiques of ILNP to the list and then tried
to collaborate with Joel.

On 7 and 8 January I corresponded extensively with Joel on what he
would put in the ILNP critique he was preparing, and which became the
critique in the current RRG draft report.  As far as I know, my
efforts did not result in any change to what he wrote.

In that correspondence I didn't mention that ILNP wouldn't be useful
for IPv4 because I considered this to be an obvious fact which was
not in dispute.

A problem with some of the critiques in the draft RRG report is that
they were written by people who were either part of the proposal
project, or who supported it.  This, and the 500 word limit, means
there's reason to believe these critiques may not mention all
concerns anyone has about the proposal.  I am not sure that Joel
previously indicated his support for ILNP, but today in (msg06526) he
wrote that he supports your recommendation - so I guess that means
that now, at least, he supports ILNP.

Below my signature are links to the 7 list messages in which I
mentioned the fundamental problem of ILNP - or CEE (Locator /
Identifier Separation) architectures in general not being suitable
for IPv4 due to their wastage of global unicast address space.

Ran (msg06487) asserts he has already answered this critique - but he
hasn't.

 - Robin

  http://www.ietf.org/mail-archive/web/rrg/current/msg05610.html
  2010-01-06   ILNP critique 4

                 Splitting the 32 bits into 16 bit sections for
                 Locator and Identifier obviously results in too few
                 of one, the other or both.

                 There are no details of how ILNP would work with
                 IPv4.

  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
  2010-01-01   CES & CEE are completely different (graphs)

                 ILNP is a CEE (Locator / Identifier Separation)
                 architecture.

                 "CEE can't be useful for IPv4, since multihoming a
                 /18 network would require a /18 of PI space from
                 one ISP and another /18 from another ISP.   So it
                 would at least double address consumption."  (This
                 should be "triple".)

  http://www.ietf.org/mail-archive/web/rrg/current/msg06125.html
  2010-02-25   Re: [rrg] Various misunderstandings - ILNP; CEE/CES;
               Loc/ID Sep. = "revolutionary"

                 "will never be practical as a routing scaling
                 solution for IPv4 because multihoming a network
                 with X IPv4 addresses requires X other IPv4
                 addresses for each of the two or more ISPs.

  http://www.ietf.org/mail-archive/web/rrg/current/msg06162.html
  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
  2010-03-04/08   Recommendation suggestion from RW/(v2)

                 "This doubling or more of each end-user network's
                 address requirements is one of the reasons CEE
                 architectures are impractical for IPv4."

  http://www.ietf.org/mail-archive/web/rrg/current/msg06250.html
  2010-03-11   Re: [rrg] Why won't supporters of Loc/ID Separation
               (CEE) argue their case? (Summary of differences)

                 "CEE architectures are only practical for IPv6, for
                 multiple reasons but always including the fact that
                 CEE requires each multihomed end-user network to use
                 at least twice the number of addresses (host
                 locators) from the global unicast address space.
                 Each of its ISPs needs to provide the number of
                 addresses the network needs.

  http://www.ietf.org/mail-archive/web/rrg/current/msg06473.html
  2010-04-20   ILNP cannot provide scalable routing benefits for IPv4

                 For each dual-homed end-user network with S global
                 unicast IP addresses, the system requires a total of
                 S*3 global unicast IP addresses:

                   S IP addresses for the hosts in the end-user
                     network

                   S IP addresses for the PA prefix from ISP-A

                   S IP addresses for the PA prefix from ISP-B

                This is impractical for widespread adoption, given
                the IPv4 address space shortage.

---

From: Ran Atkinson <[email-masked]>
Date: Fri, 23 Apr 2010 08:28:09 -0400

On 22  Apr 2010, at 23:22 , Robin Whittle wrote:
> If so, how could this be true since a

It is NOT true that a multi-homed host needs more than 1 prefix
with ILNP.  Please re-read the 2009 MILCOM paper for a detailed 
explanation of one possible way that a site can be multi-homed
with minimal consumption of global-scope locators/addresses.

If one deploys the approach in that paper, it actually permits
(at least in theory) some IPv4 address space to be reclaimed,
as compared with today's BGP multi-homing, because only exterior 
interfaces of site border routers need to have global-scope 
locators/addresses.

(In practice, the monetary value of already delegated IPv4 prefixes
is probably too high for most organisations to volunteer to 
return them, but that is an economics issue rather than a technical
issue.)

> for IPv4 because I considered this to be an obvious fact which was

Several of us have repeatedly tried to explain to you that the
above was not correct; we've tried both on-list and off-list.

(I had thought this was NOT a debating society.)

There is a difference between (A) one person disagreeing 
(or not understanding) part of a proposal and (B) the 
proposal actually having the issue that person claims.
This topic seems to be (A).

Yours,

Ran

---

From: Robin Whittle <[email-masked]>
Date: Fri, 23 Apr 2010 23:31:17 +1000

Hi Ran,

I will read the paper I think you are referring to:

http://www.cs.st-andrews.ac.uk/~saleem/papers/2009/milcom2009/milcom2009-abh2009.pdf

> above was not correct; we've tried both on-list and off-list.

No you haven't explained anything.  You just asserted without any
explanation.  You haven't supplied an explanation yet - but you have
pointed to a paper which apparently contains an explanation.

How would ILNP work with the 32 bits of IPv4 address split between
Locator and Identifier?  As far as I know, this is not documented
anywhere.

> (I had thought this was NOT a debating society.)

This is not a society, but if you want your ideas to be properly
understood and respected - and if you want to find out any
shortcomings they may have - then you will debate them patiently and
in detail with people who provide critiques.  Debate involves
arguments and evidence, not unsupported assertions and casting
aspersions on other people and their supposed lack of understanding.

> This topic seems to be (A).

I will respond after I have read the above paper and after you
explain how ILNP's Locator and Identifier bit fields are implemented
in IPv4  packets. They are 64 bits each in IPv6.

  - Robin

---

From: [email-masked]
Date: Fri, 23 Apr 2010 10:05:59 -0400

No one can do magic things, including ILNP. It is a waste of time continuing to debate that ILNP could do anything for solving the IPv4 scalability and depletion issue.
4 bytes are just 4 bytes; you cannot get more than that out of them.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Robin Whittle <[email-masked]>
An: RRG <[email-masked]>
Cc: Ran Atkinson <[email-masked]>
Verschickt: Fr., 23. Apr. 2010, 15:31
Thema: Re: [rrg] Proposal for recommendation language - ILNP & IPv4

Hi Ran,

  - Robin
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Ran Atkinson <[email-masked]>
Date: Fri, 23 Apr 2010 11:08:58 -0400

> Locator and Identifier?  As far as I know, this is not documented

See draft-rja-ilnp-dns, which makes clear that the 32-bits
is the Locator value (L32).  As we've discussed on this
list (both historically and recently) there are a variety
of ways that one can engineer the transport of an Identifier
(and a Nonce for that matter).

A more detailed explanation of ILNPv4 is in the peer-reviewed 
paper published in Telcommunications Systems.  

This is an IRTF Research Group.  Unlike the IETF, the IRTF 
expects that participants already know the RG topic very well,
and that participants WILL take the time to read the relevant 
research literature.  ILNP is VERY well documented in the
peer-reviewed research literature.  Most of those papers
are available online in PDF at well-known URLs.

When time permits, I intend another pass at updating the
various draft-rja-ilnp-* I-Ds.  (NB: Time I spend on this 
list is time not available to do such updates, and my paid 
job does not include any of this.)

> in detail with people who provide critiques.  

Wrong.  This is NOT a debating society.  It certainly is 
NOT incumbent upon anyone to debate anything with anyone.
RGs are not setup as debating forums.  

The way that one gets ideas properly reviewed, understood, 
and respected in the research world (and an IRTF RG by 
definition IS in the research world) is to publish papers 
in the peer-reviewed research literature.  We've done that 
with ILNP, and we have been doing that with ILNP since LONG 
before this RG was re-focused onto this topic.

Yours,

Ran

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 Apr 2010 12:57:26 +1000

Continuing from Ran's message "Re: [rrg] Proposal for recommendation
language - ILNP & IPv4".

Short version:   Ran indicates that ILNP for IPv4 will use separate
                 headers to convey the Identifier and other items
                 such as a nonce.  The IP header will contain 32
                 bit IP addresses which function as a Locator.

                 Details remain unclear - but are apparently
                 explained in a paper which is not freely available.

                 If this arrangement can be shown to work, then
                 my previous critique about each multihomed end-user
                 network which currently has N IP addresses for N
                 hosts requiring, in total, 3*N global unicast
                 addresses (N in ISP-A and N in ISP-B, plus N in
                 for its own IP addresses) does not apply.

                 This approach would be significantly different from
                 the IPv6 approach.  So whatever claims are made
                 about ILNP in IPv6 don't necessarily hold for its
                 application to IPv4.

                 If you accept making packets longer with an extra
                 header, and accept the need to upgrade the stacks
                 of all hosts, then many things become possible.

                 However, if ILNP is to work with ordinary
                 applications, then it seems that it is stuck with
                 a 32 bit limitation on Identifier.  (As best I can
                 guess how it might work.)

                 I suggest that if we are going to require stack
                 upgrades to all IPv4 hosts, then many other things
                 are open for consideration too.  I recall that
                 HIPv4 involves stack and I think application
                 upgrades.  How would ILNPv4 compare with HIPv4?

                 Ran, I understand you have read all the relevant
                 research literature, which includes Patrick
                 Frejborg's work on HIPv4.  Can you give an account
                 of the commonalities and differences between ILNP
                 for IPv4 and HIPv4?

Hi Ran,

> paper published in Telcommunications Systems.  

OK - this is:

   http://www.springerlink.com/content/83546636m483u377/

Please email me a copy of the paper.  I don't feel inclined to pay
$34 to read it.

I understand then that ILNPv4 involves attaching an extra header to
all packets at the sending host, and having this transported to the
destination host.  The full 32 bits of the existing IP header is used
as a "Locator" - so a single router on a single IP address can
therefore handle packets for any Identifier - and for any number of
hosts with different identifiers.

I assume you would use more than 32 bits for Identifier.  I will
assume 64 bits for this discussion.

This is completely different from the way Locator and Identifier are
placed in packets in ILNPv6.  The description you have given here is,
AFAIK, the best description to date in the RRG list.

If you can do this, which depends on the nature of your new header,
then it should work fine.  You are effectively creating a new address
space, new namespace or whatever you like to call it for host
Identifiers.  Then the existing IPv4 address space is used by the
border routers of ISPs or other networks.

To use this, hosts need new stacks.  Are you planning on this working
with existing applications?

This appears to be a significantly different arrangement to that of
ILNP for IPv6.  So whatever claims are made for ILNP for IPv6 would
need to be carefully re-evaluated in terms of however it is to be
implemented for IPv4.

> research literature.  

This is an unsupported assertion.  Where in the IRTF rules is this
stated?

You expect me to know how ILNP for IPv4 will work and you have
previously claimed that you have explained it to me before - but you
haven't.  You can't expect me or anyone else to read all the papers
listed at your site:

  http://ilnp.cs.st-andrews.ac.uk/

some of which go back to 2004, just to understand your proposal.
This is especially the case if the papers are not freely available.

It is reasonable to expect anyone interested in your proposal to read
the Internet Drafts, summaries etc. you post to the list.  People
can't be expected to keep up with every update to these, but I did
read your I-Ds at the start of the year and made a concerted attempt
to understand your proposal then.

> ILNP is VERY well documented in the

Please make the above mentioned paper available on your site, or
email it to anyone on the list who wants to read it.

> job does not include any of this.)

OK - I know it is hard to keep up documenting things, since the
proposal does develop and it is a lot of work discussing things on
the list, developing ideas, writing them up in a consistent manner etc.

> Wrong.  This is NOT a debating society.  

I wrote it is not a society.  I asserted that in order to have your
ideas understood and respected you need to engage in patient and
detailed debate, including making information about your proposal
freely available.  I stand by this assertion.  You have an
understanding of how ILNP will work for IPv4 but it seems no-one else
does.  If you explained it on the list, or in an I-D, we would all be
able to understand it without too much fuss.

> It certainly is

Sure - no-one is obligated to do so.  Its just that if you want your
proposal to be widely understood and respected, as far as I know,
there is no alternative to patient and detailed discussion and debate.

> RGs are not setup as debating forums.  

Yet they are forums in which debate frequently does occur.  You seem
to be avoiding debate and discussion - instead expecting people to
already understand what is in your mind and which may be documented
in some paper linked to from your site.

> before this RG was re-focused onto this topic.

Sure - and some important aspects of your proposal are not understood
by many RRG participants despite us going to some trouble to do so.

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 Apr 2010 21:27:03 +1000

Hi Ran,

  R. Atkinson, S. Bhatti, S. Hailes,
  ILNP: Mobility, Multi-Homing, Localised Addressing and Security
  Through Naming,
  Telecommunication Systems, vol. 42, no. 3-4 pp273-291.
  [Springer] Dec 2009. ISSN 1018-4864 print / 1572-9451 online.

It is over 13,000 words, which is fine by me - this is a complex
field.  Just don't give me a hard time in the future for writing in
detail about Ivip or anything else.

I haven't read this yet, but below my signature is the section which
appears to be relevant to ILNP for IPv4.

  - Robin

5.2 Retro-fitting IPv4: ILNPv4
------------------------------

ILNP could also be implemented as a set of modifications
for IPv4, giving ILNPv4. Here, the IPv4 addresses would
become the Locators and separate Identifiers would be carried
in a new IP option. As with the previously described
IPv6-centric approach, all of the transport-layer state would
be bound to the Identifiers and a new session mapping table
would be added to the IP layer in host implementations.
Similarly, one could optionally carry a nonce in an IPv4 option
to provide light-weight protection against off-path attacks.
Mobility and multi-homing would work as described
previously and would bring the same benefits. This would
provide many of the same architectural benefits as the IPv6-
oriented approach in ILNPv6. A possible realisation of a
ILNPv4 header is shown in Fig. 6.

If the IPv4 address field in the IPv4 header were reused
for ILNPv4, the current IPv4 address prefix would be used
as the Locator, and the host part of the IPv4 address would
be ignored. Again, this would mean that there is virtually no
impact on routing ILNPv4 packets through an existing IPv4
core.

For ILNPv4, ARP would need to be modified to use
the combination of the ILNPv4 Locator and the Identifier.
So, the edge router at the final hop, as well as dual-stack
IPv4/ILNPv4 hosts in the subnetwork, would need to know
when to send a normal IPv4 ARP and when to send a modified
ILNPv4 ARP. If the full 32-bits of the IPv4 address
were used for ILNPv4 Locator values, then the lifetime of
the IPv4 address space potentially could be prolonged. Of
course, there is the possibility of confusion here, with ambiguities
between a 32-bit value being a ILNPv4 locator or a
normal IPv4 address for a node interface.

Practical considerations (e.g. limited IPv4 option space,
routers that forward IPv4 packets with options via the slowpath)
reduce the value proposition of ILNPv4, compared
with ILNPv6. However, we feel that a proof of concept implementation
of ILNPv4 should be possible with approximately
the same effort as ILNPv6.

Fig. 6 ILNPv4 packet header with optional Nonce

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|IHL=12 |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |   Protocol    |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Locator                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Locator                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  OT=ILNPv4_ID |     OL=5      |       Padding=0x0000          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                    Source Identifier                          +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                  Destination Identifier                       +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OT=ILNPv4_NONCE|     OL=2      |    top 16 bits of nonce       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     lower 32 bits of nonce                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL: Internet Header Length OT: Option Type OL: Option Length

---

From: Ran Atkinson <[email-masked]>
Date: Sat, 24 Apr 2010 08:39:11 -0400

(The title is incorrect.  ILNP for IPv4 uses an IPv4 option.)

>                 about ILNP in IPv6 don't necessarily hold for its

The *architecture* is IDENTICAL.  The only thing that 
changed is where the bits get stuffed on the wire.

>                 guess how it might work.)

Not true.

> Please email me a copy of the paper.  

Unfortunately, Copyright Law (in Australia and elsewhere) means
that I can't legally do so.

> with existing applications?

Yes.  No application changes will be needed.

> You can't expect me or anyone else to read all the papers
> listed at your site:
> 

I precisely do expect that.

> to understand your proposal then.

You apparently didn't read draft-rja-ilnp-dns, 
which describes the L32 record used for ILNPv4.

> email it to anyone on the list who wants to read it.

You are suggesting that I break the law. 

> there is no alternative to patient and detailed discussion and debate.

I believe a majority of list understands ILNP well enough already.
Certainly the off-list queries about very minor specific details 
indicate that the folks sending those queries already understand 
ILNP well.  People attending RG meetings tell me they understand 
ILNP (whether or not they prefer it).  People in Anaheim were not
necessarily enthusiastic about the Co-Chair's decision, but there
were no complaints voiced about ILNP documentation or clarity in
Anaheim

You appear to be a statistical outlier in this regard.  Probably
not the only person, but certainly you aren't in the majority.

> Yet they are forums in which debate frequently does occur.  

This one sadly seems to have become one, thanks to your presence.  
Other RGs I've been involved with haven't been debating societies.

Ran

---

From: Robin Whittle <[email-masked]>
Date: Sun, 25 Apr 2010 01:44:43 +1000

Short version:   Ran doesn't like debate - and blames me for the
                 debates which occur on the RRG.  Apparently this
                 debate-ridden Research Group is a new experience
                 for him.

                 He expects people to understand ILNP by, in part
                 reading academic papers - such as one which for
                 many people is behind a paywall and which he
                 doesn't mention on the RRG list, and only references
                 once in a non-specific manner in one of his I-Ds.

                 He wants people to understand and accept his
                 ideas - but I don't recall him discussing,
                 critiquing or debating anyone else's architecture.

                 ILNP for IPv4 involves some very different
                 practical considerations for ILNP for IPv6 -
                 including the need to upgrade some or all DFZ and
                 other routers.  It also imposes a 28 byte overhead
                 on all packets.

                 As far as I know, Ran has never argued why the
                 extra host burdens, extra packets, longer packets
                 (ILNP for IPv4) and typically extra delays in

                 establishing communications for all hosts are
                 justified by avoiding the extra network
                 infrastructure of alternatives such as LISP, Ivip
                 and IRON-RANGER.

                 Nor has he compared ILNP for IPv4 with the somewhat
                 similar architecture hIPv4.

Hi Ran,

> (The title is incorrect.  ILNP for IPv4 uses an IPv4 option.)

Fixed.

You wrote (msg06540):

   Unlike the IETF, the IRTF expects that participants already know
   the RG topic very well, and that participants WILL take the time
   to read the relevant research literature.

So you will be aware of Patrick Frejborg's recent work on hIPv4.
This is not HIP.  (I mistakenly used upper-case H in previous
messages.)

How does ILNP for IPv4 compare with hIPv4?  Both involve using new
IPv4 header options to convey extra "Identifier" or extended address
bits to hosts with modified stacks.

> changed is where the bits get stuffed on the wire.

For a sufficiently rarefied definition of the boundary between
"architecture" and everything else, yes, the architecture is identical.

But relying on IPv4 header options has important practical consequences.

You acknowledge some consequences - the need for modified ARP in the
local network of all hosts.  You also acknowledge that routers -
including DFZ routers - may handle packets with IP options in the
"slow path", which is entirely prohibitive.

So it seems that to implement ILNP for IPv4 at all, there would have
to be upgrades to some or all DFZ routers, just to ensure that they
handled the packets with your new IP option via their normal FIB
paths.  You also need to upgrade the stacks of all hosts.  That's two
huge sets of obstacles to adoption.

ILNP for IPv4 would add a 28 byte overhead to every packet.  This
adds overhead in general and also reduces the maximum payload a
packet can handle.  The lack of such overheads or restrictions is one
of the good things about ILNP for IPv6.

As with ILNP for IPv6 and with other CEE (Locator / Identifier
Separation) architectures IPv6, hosts need to do more work than they
do today, including doing mapping lookups, which involves extra
packets and delays in establishing initial communications.

Where do you argue that this burden, for all hosts, is a worthwhile
price to pay for avoiding the additional network infrastructure such
as is required by Ivip, LISP or IRON-RANGER (CES architectures)?
These architectures involve no host alterations - and do not require
changes to all networks.

> Not true.

OK - now I read this part of the paper, I can see you keep the same
64 bit Identifier.

> that I can't legally do so.

OK.  However, you have known since before October last year how you
are contemplating implementing ILNP for IPv4.  In all that time, you
have failed to explain this on the list.  All you had to do is quote
the text I quoted, or write something similar - on the RRG list
and/or in one of the ILNP I-Ds.

> Yes.  No application changes will be needed.

OK, as with ILNP for IPv6.

> I precisely do expect that.

OK.  I stand corrected.  You do expect this.

I think your expectation is entirely unreasonable - especially since
at least one of these papers is behind a paywall (USD$34) for those
people who don't have company or university access to the journal.

> which describes the L32 record used for ILNPv4.

I read version 01 it in January when I spent most time discussing
ILNP.  That doesn't mention IPv4.  Version 02 (2010-02-08) does
mention this 32 bit Locator field.  However, there's no mention of
the packet format - so no way of understanding how ILNP would work
for IPv4 - unless of course I had happened to spend $34 on the
October 2009 paper, which I don't recall you mentioning on the list
until just now.

> You are suggesting that I break the law. 

You are expecting people to spend good money, as well as their
precious time, reading your material.

I am suggesting that you should make all the material any RRG person
needs to understand ILNP freely available.  If that paper is tied up
with copyright, then I suggest you write a separate document as an
I-D, a mailing list message or a document on your site:

> I believe a majority of list understands ILNP well enough already.

I think you are mistaken, but there's no way of proving either
position.  How many of them understood how you proposed to implement
ILNP for IPv4?

> ILNP (whether or not they prefer it).  

How can you be sure they understand it?  They may understand some of
what you wrote, or think they understand it - but actually not
understand it properly at all.  How do you know what they read?  They
may have read a subset of your material, but not something important
like the section I quoted - section 5.2 on pages 14 and 15 of a paper
which is listed on your site, and only referenced once, in an
entirely non-specific manner, in draft-rja-ilnp-intro-03.

> People in Anaheim were not

OK, but you went to a lot of effort on the list to complain about my
lack of understanding, while doing nothing to help me understand
something important about ILNP.  At any time since December, you
could have posted text such as I just quoted from your paper.  In the
end, all you did was loosely refer to a paper - and expect me to
chase it up.

> You appear to be a statistical outlier in this regard.  

Maybe I am fussier about my understanding than some other folks.

> Probably

It would be better if more RRG people went to the trouble I did to
understand and comment on all the proposals, including yours.  It
would be better if you critiqued other proposals.

> Other RGs I've been involved with haven't been debating societies.

I have never asserted the RRG is a society.  I do assert that it is a
forum for debate - and furthermore that this is essential to the
RRG's work.

So you don't like debate - and indeed you blame me for the
preponderance of debate which occurs on the RRG!

As far as I know, "debate" is the same thing as meaningful discussion
when there are more than one point of view.

You seem to want people to understand and accept your ideas without
debate or meaningful discussion.  I have never heard of such a
suggestion in any professional setting.

The Charter:

  http://www.irtf.org/charter?gtype=rg&group=rrg

includes:

     The RRG will have an open general discussion mailing list where
     any topic of interest to the routing research community can be
     discussed, and topics related to scalable routing architectures
     are particularly encouraged.

It seems you are intent on discussion without debate.  I regard that
as meaningless.

Furthermore, you only seem interested in discussing ILNP - though you
did make some constructive suggestions recently about what the RRG
might be able to achieve consensus on.

You want and expect other people to understand and ideally agree with
your ideas - other people who have their own proposals.  Yet you
don't bother to critique anyone else's proposal.

Can you identify any other RRG participants who share your preference
for discussion without debate?  Its my impression that most folks who
write to the list are keen to debate things.

  - Robin

---

From: Ran Atkinson <[email-masked]>
Date: Sat, 24 Apr 2010 12:13:05 -0400

Robin's notes about ILNP and about what 
I have said/not said/written/not written 
continue to be overwhelmingly inaccurate.

I've been asked not to respond to his notes, 
on the reasonable basis that nothing in
this thread is relevant to producing the 
RRG document.

Yours,

Ran

---

From: <[email-masked]>
Date: Sat, 24 Apr 2010 21:43:31 +0100

Ran,

who were you asked by? (I'm presuming not the chairs, otherwise you'd have mentioned them.)

L. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ran Atkinson
Sent: 24 April 2010 17:13
To: IRTF Routing RG
Subject: Re: [rrg] ILNP

Robin's notes about ILNP and about what I have said/not said/written/not written continue to be overwhelmingly inaccurate.

I've been asked not to respond to his notes, on the reasonable basis that nothing in this thread is relevant to producing the RRG document.

Yours,

Ran

---

From: Robin Whittle <[email-masked]>
Date: Sun, 25 Apr 2010 11:44:00 +1000

Short version:  Tony wanted comments on his and Lixia's draft
                recommendation.  I am commenting (AKA discussing,
                AKA debating) on some aspects of this, including
                the applicability of ILNP to IPv4 - which I argue
                needs to be mentioned explicitly since it has
                significant practical difficulties in addition to
                those which apply to ILNP for IPv6.

                Ran and Tony have not yet responded.

Hi Ran,

What are the advantages of ILNP for IPv4 over hIPv4?

They both involve host changes and sending extra information with
every packet.  If hIPv4 packets have a new IP header option, as you
propose for ILNP for IPv4, then both architectures will also require
upgrades to some, many or all DFZ and other routers.

Both architectures provide a larger (64 bit) Identifier space.  I
recall Patrick is considering alternatives to header options.  Could
you include the ILNP header and the rest of the packet within a UDP
header?  I think that would get around the need for a new header
option and so for the need to upgrade DFZ and other routers.

> continue to be overwhelmingly inaccurate.

This is an unsupported assertion.

You spent significant bandwidth accusing me of having deficient
understanding of ILNP and scalable routing in general - when you
could have used that bandwidth to explain to me and others how ILNP
would work for IPv4.  If you criticise people on the list they are
likely to defend themselves.

> this thread is relevant to producing the 

Ah - so there are other people who don't like debate.

I was trying to have a meaningful discussion (AKA debate) about your
proposal.  See:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06578.html

At first you refused to discuss your proposal - derided my lack of
understanding.  Now that I have a better understanding, you still
don't want to discuss your proposal.

I am happy to discuss/debate my proposal with anyone.  If I think
they don't understand it well, then I try to improve their
understanding.  Quite likely I will learn something about scalable
routing, about my own proposal, or about how to explain it better.

I argue that the question of ILNP's applicability to IPv4 is
something Tony and Lixia's recommendation needs to be explicit about.
 The current draft of the text:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06521.html

has nothing to alert the reader that ILNP is primarily designed for
IPv6, and that in the current header option proposal for IPv4 would
require upgrades to some, many or all DFZ routers before anyone could
use ILNP.

Tony's request regarding that draft was "Please comment." - which is
what I am doing.

  - Robin

---

From: <[email-masked]>
Date: Sun, 25 Apr 2010 11:32:07 +0100

Ran,

first, it's not breaking the law, but going against the copyright owner's wishes, should the copyright owner decide that your actions go against its wishes. As such, any action will be a civil dispute, rather than a criminal prosecution.

Second, you will find that typical Springer Verlag copyright transfer agreements include the sentences "An author may self-archive an author-created version of his/her article on his/her own website and or in his/her institutional repository." and "Prior versions of the article published on non-commercial pre-print servers like arXiV.org can remain on these servers and/or can be updated with the author's accepted version."

You can't share the final typseset Springer copy, which is their property, but you can share what you wrote prior to that, which is yours.

Or, what you have written on the law can best be described as "overwhelmingly inaccurate."

L.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ran Atkinson
Sent: 24 April 2010 13:39
To: IRTF Routing RG
Subject: Re: [rrg] ILNP for IPv4 uses extra header.

[..]
> Please email me a copy of the paper.  

Unfortunately, Copyright Law (in Australia and elsewhere) means that I can't legally do so.

[..]
> Please make the above mentioned paper available on your site, or email 
> it to anyone on the list who wants to read it.