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

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

re: simultaneous querying; In agreement with Shawn,
 
As there are a) a number of federation enum registries in existence
today, some with full data push, and others with query only, and b)
carriers/SPs are looking 1) to optimise the searching (i.e reduce PDD)
and 2) maximise the hit rate, therefore by enabling simultaneous queries
(with carefully selected "ms" timeouts) or a combination of sequential
and simultaneous, and a simple decision tree for multiple results,
allows the 2 key objectives to be achieved.
 
Afaik, even with alternative federation discovery mechanisms (Otmar et
al), any SP can be a member of multiple federations, in which case
again, the route-decision-process may involve multiple queries coupled
with a desire for optimum and efficient query logic.
 
Eli

________________________________

From: Shawn Pouliotte [mailto:[email-masked]] 
Sent: 20 September 2006 06:50
To: Uzelac, Adam; Brian Rosen; Klaus Darilion; [email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

Hi Adam,

I am curious why you would say that. Obviously I understand the issues
with serial queries and PDD but simultaneous? I fail to see the issue
unless its related to equipment capability. I see an incredible amount
of drive for simultaneous queries in numerous carriers. The carriers in
question generally prefer to peer and slave one another's data however
in some cases, some peering entities choose to not share the data and
will only support per call queries issued to their database. In these
cases, the operators are asking for; 

- Query off board databases if my local database does not have
resolution
- Query my database and all remote databases. 

The responses are then prioritzed and filters based on the carrier's
policy and the result is returned to the client/resolver. 

So, what is the concern? 

Thanks
Shawn

________________________________

	From: "Uzelac, Adam" [mailto:[email-masked]]
	To: Brian Rosen [mailto:[email-masked]], Klaus Darilion
[mailto:[email-masked]], [email-masked]
	Cc: [email-masked]
	Sent: Tue, 19 Sep 2006 18:53:41 -0700
	Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
	
	I, for one, would never expect to see in our network a next-hop
	determination process that would result from simultaneous dips.
	Sequential dips could be something that I could handle, but my
concern
	there is primarily post-dial-delay. The ideal is a single
	query/response for next-hop determination, and after that,
sequential.
	I am not a fan of the simultaneous dip scenario.
	
	-AU
	
	-----Original Message-----
	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Tuesday, September 19, 2006 1:34 PM
	To: 'Klaus Darilion'; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
	
	This solution makes an assumption that as we currently see the
market
	evolving, doesn't make it practical FOR THE EARLY
'PROFILES'/'VERSIONS'
	
	Specifically, the way we are actually (in every case I know)
coupling
	the enum dip with the federation.
	
	This means you can't do federation discovery.
	
	At some point, you could see these functions being split, and
then it
	becomes practical to do federation discovery.
	
	Some people here have pointed out that if you go to a
federation, get
	the dip, and discover the identity of the terminating domain
from the
	dip, then you could connect via some other mechanism (private
peering
	for example).
	Ignoring the business issues, you would have to do serious host
name
	hacking to actually do this. I can't see developing IETF specs
on that
	basis.
	
	I'm trying to be practical here. Self serving, perhaps, but
practical
	none the less. I don't want to be spinning wheels developing
specs that
	can't actually be deployed real soon. As a practical matter, you
CAN be
	a member of multiple federations, and do simultaneous or
sequential dips
	in all of them, evaluate the results, and choose one. That is a
form of
	federation discovery, but it wouldn't use a mechanism like what
Otmar
	proposes.
	
	Brian
	
	> -----Original Message-----
	> From: Klaus Darilion [mailto:[email-masked]]
	> Sent: Tuesday, September 19, 2006 1:11 PM
	> To: [email-masked]
	> Cc: [email-masked]
	> Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
	> 
	> Hi Richard!
	> 
	> 
	> 
	> Richard Shockey wrote:
	> >
	> > What we cant do ... right now.
	> ...
	> > B. Federation Discovery and Policy. How you find a
federation what 
	> > are
	> the
	> > policies associated with that federation.
	> >
	> > Its just too complex to believe that we can deliver a
solution in a 
	> > reasonable amount of time when we have not begun to outline
the
	> semantics of
	> > what that policy should look like.
	> 
	> IMO we are some further. There are already drafts (Otmar's
drafts) 
	> which describe how the federation discovery can be done (there
is even
	
	> working code available).
	> 
	> And the policy will be written on paper somewhere - like with
current 
	> interconnect agreements on TDM basis.
	> 
	> I agree with your other statements.
	> 
	> regards
	> klaus
	> 
	> 
	> >
	> > C. Full Attribute based Identity Management across transit
networks.
	> >
	> > Again the issue is tactical vs architectural.
	> >
	> > Thoughts and flames are sincerely appreciated.
	> >
	> >
	> >
--------------------------------------------------------------------
	> > ----
	> ----
	> > ----
	> > From: Anna Charny (acharny)
	> > Sent: Thursday, September 14, 2006 4:51 PM
	> > To: 'Magnus Westerlund'; 'Lars Eggert'
	> > Cc: [email-masked]'; [email-masked]
	> > Subject: Request for Pre-Congestion Notification BOF
	> >
	> >
	> > Hello Lars and Magnus,
	> >
	> > This message constitutes a formal request for Pre-Congestion
	> Notification
	> > BOF at the November IETF meeting in San Diego.
	> >
	> > The BOF description and its proposed agenda are attached at
the end 
	> > of
	> this
	> > message.
	> >
	> > If this BOF is approved, we would like to request a two-hour
slot 
	> > that avoids scheduling conflicts with the following working
groups:
	
	> > tsv,
	> nsis,
	> > sip, ieprep, ecrit, pwe3, dccp.
	> >
	> > We also ask that you CC [email-masked] with your decision.
	> >
	> > Of course we welcome any feedback you might have.
	> >
	> > Best Regards,
	> > Anna Charny
	> >
	> > PCN BOF Description
	> >
	> > The Pre-Congestion Notification (PCN) BOF will address the
problem 
	> > of
	> how
	> > to provide scalable and resilient admission control and
strong QoS
	> assurance
	> > while using packet marking techniques. Current attempts to
deliver 
	> > QoS
	> using
	> > only packet marking (e.g. DiffServ) are limited in the level
of QoS 
	> > assurance that can be provided without substantial 
	> > over-provisioning. To improve the QoS assurance, PCN will
add flow 
	> > admission control and flow pre-emption. In normal
circumstances 
	> > admission control should protect
	> the
	> > QoS of previously admitted flows. In times of heavy
congestion (for
	> example
	> > caused by route changes due to link or router failure)
pre-emption 
	> > of
	> some
	> > flows should preserve the QoS of remaining flows.
	> >
	> > The overall approach will be based on a the concept of a
PCN-Region,
	> within
	> > which the functionality is separated between the
PCN-Interior Node 
	> > (PIN)
	> and
	> > the PCN-End Node (PEN). The initial scope of the BOF will be
the 
	> > case of
	> a
	> > single DiffServ region, which maps to a PCN-Region. PINs
mark
	packet
	> > headers when their traffic is above a certain level, as an
early 
	> > warning
	> of
	> > incipient congestion ("pre-congestion"); this builds on
concepts 
	> > from
	> RFC
	> > 3168 "The Addition of Explicit Congestion Notification to
IP". PENs
	> monitor
	> > the markings and that information is used to make flow
admission 
	> > control
	> and
	> > pre-emption decisions. The decisions could be made by the
PENs or by
	
	> > a centralized system (which is informed of the PCN
information).
	> >
	> > The BOF will address the need and the motivation for PCN
work in the
	> context
	> > of IETF, provide a brief overview of prior PCN efforts and
related 
	> > work, and review open issues. The BOF will also discuss the
scope 
	> > of work and solicit feedback on the proposed charter.
Ultimately, 
	> > the goal of the
	> BOF
	> > is to solicit community feedback on whether the problem is
clear and
	> needs
	> > to be addressed, and consequently whether the creation of a
new PCN 
	> > WG within the scope of the proposed charter is warranted.
	> >
	> > The draft charter is available from
	> > http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt.
The 
	> > problem statement and motivation for the PCN work is
discussed in 
	> > more detail in draft-chan-pcn-problem-statement-00, which
has been 
	> > submitted to IETF
	> and is
	> > also available at
	
http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt.
	> >
	> > Proposed BOF agenda
	> >
	> > 1. Agenda bashing (5 min)
	> > 2. Motivation and Problem Statement presentation (15 min) 3.

	> > Discussion of motivation and problem statement (30 min) 4.
Overview
	
	> > of prior PCN efforts, related work and open issues (15 min)
5. 
	> > Overview of the proposed charter (10 min) 6.
Discussion/bashing of 
	> > the proposed charter (20 min) 7. General discussion and poll
on the
	
	> > WG creation (25 min)
	> >
	> >
	> > Richard Shockey
	> > Director, Member of the Technical Staff NeuStar 46000 Center
Oak 
	> > Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org 
	> > sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN
Mobile: 
	> > +1 703.593.2683 <mailto:richard(at)shockey.us> 
	> > <mailto:richard.shockey(at)neustar.biz>
	> >
	> >
	> >
	> >
	> >
	> >
	> > _______________________________________________
	> > 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
	
	_______________________________________________
	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 07:07:30 -0400

I don't agree. any SP will logically look at his multiple peering agreements
and federation member ships and aggregate them into a single optimal query
response based on internal policy.

The optimal goal is all call querie on call origination.  One DB dip does it
all. Of course the optimal query mechanism is 3761.

No one is going to tolerate N queries to get an optimal routing /
termination path.

  _____  

From: Eli Katz [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 6:37 AM
To: Shawn Pouliotte; Uzelac, Adam; Brian Rosen; Klaus Darilion;
[email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

As there are a) a number of federation enum registries in existence today,
some with full data push, and others with query only, and b) carriers/SPs
are looking 1) to optimise the searching (i.e reduce PDD) and 2) maximise
the hit rate, therefore by enabling simultaneous queries (with carefully
selected "ms" timeouts) or a combination of sequential and simultaneous, and
a simple decision tree for multiple results, allows the 2 key objectives to
be achieved.

Afaik, even with alternative federation discovery mechanisms (Otmar et al),
any SP can be a member of multiple federations, in which case again, the
route-decision-process may involve multiple queries coupled with a desire
for optimum and efficient query logic.

Eli

  _____  

Hi Adam,

I am curious why you would say that. Obviously I understand the issues with
serial queries and PDD but simultaneous? I fail to see the issue unless its
related to equipment capability. I see an incredible amount of drive for
simultaneous queries in numerous carriers. The carriers in question
generally prefer to peer and slave one another's data however in some cases,
some peering entities choose to not share the data and will only support per
call queries issued to their database. In these cases, the operators are
asking for; 

- Query off board databases if my local database does not have resolution
- Query my database and all remote databases. 

The responses are then prioritzed and filters based on the carrier's policy
and the result is returned to the client/resolver. 

So, what is the concern? 

Thanks
Shawn

  _____  

I, for one, would never expect to see in our network a next-hop
determination process that would result from simultaneous dips.
Sequential dips could be something that I could handle, but my concern
there is primarily post-dial-delay. The ideal is a single
query/response for next-hop determination, and after that, sequential.
I am not a fan of the simultaneous dip scenario.

-AU

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 1:34 PM
To: 'Klaus Darilion'; [email-masked]
Cc: [email-masked]
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

This solution makes an assumption that as we currently see the market
evolving, doesn't make it practical FOR THE EARLY 'PROFILES'/'VERSIONS'

Specifically, the way we are actually (in every case I know) coupling
the enum dip with the federation.

At some point, you could see these functions being split, and then it
becomes practical to do federation discovery.

Some people here have pointed out that if you go to a federation, get
the dip, and discover the identity of the terminating domain from the
dip, then you could connect via some other mechanism (private peering
for example).
Ignoring the business issues, you would have to do serious host name
hacking to actually do this. I can't see developing IETF specs on that
basis.

I'm trying to be practical here. Self serving, perhaps, but practical
none the less. I don't want to be spinning wheels developing specs that
can't actually be deployed real soon. As a practical matter, you CAN be
a member of multiple federations, and do simultaneous or sequential dips
in all of them, evaluate the results, and choose one. That is a form of
federation discovery, but it wouldn't use a mechanism like what Otmar
proposes.

Brian

> > B. Federation Discovery and Policy. How you find a federation what 
> > are
> the
> > Its just too complex to believe that we can deliver a solution in a 
> > reasonable amount of time when we have not begun to outline the
> semantics of
> IMO we are some further. There are already drafts (Otmar's drafts) 
> which describe how the federation discovery can be done (there is even

> working code available).
> 
> And the policy will be written on paper somewhere - like with current 
> > C. Full Attribute based Identity Management across transit networks.
> >
> > The BOF description and its proposed agenda are attached at the end 
> > of
> this
> > message.
> >
> > If this BOF is approved, we would like to request a two-hour slot 
> > that avoids scheduling conflicts with the following working groups:

> > The Pre-Congestion Notification (PCN) BOF will address the problem 
> > of
> how
> > to provide scalable and resilient admission control and strong QoS
> assurance
> > while using packet marking techniques. Current attempts to deliver 
> > QoS
> using
> > only packet marking (e.g. DiffServ) are limited in the level of QoS 
> > over-provisioning. To improve the QoS assurance, PCN will add flow 
> > admission control and flow pre-emption. In normal circumstances 
> > QoS of previously admitted flows. In times of heavy congestion (for
> example
> > caused by route changes due to link or router failure) pre-emption 
> > of
> some
> > The overall approach will be based on a the concept of a PCN-Region,
> within
> > which the functionality is separated between the PCN-Interior Node 
> > (PIN)
> and
> > the PCN-End Node (PEN). The initial scope of the BOF will be the 
> > case of
> a
> > single DiffServ region, which maps to a PCN-Region. PINs mark
packet
> > headers when their traffic is above a certain level, as an early 
> > warning
> of
> > incipient congestion ("pre-congestion"); this builds on concepts 
> > from
> RFC
> > 3168 "The Addition of Explicit Congestion Notification to IP". PENs
> monitor
> > the markings and that information is used to make flow admission 
> > control
> and
> > pre-emption decisions. The decisions could be made by the PENs or by

> > a centralized system (which is informed of the PCN information).
> >
> > The BOF will address the need and the motivation for PCN work in the
> context
> > of IETF, provide a brief overview of prior PCN efforts and related 
> > work, and review open issues. The BOF will also discuss the scope 
> > of work and solicit feedback on the proposed charter. Ultimately, 
> > the goal of the
> BOF
> > is to solicit community feedback on whether the problem is clear and
> needs
> > to be addressed, and consequently whether the creation of a new PCN 
> > http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt. The 
> > problem statement and motivation for the PCN work is discussed in 
> > more detail in draft-chan-pcn-problem-statement-00, which has been 
> > submitted to IETF
> and is
> > also available at
> >
> > Discussion of motivation and problem statement (30 min) 4. Overview

> > of prior PCN efforts, related work and open issues (15 min) 5. 
> > Overview of the proposed charter (10 min) 6. Discussion/bashing of 
> > the proposed charter (20 min) 7. General discussion and poll on the

> > WG creation (25 min)
> >
> >
> > Richard Shockey
> > Director, Member of the Technical Staff NeuStar 46000 Center Oak 
> > sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile:

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 20 Sep 2006 10:14:06 -0400

Eli,
 
I understand exactly the vision you are depicting, but my phone would be
ringing off the hook if the most appropriate route/path (either in terms
of cost or efficiency) were to "timeout" and therefore not be selected
for any significant length of time.  I could cache, but the data-set
tends to be more dynamic than not.  My other concern is the volume of
transactions in the "pump out X number of requests to X number of enum
registries).  To be practical, X must be a small number (<=6 IMO). If
not, I could see our routing team cause major SIP border floods in the
signaling plane by flushing the cache due to stale routes.
 
A question I have builds on your point "As there are a) a number of
federation enum registries in existence today...." and I would add that
we are at the tip of the proverbial iceberg -  So, are there any other
options to access key routing data besides simultaneous (timeout/delay
concern) or sequential (delay/timeout concern) routing dips?  Do you
think that there's a practical limit to the number of registries I can
garner data from? 
</melodrama bit on>
Are we heading down the path to mayhem? Or worse yet, are is down the
path of replacing the current static routing practices of the legacy
PSTN with something LESS efficient?  /me shudders.
</melodrama bit off>
 
-AU 

 

Eli

Hi Adam,

So, what is the concern? 

Thanks
Shawn

	
	
	-AU
	
	-----Original Message-----
	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Tuesday, September 19, 2006 1:34 PM
	To: 'Klaus Darilion'; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

	

	
	
	Brian
	
federation what 
solution in a 
the
drafts) 
is even
	
current 
networks.
the end 
slot 
	
problem 
strong QoS
deliver 
of QoS 
add flow 
circumstances 
congestion (for
pre-emption 
PCN-Region,
PCN-Interior Node 
the 
mark
	packet
early 
concepts 
IP". PENs
admission 
PENs or by
	
information).
work in the
related 
scope 
Ultimately, 
clear and
new PCN 
The 
discussed in 
has been 

Overview
	
5. 
Discussion/bashing of 
on the
	
Oak

---

From: Shawn Pouliotte <[email-masked]>
Date: Wed, 20 Sep 2006 08:19:21 -0700

Hey Adam,

Let me add some qualifiers around my comments. Firstly, if there are 5 registries, you will not be doing remote queries to 5 - more likely 1 or 2. I agree that sharing the data makes consierably more sense but some SPs just don't want to go there. Regarding timeout, if the average response time for a db is in the order of 1 mSec. Lets pretend its really slow and it takes 5 mSec for sake of arguement. Your timeout is round trip time + query latency more of less. The SP is free to decide how much time is too long and can certainly negotiate to have slaves located in a place where rtt is minimized if its beyond their acceptable budget. 

If you take the case above where 3 are sharing data with you and 2 expect off board queries. Assume rtt=30 mSec for the offboard resources and 5 for query response. If your policy is to query your local db (which contains your data and data from 3 others) first and if no resolution, go to the others, your introduction in PDD is 5 mSec for local resolution and 35 mSec for remote. If you receive all your responses before 35 mSec, it would obviously be less. If thats too high then turn down the query timeout on remote requests and don't agree to interwork with fabrics that can't meet your delay budget. If you can't tolerate delay at all, then no solution will work for you in this case - serial would definitely be off the table (which you eluded to as being more acceptable)

All that said, are there better ways to do things and a Utopian view? Of course there are but that doesn't change the fact that there are islands out there that just are not ready to go down those roads. My only point was that I don't see an issue with parallel queries to solve this issue when other vehicles don't exist. 

Shawn
  _____  

From: "Uzelac, Adam" [mailto:[email-masked]]
To: Eli Katz [mailto:[email-masked]], Shawn Pouliotte [mailto:[email-masked]], Brian Rosen [mailto:[email-masked]], Klaus Darilion [mailto:[email-masked]], [email-masked]
Cc: [email-masked]
Sent: Wed, 20 Sep 2006 07:14:06 -0700
Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

Eli,  
   
I understand exactly the vision you are depicting, but my phone   would be ringing off the hook if the most appropriate route/path (either in   terms of cost or efficiency) were to "timeout" and therefore not be   selected for any significant length of time.  I could   cache, but the data-set tends to be more dynamic than   not.  My other concern is the volume of transactions in   the "pump out X number of requests to X number of enum   registries).  To be practical, X must be a small number (<=6   IMO). If not, I could see our routing team cause major SIP border floods in   the signaling plane by flushing the cache due to stale   routes.  
   
A question I have builds on your point "As there are a) a   number of federation enum registries in existence today...." and I would   add that we are at the tip of the proverbial iceberg -  So, are there   any other options to access key routing data besides simultaneous   (timeout/delay concern) or sequential (delay/timeout concern) routing   dips?  Do you think that there's a practical limit to the number of   registries I can garner data from?   
</melodrama bit on>  
Are we heading down the path to mayhem? Or   worse yet, are is down the path of replacing the current static routing   practices of the legacy PSTN with something LESS efficient?  /me   shudders.  
</melodrama bit off>  
   
-AU 

    _____  

  From: Eli Katz [mailto:[email-masked]]   
Sent: Wednesday, September 20, 2006 6:37 AM
To: Shawn   Pouliotte; Uzelac, Adam; Brian Rosen; Klaus Darilion;   [email-masked]
Cc: [email-masked]
Subject: RE:   [Speermint] Dear Collegues .. a modest proposal.

   
As there are a) a number of federation enum registries in   existence today, some with full data push, and others with query only, and b)   carriers/SPs are looking 1) to optimise the searching (i.e reduce   PDD) and 2) maximise the hit rate, therefore by enabling simultaneous   queries (with carefully selected "ms" timeouts) or a combination of sequential   and simultaneous, and a simple decision tree for multiple results, allows the 2   key objectives to be achieved.  
   
Afaik, even with alternative federation discovery mechanisms   (Otmar et al), any SP can be a member of multiple federations, in which case   again, the route-decision-process may involve multiple queries coupled with a   desire for optimum and efficient query logic.  
   
Eli  

    _____  

Hi Adam,

I am curious why you would say that. Obviously I   understand the issues with serial queries and PDD but simultaneous? I fail to   see the issue unless its related to equipment capability. I see an incredible   amount of drive for simultaneous queries in numerous carriers. The carriers in   question generally prefer to peer and slave one another's data however in some   cases, some peering entities choose to not share the data and will only support   per call queries issued to their database. In these cases, the operators are   asking for; 

The   responses are then prioritzed and filters based on the carrier's policy and the   result is returned to the client/resolver. 

So, what is the concern?   

Thanks
Shawn
        _____  

    From: "Uzelac, Adam"     [mailto:[email-masked]]
To: Brian Rosen     [mailto:[email-masked]], Klaus Darilion     [mailto:[email-masked]], [email-masked]
Cc:     [email-masked]
Sent: Tue, 19 Sep 2006 18:53:41     -0700
Subject: RE: [Speermint] Dear Collegues .. a modest     proposal.

-AU

-----Original Message-----
From: Brian Rosen     [mailto:[email-masked]] 
Sent:     Tuesday, September 19, 2006 1:34 PM
To: 'Klaus Darilion'; [email-masked]
Cc: [email-masked]
Subject: RE:     [Speermint] Dear Collegues .. a modest proposal.

Brian

packet

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 22 Sep 2006 17:12:45 +0200

> response based on internal policy.

That assumes that all necessary data can be pre-loaded into the local database.

This assumption is non-trivial. Especially when we start to talk about
routing based on URIs, we'll run into the domain-enumeration problem,
which is IMHO not solveable.

> No one is going to tolerate N queries to get an optimal routing /

Agreed on the all call query.

Regarding the single dip: that's not the requirment. That's a
possible solution. The requirement it a short and predictable 
resolution time.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >