Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

From: Otmar Lendl <[email-masked]>
Date: Wed, 2 Jan 2008 23:24:03 +0100

On 2007/12/12 16:12, Paul Erkkila <[email-masked]> wrote:
> Otmar Lendl wrote:
> >
> > 
> > Yes, the incremental change ist not that big. The question remains: 
> > 
> > Have we now reached the point where we should stop fiddling with the
> > DNS protocol and should instead look for a directory lookup protocol
> > which was designed from the beginning to support authenticated and
> > complex queries returning structured data?
> 
> LDAP?
> 

I've been mulling over this question during the holidays. I've come
to the following conclusion:

The DNS (as well as LDAP) is primarily designed as a directory service.
It is a protocol to query a database for records conforming to a
specific question. The intelligence on how to interpret the data and
what to do with this information (possibly combined with data learned
from other sources) is in the device which asked the query.

In terms of VoIP: the call routing algorithm runs inside the
soft-switch. ENUM is just one input into this algorithm.

What I see in various proposals here in the WG (starting with the
trunk-ID draft ) and most clearly from this draft is a different
approach to the overall architecture: The soft-switch should be dumb,
all call routing decisions are out-sourced to the ENUM DNS servers.
They do capacity planning, source-dependent routing and all the peering
logic. If you take this approach, then of course the soft-switch needs
to somehow communicate all the basics of that call to the ENUM DNS
server so that it can make the correct call routing decision.

Such "out-source the logic" approaches are not new. Network equipment
handling dial-up sessions or DSL logins have been doing that for years.
The protocol of choice for such applications has been RADIUS (perhaps
now supplanted by DIAMETER). RADIUS supports almost arbitrary key-value
pairs in the query: All the information the dumb switch has can thus
be easily packed into the query. The same holds for the answer: it can
instruct the soft-switch in detail what to do with the call.

---

Yes, of course it is possible to pack that on top of the DNS and build
tricky algorithms into the DNS response generation (Akamai and all the
DNS-based load-balancer vendors have been doing that for years), but
given the potentially large set of background information the server
needs in order to run its algorithm (which has to be included in the
query) plus the need to return a more complex answer than just a URI
make the DNS a bad choice for the query protocol.

LDAP is only a marginally better choice. It, too, is a "give me the
information you have which matches XYZ"-protocol and not a "I have a
customer request with these parameters, please tell me what to do"
kind of protocol. 

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

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

---

From: Paul Erkkila <[email-masked]>
Date: Fri, 04 Jan 2008 14:46:09 -0500

Some comments inline to add to the discussion but no real content :).

> to the following conclusion:

(Conclusion 1: That you need more hobbies ;) )

> soft-switch. ENUM is just one input into this algorithm.

I see what you are getting at here (at least I think I do). However I
think the term "soft-switch" is overloaded to the point where the
argument changes depending on the definition.

(If I have an edge device (proxy/other) that is capable of gathering
routing and policy information, and using that to make next hop
determination does that make it a soft-switch? Or does it have to be a
singleton entity for a particular network with state information? Not
really an argument for the ENUM group :) )

> server so that it can make the correct call routing decision.

I'm not confident this is exactly what is going on but it is certainly a
valid view of the data. One possibility is what we are seeing is the
natural bounce between the single "core" routing model and "edge only"
routing model, with a good dose of single vs multiple query and single
vs multiple route decision per network argument thrown in to confuse
things even more. Speaking from experience with a single query and for
the most part single routing view VoIP network there is no simple
answer, and the sweet spot will be different for every network, and
maybe even every different type of flow in that network.

This draft is useful in all of these cases when ENUM is used as on of
the inputs to the routing decision. It allows the entity doing the ENUM
query to be more specific with its query and hopefully get a more
specific answer, which should reduce the total amount of global
resources used to properly route a particular session.

> make the DNS a bad choice for the query protocol.

My gut feeling is that there has been a great benefit to communications
as a whole from the examples you've picked above even if they are doing
things outside of the original intent. (I have not fully digested the
comments from Olafur so I'm not sure how they would fit here). It is
possible adding these types of extensions to the DNS above the "holy
trinity" for a query would benefit other applications as well. Then
again it might crush the whole thing ;).

> customer request with these parameters, please tell me what to do"

My only input here is that some of the benefits (delegation/caching) of
DNS might be lost with transition to another protocol . In the case of
this draft though that might be OK. Since it is aimed at more or less
private interconnects there is already a configuration requirement for
the DNS servers and the appropriate roots to query.

This draft and surrounding discussion have certainly stimulated my
thinking about the current state of things as we work on replacements
for the pieces of the SS7 network(s). The draft is a step forward in
that direction if we assume the replacement will be based around ENUM.

-pee