Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Jun 2007 09:37:51 +0200

Hi Eliot,

I guess the RAM list is the place for this. I really only
have two comments at the moment.

 > 3.1.  NERD Record Format

I don't think it's OK only to document the IPv4 format.
By the time any of this becomes reality we'll be in real need of
IPv6 support. It's much better to design it in now, and include
it in the calculations.

I think it "only" doubles your EID and RLOC sizes - 64 bits should
do fine; even a /64 mask seems unlikely in practice.

 > 8.  Deployment Issues
 >
 >    While LISP and NERD are intended as experiments at this point, it is
 >    already obvious one must give serious consideration to circular
 >    dependencies with regard to the protocols used and the elements
 >    within them.

Indeed one must. I strongly suggest getting rid of your dependency
on DNS for NERD bootstrapping and update. I see no way to assert
with certainty that http://www.example.com/eiddb/ can be resolved without
any indirect dependency on LISP - whereas http://192.0.2.123/eiddb/
or http://[2001:DB8::1234]/eiddb/ could be, by assigning server addresses
that are in fact global RLOCs. Also, this way you remove any security
issues associated with DNS, and any confusion about IPv4 vs IPv6
connectivity to the servers.

Since the NERD sevrvers will be just as crucial to the network as
the DNS TLD servers, I don't see a strong argument against managing
their IP addresses in much the same way as the TLD servers'.

    Brian

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

IMCGDkbqUqNy2Hmm6jdROrPd4HgF4IDFjNZAMhR0rpdQe3Jtg7XPVIeVVtjmIOHbVLS8Er9/7orZ1Bhp56eQTi867WKaxO1E04wu+TNeVWm2hz+SK4+rMVUfR3eblslHUY=
Date: Fri, 15 Jun 2007 09:37:51 +0200
From: Brian E Carpenter <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-01.txt

Hi Eliot,

I guess the RAM list is the place for this. I really only
have two comments at the moment.

 > 3.1.  NERD Record Format

I don't think it's OK only to document the IPv4 format.
By the time any of this becomes reality we'll be in real need of
IPv6 support. It's much better to design it in now, and include
it in the calculations.

I think it "only" doubles your EID and RLOC sizes - 64 bits should
do fine; even a /64 mask seems unlikely in practice.

 > 8.  Deployment Issues
 >
 >    While LISP and NERD are intended as experiments at this point, it is
 >    already obvious one must give serious consideration to circular
 >    dependencies with regard to the protocols used and the elements
 >    within them.

Indeed one must. I strongly suggest getting rid of your dependency
on DNS for NERD bootstrapping and update. I see no way to assert
with certainty that http://www.example.com/eiddb/ can be resolved without
any indirect dependency on LISP - whereas http://192.0.2.123/eiddb/
or http://[2001:DB8::1234]/eiddb/ could be, by assigning server addresses
that are in fact global RLOCs. Also, this way you remove any security
issues associated with DNS, and any confusion about IPv4 vs IPv6
connectivity to the servers.

Since the NERD sevrvers will be just as crucial to the network as
the DNS TLD servers, I don't see a strong argument against managing
their IP addresses in much the same way as the TLD servers'.

    Brian

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Jun 2007 09:02:48 +0100

> IPv6 support. It's much better to design it in now, and include

Hmm... You'll note the AFI in the record format.  The analysis is IPv4, 
and it is worth mentioning how IPv6 would impact it.  Your analysis 
below seems accurate.

> any indirect dependency on LISP

I would argue that name servers and NERD web servers involved should 
have globally routed addresses.  This resolves the interdependencies.  I 
see no reason, by the way, why everyone must use LISP ETRs and PI 
space.  If you are single homed, what's the benefit?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Jun 2007 10:32:09 +0200

> space.  If you are single homed, what's the benefit?

But how do you know that *all* the routes involved in DNS transactions,
including caching, and zone transfers, are working when the NERD has not
been fully updated? I don't see how you can prove that there is no
circularity.

     Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Jun 2007 11:07:51 +0100

> been fully updated? I don't see how you can prove that there is no

There is direct feedback if you get this wrong, and there is a known 
solution to getting it right.  Anytime you use LISP you will need to 
worry about circular dependencies, because in a sense we are simply 
recursing the routing.  That doesn't mean that the problem is 
insurmountable, but rather that one needs to apply some caution.  There 
is also a way for mission critical devices for LISP are going to create 
such a circular dependency: grab a copy of the NERD and see if your own 
address is listed.  Does this make the Internet more fragile?  I would 
argue only VERY marginally, and that the problem is bilateral in nature, 
meaning that one of the two communicating parties can step in to fix it.

Another approach to all of this would be to simply multicast the 
database as we do with OSPF today.  I see nothing wrong with such an 
approach in principle, but I have not considered the details.  That's 
more code to write, and it does not seem necessary as a starting point.

Eliot

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Jun 2007 13:02:44 +0200

On Wed, Jun 13, 2007 at 06:50:02PM -0400,
 [email-masked] <[email-masked]> wrote 
 a message of 97 lines which said:

> 	Title		: NERD: A Not-so-novel EID to RLOC Database
> 	Author(s)	: E. Lear

> First, the obvious concern is that XML is not known for efficiency
> of data transport.

This argument no longer holds if you use compression. The figures you
mention for compression are for the efficient binary format but, with
XML, you have have higher ratios and may be bring XML database size
down to the size of the binary one.

Also, there is no discussion of JSON? (RFC 4627)

> The other concern about XML is that version 1.0 of the specification
> is silent on the order of sibling elements.

This is not true. The specification uses the word "sequence" which is
very clear in mathematics and computer science. It implies order.

Also, in the context of security and cryptographic signature that you
mention, the specifications of XML Signature
(http://www.w3.org/TR/xmldsig-core/) and Canonical XML
(http://www.w3.org/TR/xml-c14n) contain everything you need to be sure
that the issue will not be a problem.

>  [13]  Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383,
>         December 1992.

> Several recent studies have outlined the risk of "routing explosion"
> in the current Internet: there are already more than 5000 networks
> announced in the NSFNET routing tables,

Indeed, the sky is falling :-)