Subject: RE: [Enum] draft-ietf-enum-operation-00.txt

From: "Pfautz, Penn L, NNAD" <[email-masked]>
Date: Fri, 21 Jul 2000 12:43:22 -0400

Just to clarify, changes to the LNP SMS are supposed to be reflected in
carrier networks within 15 minutes of activation.

Penn Pfautz

-----Original Message-----
From: Hong Liu [mailto:[email-masked]]
Sent: Thursday, July 20, 2000 9:45 PM
To: Patrik Fältström
Cc: [email-masked]
Subject: Re: [Enum] draft-ietf-enum-operation-00.txt

Patrik,

I generally agree with your comments. There are two factors that affect the
propagation of changes in DNS:
(1) Caching delay, as determined by the TTL of individual NAPTR RR;
(2) Zone update delay, as determined by the REFRESH timer of the SOA RR of
the
zone if NOTIFY is not used.
As you pointed out, setting TTL close to 0 may cause strained behaviors on
the
DNS system. In your document draft-ietf-enum-e164-dns-02.txt (Section 5),
you
also mentioned that TTL should be kept minimum. Since we are discussing
operational guidelines here, do you or other DNS experts in IETF have any
recommendation as to what constitutes minimum TTL in the context of ENUM? I
think that will really help to move this document forward.

I have some additional comments below.

Patrik Fältström wrote:

> At 10.35 -0400 00-07-20, Manfredi, Albert E wrote:
> >I'd like this settled, myself. I've seen claims on this list that DNS can
> >now be updated in seconds, including master and slave servers. True?
False?
>
> Updated in seconds IFF all servers:
>
> - Can handle the extension NOTIFY
> - Have enough spare CPU-cycles to actually request a zonetransfer within
>    a short time span after a NOTIFY arrives
> - Have enough I/O to transfer and handle the zone itself (or can handle
>    IXFR for incremental updates) within the timespan
>
> Most servers can handle all of the above.
>

Agree. Zone transfer delay can be minimize via NOTIFY and incremental
transfer
IF all name servers for a zone are configured to handle these two features.
As
operational guidelines, shall we recommend that all ENUM servers should use
NOTIFY and IXFR for zone transfer?

>
> What is not true though is that we can set TTL to zero. That have
> some weird consequences which caching and the impact on the number of
> queries that are sent. Having TTL on an RR zero is not recommended at
> all. 15 minutes, ok, 15 seconds....hmmm....I would not have that.
>

Again, can we provide operational guideline here as to how minimum shall a
NAPTR
RR TTL be set for ENUM systems?

>
> So, I would say that 15 minute delay for updates are probably pretty
> ok, so for updates that need faster updates (propagation time is what
> I would like to call it) than 15 minutes should update the
> information somewhere else than in DNS.
>
> Personally, I feel that a redirect of a phonecall with 15 minute
> delay of propagation is normally quite ok. I.e. when I am at home and
> request the number at home to be redirected to my cellphone, it takes
> me more than 15 minutes to take on my shoes, jackets, forget the car
> keys, find them, find the cellphone, pick up my bag, leave the house
> and go to the car.
>
> I have no experience in what propagation time one have in the
> traditional phone system, but do know that the time is different
> depending on what operation you do. For example, when changing data
> within one IN system, the update is probably quite fast (modulo time
> for eventual mirroring internally in the database that the IN system
> uses) while porting a phone number between two telco's is probably
> slower (slower than 15 minutes).

I guess you and Greg were talking about slightly different things regarding
"fast" or "slow" updates in switches and IN databases. Loosely speaking, IN
databases, such as 800 or LNP databases, are called real time databases. The
update on a real time database is scheduled on a daily basis in batch mode
through the SMS based on a common reference database, where changes are made
continuously during the day. There is no real-time update from the
subscriber
directly, it is done by the operator via the SMS console. Once master copy
is
downloaded to the real time database, there is little delay in propagation
since
there is no caching mechanism in PSTN.

On the other hand, if you talk about the call forwarding feature, such as
redirect calls to your cell phone, is not slow either. Typically, call
forwarding is a switch-based feature. Once you activate the feature, the
forwarded number will be stored in the switch immediately after you hang up.
In
fact, some system will give you a confirmation before you hang up. Even if
the
feature is implemented in IN, the redirection will be effective right away,
though the activation duration may take longer since it involves signaling
between the switch and the SCP.

Now the question is: if someone wants to implement a service that needs
immediate update using ENUM, such as the call forwarding feature, what is
the
guideline for populating the NAPTR RR? From what you explained above, it
seems
that he/she needs to use ENUM as a redirect server to point to a server that
really handles the update in real time. In that case, the pointer is
constant,
and there is no update involved for ENUM.

However, porting a number to another provider is different since it usually
involved chaning the NAPTR RR to point to the new provider. In this case,
due to
caching, we may have to deal with inconsistent data for a short period of
time.
I guess this is what Greg was concerned about. Is that true, Greg?

Cheers,

--Hong

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

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 22 Jul 2000 13:43:46 -0700

>carrier networks within 15 minutes of activation.

Can you explain what "LNP SMS" is? If you have the time and energy, 
both when you talk about a traditional telephony network, one based 
on SIP and one based on H.323 (if there is a difference).

   paf

---

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 06:45:06 -0400

Patrik and Pfautz,

Though details may be a bit different, a more complete flow for porting a
number  is as follows:

(1) There is a lot of prep work that goes on between NPAC, the old (donor)
service provider, and the new (recipient) service provider before portingis
actually activated. At least they need to agree on a date and time for the
number to be ported.
(2) At the time of activation (let's say midnight today), the SMS sends a
message to NPAC, which then sends a message to all the effected LSMSs, which
then sends messages to the impacted Network Elements (SCPs that will be
handling the calls to the affected number).
(3) Once the update in SCPs are complete, the ported number is activated.
The maximum delay from the time that NPAC starts sending mesages (i.e.
midnight) is supposed to be 15 minutes.

Hence it is possible tha during those 15 minutes the old service provider
may have turned
off the service and the new service provider is not active yet.

If we are to provide comparable services on the IP network using ENUM, ENUM
may have to be subject to similar timing requirements for LNP updates. From
the discussion thus far, it seems that 15 minutes may be achieveable using
ENUM. It would be nice if DNS operations folks can provide some experimental
data to back this up.

Cheers,

--Hong

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Jul 2000 03:54:02 -0700

> it seems that 15 minutes may be achieveable using ENUM. It would be nice
> if DNS operations folks can provide some experimental data to back this
> up.

in the current environment, propagation of changed data in 15 minutes is a
very reasonable expectation.

but it would be nice (in the net.polite sense) if you used the knowledge to
pre-schedule you mention to not crank the ttl down until before it will be
needed.  i.e. use a long (e.g. an hour or four) ttl until the day before a
scheduled number port.

randy

---

From: Richard Shockey <[email-masked]>
Date: Sun, 23 Jul 2000 07:11:15 -0500

At 01:43 PM 7/22/2000 -0700, Patrik Fältström wrote:
>Can you explain what "LNP SMS" is? If you have the time and energy, both 
>when you talk about a traditional telephony network, one based on SIP and 
>one based on H.323 (if there is a difference).
>
>   paf

LNP SMS is the Local Number Portability Service Management System. The 
system NeuStar operates to propagate Ported Numbers to Service Control 
Points within the North American IN.

The Service Requirements for Number Portability means that the change of 
carrier should be reflected within the Telephone system within 15 min.

Please Note New Contact Information:

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Sun, 23 Jul 2000 07:22:15 -0500

>actually activated. At least they need to agree on a date and time for the

For those of you who need some translation...the NPAC is the Number 
Portability Administration Center operated by NeuStar Inc.

The function of the NPAC was mandated by order of the US FCC.

>ENUM. It would be nice if DNS operations folks can provide some experimental

I completely agree here ... though I have considerable confidence DNS can 
achieve these goals we will need some limited operational testing on this 
issue and what is the level of optimal cacheing necessary for  DNS servers 
at the IPTel network edge.

We are coming very very close to discussion of administrative delegation 
issues in e164.arpa.

It is a useful reminder that A. these issues are out of scope for the WG. 
B. we do need to talk about them.

Some of us are working very hard to come up with some proposals in this 
area ...

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 07:21:00 -0700

At 07.11 -0500 00-07-23, Richard Shockey wrote:
>LNP SMS is the Local Number Portability Service Management System. 
>The system NeuStar operates to propagate Ported Numbers to Service 
>Control Points within the North American IN.
>
>The Service Requirements for Number Portability means that the 
>change of carrier should be reflected within the Telephone system 
>within 15 min.

Ok, then we talk about the North America situation again.

We don't in this wg. This is a wg which has to specify how to do this 
in all over the world.

How you solve things in North America have to be (if needed) written 
in a specific paper.

Looking at specific examples is not a bad thing, but it can not drive 
how things should be done in ENUM operations in the world.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 07:15:44 -0700

>ENUM. It would be nice if DNS operations folks can provide some experimental

I claim based on personal experience that if you have a TTL which is 
5 minutes, and update your record on a master in a cluster of 
authoritative servers which all handle NOTIFY, that the update will 
be done within 15 minutes.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 07:13:31 -0700

>Though details may be a bit different, a more complete flow for porting a

In the US that is.

We can not make anything which is dependent on a terminology or 
process in one country.

What _can_ be created is "Enum operation in the countrycode 1", if we 
can not come up with more general descriptions.

Personally, I feel that Greg is writing general terms and conditions, 
and that is a good thing. We should continue to do that -- and then 
write specifics for each countrycode.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 07:18:23 -0700

>needed.  i.e. use a long (e.g. an hour or four) ttl until the day before a

Exactly. The normal way of changing things in DNS is:

- Use a long TTL, say "x"
- At time 3*x, turn down ttl to a short ttl, say "y"
- At some time, change content of the record
- Check after "y", 2*y and 3*y that things are ok
- Correct errors if needed
- Change TTL back to "x"

Normal values of x and y is 4-6 hours and 5 minutes (or shorter).

    paf

---

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 11:38:23 -0400

Patrik and Randy,

I really like the emails you both set out. It helped to clarify some concerns of
mine. I was told that it was what our DNS folks did when my company changed its
name from Bellcore to Telcordia. Your emails just confirmed that it is indeed a
common practice.

Cheers,

--Hong

---

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 11:56:07 -0400

Patrik,

You brought up a very good point. We should NOT constrain ourselves to
North America only in ENUM. I expanded on Penn's email just to clarify
what that "15 minutes" means so that others will not get the idea that
LSMS is updated continuously and every update has to be done within the
15 minute delay bound. It was NOT my intent to get ENUM into the North
America LNP solution. On the other hand, it was a good example to show
that there are timing requirements regarding telephone number updates in
PSTN. Other countries may have a different scheme that has different
timing requirements. I think it would be good that people from other
countries speak up. It would be nice if ENUM can satisfy most, if not
all, of them. That will make ENUM a true solution all over the world and
it will make interworking easier.

The discussion thus far reminds me a bit of what was going on when
SIGTRAN first started when people talked about transporting SS7 over IP.
Timing requirements from SS7 did play an important role to justify a new
protocol than TCP for that purpose. The bottom line: PSTN number
administration folks ("Bell Heads") and IETF ENUM folks ("Net Heads")
need to communicate since interworking is inevitable, unless you want to
restrict ENUM to serve the IP side only.

--Hong

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 08:58:26 -0700

At 11.56 -0400 00-07-23, Hong Liu wrote:
>On the other hand, it was a good example to show
>PSTN.

Agreed. It is good bringing up examples.

>Other countries may have a different scheme that has different
>countries speak up.

They should definitely speak up (or at least while we write the 
operational spec check that we don't anything which is not valid in 
their model).

   paf

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Jul 2000 09:39:28 -0700

> Normal values of x and y is 4-6 hours and 5 minutes (or shorter).

apologies that i was not sufficiently explicit for the non dns hacks here.

note that some implementations ignore ttl of less than five minutes.

and, from what little i know of this application, i would think x of a day
would be fine and make more net.friends which you could use when you crank
it down to y <= 15 minutes.

randy

---

From: Richard Shockey <[email-masked]>
Date: Sun, 23 Jul 2000 15:19:26 -0500

At 07:13 AM 7/23/2000 -0700, Patrik Fältström wrote:
>We can not make anything which is dependent on a terminology or process in 
>one country.

Exactly ...examples we have made of process in the US are just that 
..examples. Useful for reference purposes only.

We [ I ] should apologize for the often North American centric views that 
get expressed on this list from time to time.  Its the only solid frame of 
reference some of us have.

>What _can_ be created is "Enum operation in the countrycode 1", if we can 
>not come up with more general descriptions.
>
>Personally, I feel that Greg is writing general terms and conditions, and 
>that is a good thing. We should continue to do that -- and then write 
>specifics for each countrycode.

I agree again...Greg is certainly on the right track. Operational issues of 
the ENUM delegation will IMHO be specific to each country.

For instance ..in many countries telephone numbers are directly issued to 
subscribers, who then may choose their carrier of choice unlike North 
America and most Asian countries where TN's are issued by carriers to 
subscribers...its a subtle difference but rather important in the countries 
where this is common.

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640

---

From: Richard Shockey <[email-masked]>
Date: Sun, 23 Jul 2000 15:26:49 -0500

>it down to y <= 15 minutes.

Randy makes an unspoken point here that we all should consider as we move 
forward and might be a topic for our General Discussion in Pittsburgh.

Once we begin some operational testing of the ENUM scheme...we are IMHO 
going to need some well written Best Current Practice / Implementers Guide 
type documents in the future and that will require some rethinking of the 
current WG charter..... help from the DNS hack community will be most 
welcome !

Richard Shockey
Shockey Consulting LLC
5237 Sutherland
St. Louis, MO 63109
Voice 314.503.0640

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Jul 2000 13:30:45 -0700

> current WG charter..... help from the DNS hack community will be most

google for "pittsburgh sushi" has some hits.  so you might get at least some
cooperation. :-)

but, to be honest, paf knows the dns stuff more than well enough for this
application. 

randy

---

From: Hong Liu <[email-masked]>
Date: Fri, 28 Jul 2000 10:28:24 -0400

> Points within the North American IN.

Richard,

I would like to further clarify that in North America, LSMS is operated either
by the service provider itself or through a service bureau, NOT by the NPAC
administrator.  The NPAC administrator operates the regional NPACs, which also
has an SMS by itself. A regional NPAC SMS communicates with the LSMS systems
of that region. Once a request for update is sent from the NPAC SMS to a LSMS,
the update has to be completed within 15 minutes.

Cheers,

--Hong

---

From: Hong Liu <[email-masked]>
Date: Fri, 28 Jul 2000 10:48:42 -0400

Richard,

I would like to know more about this. Do you have any examples? I assume that
you are not talking about personal 800 numbers or UPT numbers. Thanks!

--Hong