Subject: [Ecrit] questions and comments on LUMP

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 30 Jul 2005 22:36:07 -0400

I gave LUMP a read; here are some thoughts and comments. I've not been 
following list discussion that closely so I apologize if much of this 
has been discussed.

There are really two separate parts to LUMP; one is a query protocol, 
and the other is a routing and distribution protocol. I had a hard time 
figuring out exactly how the latter aspect of lump worked. It would seem 
that many of the questions and issues around traditional routing 
algorithms would apply. Is the routing done by distance-vector 
approaches or link-state flooding? How is route aggregation done? How 
does the system deal with node failures? How are peering relationships 
established and maintained?

I also couldn't figure out if caching played a role here. Can a query be 
cached? How is the cache invalidated?

I would also be particularly worried about elements injecting fake 
information into the lump network. xmldsig provides a framework for 
authenticating the source of the data, but how does one make a 
reasonable decision around authorization? It would seem that the more 
loosely organized structure you have in mind for LUMP is at odds with 
the kind of authorization models you need.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Jul 2005 14:13:52 -0400

Thanks for your comments; some responses below.

> established and maintained?

I fully admit that this needs a much better discussion. It's not nearly 
as complicated as (say) BGP routing - think of the top-level 
distribution as OSPF flooding, if you want to use a routing analogy.

Node failures are fully transparent, with two levels of redundancy 
(cluster and flooding). Essentially, any first-level node is 
non-critical. You can have as many of those as you want. Analogy: DNS 
resolvers.

> cached? How is the cache invalidated?

Yes, queries are cached. Invalidation is done by replacement (top level) 
or timeout (anywhere else).

> the kind of authorization models you need.

There are two somewhat separate problems for bogus information: 
conflicting information (e.g., two entities claiming authority for the 
nj.us tree) and information for some part of the earth that doesn't 
actually exist yet in the database.

There are several possible solutions to the bogus database problem: 
signature from known-good sources and peering with known-good peer.

There's a clear trade-off here: At one end, you can have a strict 
hierarchy with a root (DNS-style), but this requires global political 
agreement about the root. The ENUM and ICANN history provide two related 
examples that such agreement is not an easy one. The other is a more 
peering-oriented model where neighbors can trust each other, possibly 
mediated by a commercial or not-for-profit entity that vets such 
information. (It would know who is authorized to sign for nj.us and a 
voice service provider trusts its LUMP "service provider". It could be 
an organization such as NENA in the US.)

I don't know which model will turn out to be more deployable and this 
may well change over time, so I want to be able to support both without 
re-starting protocol design. Since these involve very different business 
models, I'd rather not get into a design that only allows one such 
business model.