Subject: Re: [rrg] Proposal for recommendation language

From: Ran Atkinson <[email-masked]>
Date: Tue, 20 Apr 2010 11:07:53 -0400

Earlier, Brian Carpenter wrote:
> I'm flattered to be cited, but I hope this doesn't convey the
> impression that the draft (now in the RFC queue) offers a
> solution. It's more of the nature of a problem statement and
> gap analysis. I think it would be helpful to state that, to
> avoid any false expectations.

(I'm one of the co-authors of this RFC-to-be.)

Brian is quite correct if he means that the document 
is neither a panacea nor a full solution for all situations.  

That noted, there are some places where the current document
describes practical methods that can be used today to ease site 
renumbering, along with some advice on avoiding known pitfalls.

Purely by way of example, IPsec VPNs can be configured
to use FQDNs with IKE, rather than using raw IP addresses.
I believe this has for many years been an IETF standards-track
capability. The DNS KX record (widely available in BIND 
for years now) can be used to locate the VPN gateway for a 
target domain.  Further, deployed support for Secure Dynamic
DNS Update is more widespread than commonly understood.[1]
So at least some of the documented methods to ease renumbering 
have worked well for years, within at least some operational
environments, but appear not to be widely known today in the 
operational world.[2]

Last, the document does offer some advice on how to move
towards a world where site renumbering would be easier.
This last might be the bit most relevant to future standards
work, as it might help avoid standardising approaches that
are known to impede site renumbering.

So I agree with the co-chairs that the document is relevant
to the recommendation, and I agree with Brian that it is
important to be clear in how/why that document is relevant.

Yours,

Ran

[1] Cricket Liu's DNS & BIND book, 5th Edition, reports that 
in some common configurations, Microsoft Windows Server silently 
enables dynamic DNS updates and uses them in conjunction with 
the DHCP server feature.  According to that credible report,
this works fine.  There are more recent reports of interoperability 
among the dynamic DNS implementations that support TSIG-GSS.

[2] I have a decade of personal operational experience with 
ISP-driven (i.e. not planned by the end site and without warning)
renumbering of end-sites where the VPNs automatically re-established 
themselves within a few RTTs of the renumbering of the VPN gateway 
device's public IP address.  This relied upon the IKE config
using the FQDN rather than the raw IP address.

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Apr 2010 13:51:19 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

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

I don't know if Robin's claim about ILNPv4 is correct or not, in part because
I was able to find very little about ILNPv4; for example, the "ILNP Concept
of Operations" contains no details of how ILNPv4 works. But I do think IPv4
support should be covered to some degree, beyond "ILNPv4 is fully backwards
compatible with IPv4", which is all that's said at the moment.

Which leads me to another thought: it would be good to see those proposals
which wound up being recommendations given a bit more space to explain how
they work, for those many readers who will not have time to read through all
the underlying documentation, and just want a quick high-level view.

For instance, the current ILNP Summary doesn't even take time to say something
like 'ILNP splits a 128-bit IPv6 address into 64-bit locator and identifier
fields' (perhaps because it spent most of its space budget listing benefits).

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 25 Apr 2010 20:44:52 -0400 (EDT)

> From: Paul Jakma <[email-masked]>

    > I'm not sure it's enough just to try several. That will catch
    > 'workability' problems, as you suggest, but it won't per se tell us
    > which solutions handle growth the best, will it?

Well, nothing will really, _absolutely_, tell you except full-size
deployment, neh? (As the electrial grid guys have found to their cost, on
several occasions...) Simulations, good engineering practices, etc all help,
but in the end...

    > it'd be really useful to model some of the different options against
    > each other. If that hasn't been done already? (I'm presuming not).

Ah, actually, it has. Here are the latest results from modelling of
aspects (mapping lookup time) of one
scheme:

  http://www.ietf.org/mail-archive/web/lisp/current/pdf1piLVmIlgK.pdf

and here is another paper which covers an earlier round of modelling (on
cache size, hit ratios, etc):

  http://inl.info.ucl.ac.be/system/files/Conext-2007-CRV-UCL-v2-Clean.pdf

I'm pretty sure there's been some ILNP modelling, but I don't recall for
sure; try looking on the ILNP page:

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

I don't see anything there which says 'modeling' in the title, but I didn't
have time to look at them all.

I don't know if any of the others have been modelled; I looked on the RRG
page:

  http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup

but I didn't see anything else likely looking.

    > Might there be some pretty rich seams here to mine for academic work?

Already happening... :-)

	Noel