Re: New I-D:draft-kaplan-enum-source-uri-00.txt

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

Otmar Lendl wrote:
> On 2007/12/12 16:12, Paul Erkkila <[email protected]> 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:

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

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

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 :) )


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

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.

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

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

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

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