Subject: Re: AW: AW: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt

From: Marian Durkovic <[email-masked]>
Date: Tue, 8 Jul 2003 08:41:42 +0200

> Jim Reid wrote:
> Indeed. But just because something is cheap doesn't necessarily mean
> it's the Right Thing To Do. It could mean that the real issue -- which
> seems to be provisioning in this case -- does not get addressed. Or
> else a quick+dirty solution imposes undesirable constraints on
> whatever is ultimately deployed.

Use of wildcards in ENUM is not a provisioning issue. If it was, I'd spend
a couple of minutes writing the script to generate the zone files instead 
of opening the topic here.

The approach of having one record per every PBX extension is perhaps usable in 
trials, but it does not scale. Our institutions typically have 3-digit
extensions, the larger ones 4-digit extensions. Having this in mind you can
easily find yourself in the situation, where e.g. 300 customers generate
as much as 1 million records. If there's 1 million records in top-level
domain, you have 1 milion customers to cover the costs. But what will be the
cost per customer, if the number of customers is 300 ?

The approach with wildcards generates only 300 records per 300 customers.
This is huge difference certainly worth inverstigating. 

> Patrik Faltstrom wrote:
> The only place they are used is when the MX record refer to a gateway
> (to X.400 or UUCP) where the other side of the gateway is managing a
> number of (sub-) domains, and it is impossible to point all these
> domains in DNS with individual MX records to the media gateway.

You hit the nail. We need to do similar thing - redirect all voice traffic
to a VoIP gateway connected to PBX with many many extensions.
 
> Michael Haberler wrote:
> Or do you propose to have a wildcard in the zone, and have the server
> interpret it differently - i.e giving a matching non-wildcard response?

This is how wildcards work _now_ with standard DNS - they are internal to 
the host running the DNS daemon. The end-user's resolver has no way to tell,
if the response is based on wildcard or exact record, since the response 
is formulated as exact match in both cases. We can certaintly improve
the default wildcard behaviour with more sophisticated record synthesizing,
in order to get rid of common problems with classic wildcards, but I think
we really need the capability for one-to-many conversion in ENUM DNS.

I'd take BGP as an example. In early BGP3 stages, every C-class network has
to be announced via BGP. Due to scaling issues, BGP4 has to be introduced,
which enabled route aggregation. The ENUM problem is perhaps not that
urgent, since ENUM zones are not dumped to every backbone router, but the
basic principle is the same - the need for some form of aggregation is here
now, and I think we can't close our eyes.

	With kind regards,

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail: [email-masked]        ----
----                                                                  ----
--------------------------------------------------------------------------

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Marian Durkovic <[email-masked]>
Date: Tue, 8 Jul 2003 15:20:00 +0200

On Tue, Jul 08, 2003 at 10:58:46AM +0200, Jaap Akkerhuis wrote:
> Most instances of this idea with customers with n-bit extensions
> PBX I'm familar with, are actually maintaining such a PBX themselves.
> If theu want top do ENUM, the obvious solution is to delegate to
> that customer. [snip] You can delegate to a nameserver which
> maintains that part of the name space for that particular PBX.
> There is no need to populate the toplevel with all the nitty gritty
> details of that PBX. 

Sure, those records would not appear in the toplevel, but at the ISP level,
since the customers either outsource the DNS to them or at least request
a backup DNS to be operated by the ISP.  

On Tue, Jul 08, 2003 at 02:08:02AM -0700, Jim Reid wrote:
> I don't understand the point you're trying to make here. You seem to
> be saying something "won't scale" for 300 names but somehow scales
> just fine for 1 million names. I'm confused. And you've still to
> explain why provisioning NAPTRs for each number -- something you said
> was trivial -- couldn't be done and why a wildcard RR was the only
> possible solution to the problem you're trying to solve.

No, I'm saying that 300 PBX customers might create as much 1 million records.
Operating DNS servers with millions of records is not a trivial task at
least not for commonly available DNS software and just this is IMHO a good
reason to look for alternatives which make more decent use of resources.

> Well this is a perfect example of why DNS wildcards provide the wrong
> answer to the wrong question. You're assuming that the only use of
> ENUM for some range of numbers would be to contact a VoIP gateway. This
> cannot be guaranteed. What happens when the owners of (some of) those
> numbers want additional NAPTRs for other services? 

I'm not saying everyone _should_ use wildcards for every possible
configuration. But plese don't do the opposite - i.e. don't tell me that
we _must not_ use them.

> What if they *don't*
> want to use this default VoIP gateway? Or can't use it. 

You might still point the wildcard towards e.g. SIP proxy server, which can
handle this more effectively (changes are visible immediately).

> with numbers that are not in service? Should applications which look
> these up be pointed at the VoIP gateway regardless? That's what you'd
> get with a wildcard. Maybe it would be better to get an NXDOMAIN
> response from the DNS. Which of course you can't get if there's a
> wildcard RR.

This can only introduce another point of failure. This would mean, that PBX
configuration and DNS configuration must be always in sync which is hard
to achieve. Better get the "No subscriber" from the PBX like with PSTN. 

> The same goes for numbers that are invalid because they
> don't have the correct number of digits. What if some of the active
> numbers must not be used for VoIP because they're bound to things like
> a fax machine or a modem? What if you need to introduce additional
> VoIP gateways for some or all of the numbers?

Again, you can point the wildcard towards e.g. SIP proxy and introduce much
more services.

> Sorry, you can't change the semantics of DNS wildcarding without a
> wholesale protocol rewrite. And somehow keeping backwards
> compatibility with the installed base. Please show how you intend to
> do this.

I don't. I was mentioning record synthesizing indepened of classic wildcards
and their problems.

>     Marian> but I think we really need the capability for one-to-many
>     Marian> conversion in ENUM DNS.
> 
> I've not seen any justification for this so far though I accept it
> might be useful. Perhaps you could provide some examples?

DID (Direct Inward Dial) is a standard telco service that the customers are
used to. Emulating it by enumerating all possible digit combinations could
be only considered as a workaround and is in many cases pure waste of 
resources. If the wildcards are no good, other solution has to be found.

	M.

---

From: Jim Reid <[email-masked]>
Date: Tue, 08 Jul 2003 02:08:02 -0700

>>>>> "Marian" == Marian Durkovic <[email-masked]> writes:

    Marian> The approach of having one record per every PBX extension
    Marian> is perhaps usable in trials, but it does not scale. Our
    Marian> institutions typically have 3-digit extensions, the larger
    Marian> ones 4-digit extensions. Having this in mind you can
    Marian> easily find yourself in the situation, where e.g. 300
    Marian> customers generate as much as 1 million records. If
    Marian> there's 1 million records in top-level domain, you have 1
    Marian> milion customers to cover the costs. But what will be the
    Marian> cost per customer, if the number of customers is 300 ?

I don't understand the point you're trying to make here. You seem to
be saying something "won't scale" for 300 names but somehow scales
just fine for 1 million names. I'm confused. And you've still to
explain why provisioning NAPTRs for each number -- something you said
was trivial -- couldn't be done and why a wildcard RR was the only
possible solution to the problem you're trying to solve. Despite what
you said earlier, this still looks to me that the wildcard has been
suggested as a kludge to work around a provisioning problem. And a
straightforward one at that.

    Marian> The approach with wildcards generates only 300 records per
    Marian> 300 customers.  This is huge difference certainly worth
    Marian> inverstigating.

It has even bigger implications which you don't seem to appreciate.
You've not given any convincing explanation why a wildcard RR is the
only solution and why alternatives are not viable. Please provide that
explanation. 

    >> Patrik Faltstrom wrote: The only place they are used is when
    >> the MX record refer to a gateway (to X.400 or UUCP) where the
    >> other side of the gateway is managing a number of (sub-)
    >> domains, and it is impossible to point all these domains in DNS
    >> with individual MX records to the media gateway.

    Marian> You hit the nail. We need to do similar thing - redirect
    Marian> all voice traffic to a VoIP gateway connected to PBX with
    Marian> many many extensions.

numbers want additional NAPTRs for other services? What if they *don't*
want to use this default VoIP gateway? Or can't use it. What happens
wildcard RR. The same goes for numbers that are invalid because they

BTW, what you're proposing is NOT similar to the scenario Patrik
outlined at all. You're talking about a known, well-defined, if large,
name space: a range of telephone numbers. It is possible to enumerate
all the domain names that exist there. In fact, it's trivial. In the
scenario Patrik explains the wildcard MX record covers a name space
that is not known and cannot be enumerated because it is somewhat
unstructured and dynamic.

    >> Michael Haberler wrote: Or do you propose to have a wildcard in
    >> the zone, and have the server interpret it differently - i.e
    >> giving a matching non-wildcard response?

    Marian> This is how wildcards work _now_ with standard DNS - they
    Marian> are internal to the host running the DNS daemon. The
    Marian> end-user's resolver has no way to tell, if the response is
    Marian> based on wildcard or exact record, since the response is
    Marian> formulated as exact match in both cases. We can certaintly
    Marian> improve the default wildcard behaviour with more
    Marian> sophisticated record synthesizing, in order to get rid of
    Marian> common problems with classic wildcards,

Sorry, you can't change the semantics of DNS wildcarding without a
wholesale protocol rewrite. And somehow keeping backwards
compatibility with the installed base. Please show how you intend to
do this. For bonus points, get the DNS WGs to adopt your proposal. :-)