Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

From: "Eli Katz" <[email-masked]>
Date: Wed, 20 Sep 2006 20:57:08 +0100

Rich,

> I agree that there is no way a SP is going to do look ups to multiple 
> databases, utter madness. 

"Though this be madness, yet there is method in 't." [H. (II, ii)]

The role of neutral Trusted Private Registries (a private enum registry
which is often a core component of a Federation), as you identify and
define below, enables peering between the SPs belonging to that
Federation. [ With the Federation Provider providing an optional set of
'enabling' services, signalling mgmt, security,  transcoding, transport
etc.., and possibly multiple instations of federations ]. 

The TPR may (based on the specific federation and member policy) either
PUSH the registry data directly into the SP's local database to enable
local querying, or only provide remote query access to such data (due to
(semi-)rational commercial/privacy reasons).

The situation today, is that there is more than 1 neutral Trusted
Private Registry / Federation provider.
[ There may well bi-lateral relationships between the federations, to
enable Service Providers SPs of one Federation to easily peer with SPs
of another Federation. ]

There may also be SP's who are members of >1 Federation.

Hence, while there is not a single global definitive source of TN data
and there are multiple federations (where data is not always pushed to
end SP), then the ability for an SP to query multiple databases is
required. If this will be happen, then the options for sequential and
simultaneous querying methodologies seem to enable a more efficient
lookup.

> Frankly for US Carriers none of this should come as a surprise..the 
> routing tables for the North American PSTN are a union of the 
> Telcordia Local Exchange Routing Guide and the Number Portability 
> Database Administration ..currently NeuStar. Those trusted data 
> sources are merged into a Service Control Point which a Class 5 switch
queries for authorative routing data.

For the USA and approx a handful of other countries, this is the case,
with an advanced almost real-time central database service (NPAC/LERG
combo) for all in-country national routing. Unfortunately, for the other
185 countries this is not (yet) the case at all - although who knows,
based on experiences with various 'forward-looking' NRAs, by 2026 this
may change :-)

Eli

-----Original Message-----
From: Shawn Pouliotte [mailto:[email-masked]] 
Sent: 20 September 2006 19:53
To: [email-masked]; 'Dwight, Timothy M (Tim)'; 'Michael Hammer
(mhammer)'; 'Stastny Richard'; 'Andrew Newton'
Cc: [email-masked]
Subject: Re: [Speermint] Dear Collegues .. a modest proposal.

Richard,

Don't disagree but have some comments listed below;

On 9/20/06 11:29 AM, "Richard Shockey" <[email-masked]> wrote:

> 
> Let me try and set out an alternative theory of how this might 
> actually operate.
> 
> I agree that there is no way a SP is going to do look ups to multiple 
> databases, utter madness. What I presume operators want is _one_ look 
> up that provides a trusted set of data that can be used to make a 
> routing decision on based on local policy.

Actually I have spoke to many who are placed in the position of having
to do this. The providers they want to use as potential routes will NOT
share their data. In these cases, it seems that the business need
outweighs philosophy and they choose to do such things
> 
> A service provider might be part of several federations though in 
> practice the administrative overhead of doing so would be prohibitive.

> What some refer to as the N squared problem.

Of course everything has practical limits. Its like route lists and
current interconnect models. Most carriers cap a route list at 30 deep
due to management and PDD issues. There would be practical limits to
off-board queries as well and a provider will decide what is "enough"
> 
> What is important is the SP be able to "publish" the appropriate TN to

> URI mappings for their points of interconnection for those end points 
> that it purports to be authoritative for to what I would define as a 
> trusted private registries that can act as data aggregator for
multiple service providers.

If they choose to publish. Some just won't
> 
> In the infrastructure ENUM system (ie164.arpa) this would be the 
> appropriate zone administrators' or  whomever the national regulatory 
> authority appoints.

I am referring to pure carrier enum. No regulator or registry
> 
> The SP might aggregate data directly from other trusted private 
> registries into a locally cached database or have their registry 
> operator aggregate data from multiple sources for them.
> 
> How the data is "published" is presumably some form of out of band 
> provisioning interface and how the registry data is acquired is also 
> out of band..for now.
> 
> That data is then made available in a "useful format" such as DNS 
> NAPTR records per 3761 and the SS or whatever network elements then.
> 
> Frankly for US Carriers none of this should come as a surprise..the 
> routing tables for the North American PSTN are a union of the 
> Telcordia Local Exchange Routing Guide and the Number Portability 
> Database Administration ..currently NeuStar. Those trusted data 
> sources are merged into a Service Control Point which a Class 5 switch
queries for authorative routing data.

Not all resolutions required in an SCP paradigm will resolve in 1 query.
Not sure if that was what you were inferring.
> 
> IMHO the solution is multiple data sources merged into a single view 
> for routing. Everything else is how does the SS query for the data. 
> Presumably
> 3761 since its 10 times faster than anything else out there.

No argument. I am just giving my 5 cents on use cases that I see where
this is not possible for whatever crazy reason
> 
> Sure that is probably how someone like myself would look at the 
> problem but there is empirical evidence that the model works in large 
> scaleable public network environments.

No argument that it scales
> 
> I don't see finding federations as much different.
> 
>> -----Original Message-----
>> From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
>> Sent: Wednesday, September 20, 2006 10:31 AM
>> To: Michael Hammer (mhammer); [email-masked]; Stastny Richard; 
>> Andrew Newton
>> Cc: [email-masked]
>> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
>> 
>> I'm confused by a couple of points.
>> 
>> 1. If a VSP can participate in many federations then it must be the
>>    case that the domain lookup sometimes finds multiple federations.
>>    On what basis is a selection made, and does this require some
>>    standardization (e.g., publication of weights, priorities, etc.,).
>> 
>> 2. What does it mean for a transit SP to "serve a federation"?  Are
we
>>    assuming some sort of federation-level interconnection (i.e., that
>>    the transit SP interconnects "to the federation" rather than to
>>    federation memebers)?
>> 
>> tim
>> 
>> 
>>> -----Original Message-----
>>> From: Michael Hammer (mhammer) [mailto:[email-masked]]
>>> Sent: Tuesday, September 19, 2006 2:21 PM
>>> To: [email-masked]; Stastny Richard; Andrew Newton
>>> Cc: [email-masked]
>>> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
>>> 
>>> ATIS has already put out an ANSI NNI standard.  Why reinvent that 
>>> wheel?
>>> 
>>> I think it is important to realize that the world will divide itself

>>> up into federations based on their natural affinities, and that they

>>> won't all agree on the NNI profile.  So, it is better to spend time 
>>> defining how to discover whether the party targeted by the E.164 
>>> number is in a federation shared with the calling domain, or whether

>>> a transit SP is needed, and which one, than to duplicate the work of

>>> other SDOs or forums.
>>> 
>>> ENUM (of whatever flavor) helps to discover the corresponding
domain.
>>> A lookup based on domain helps to discover the federation.
>>> A lookup based on the federation helps to discover transit SPs 
>>> serving those federations.
>>> 
>>> The above can be combined into a single lookup or done separately.
>>> 
>>> Mike
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Richard Shockey [mailto:[email-masked]]
>>>> Sent: Tuesday, September 19, 2006 2:58 PM
>>>> To: 'Stastny Richard'; 'Andrew Newton'
>>>> Cc: [email-masked]
>>>> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
>>>> 
>>>> Which are only 99.998 percent of the transactions right now.
>>>> 
>>>> 
>>>> 
>>>> Yes SPEERMINT should define something more than an NNI
>>> which is why I
>>>> suggest this be done in a series of profiles. Deal with the SIMPLE 
>>>> problems first then proceed in measured steps.  This is the IETF.
>>>> 
>>>> 
>>>> 
>>>> Ending world (or SP)  hunger is not an immediate, though laudable 
>>>> goal.
>>>> 
>>>> 
>>>> 
>>>>   _____
>>>> 
>>>> From: Stastny Richard [mailto:[email-masked]]
>>>> Sent: Tuesday, September 19, 2006 2:26 PM
>>>> To: [email-masked]; Andrew Newton
>>>> Cc: [email-masked]
>>>> Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
>>>> 
>>>> 
>>>> 
>>>> 1. SNIP assumes that you are starting with an e:164 number
>>>> 
>>>> 2. Speermint should do more than just defining an NNI
>>>> 
>>>> 
>>>> 
>>>> Richard
>>>> 
>>>> 
>>>> 
>>>>   _____
>>>> 
>>>> Von: Richard Shockey [mailto:[email-masked]]
>>>> Gesendet: Di 19.09.2006 20:16
>>>> An: 'Andrew Newton'; Stastny Richard
>>>> Cc: 'Brian Rosen'; 'Klaus Darilion'; [email-masked]
>>>> Betreff: RE: [Speermint] Dear Collegues .. a modest proposal.
>>>> 
>>>> Right ... well you maybe could use infrastructure enum to
>>> discover the
>>>> federation ... then a private tree to find the routing data
>>> but I have
>>>> serious doubts about that which is why I tend assume that
>>> some form of
>>>> first iteration SNIP probably deals with federation
>>> discovery out of
>>>> band.  I could be proven wrong however.  Again the idea of SNIP is 
>>>> SIMPLE.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   _____
>>>> 
>>>> From: Andrew Newton [mailto:[email-masked]]
>>>> Sent: Tuesday, September 19, 2006 1:57 PM
>>>> To: Stastny Richard
>>>> Cc: Brian Rosen; Klaus Darilion; [email-masked]; 
>>>> [email-masked]
>>>> Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sep 19, 2006, at 1:52 PM, Stastny Richard wrote:
>>>> 
>>>> 
>>>> 
>>>> Use draft-stastny-enum-ern-00
>>>> 
>>>> 
>>>> 
>>>> This assumes public ENUM. I think the point is that most
>>> federations
>>>> use private ENUM.
>>>> 
>>>> 
>>>> 
>>>> -andy
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Speermint mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/speermint
>>> 
>>> 
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Sep 2006 16:31:52 -0400

> From: Eli Katz [mailto:[email-masked]]
> Sent: Wednesday, September 20, 2006 3:57 PM
> To: Shawn Pouliotte; [email-masked]; Dwight, Timothy M (Tim); Michael
> Hammer (mhammer); Stastny Richard; Andrew Newton
> Cc: [email-masked]

Correct but these value added services are out of scope to the task at hand.
How do service providers create and trust the data they use for routing.

> (semi-)rational commercial/privacy reasons).

Actually they are irrational and bizarre reasons since the point of
interconnection may or may not represent the ultimate endpoint. In IMS for
instance the I-CSCF would then look locally for the true destination
endpoint. We've had this debate before. Ever heard of data mining..this is
what cacheing is all about.

> There may also be SP's who are members of >1 Federation.

Possible.

> simultaneous querying methodologies seem to enable a more efficient

Again not necessarily you are assuming business models here. There may be
data aggregators that may provide a single external view of multiple data
sources on a outsource basis for external query just as there are third
party SS7 C7 providers .. I think a company ..Veri-somebody does that :-)

> based on experiences with various 'forward-looking' NRAs, by 2026 this

You are being too pessimistic. :-) 

The change to SIP based service  routing based on TN argues that such things
will be inevitable. We both know this is not about if, its when.

Cheers..