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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 19 Sep 2006 15:21:27 -0400

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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Sep 2006 06:25:43 -0400

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2006 3:21 PM
> To: [email-masked]; Stastny Richard; Andrew Newton
> Cc: [email-masked]

So why does SPEERMINT exist? See charter.

> A lookup based on the federation helps to discover transit SPs serving

IMHO this is a very complex problem. I simply wonder if this is better done
out of band as part of classical bi-lateral relationships between providers
but accessed locally as part of some cached data base.

I simply refuse to believe that any advertisement of membership in a
federation or ability to route against a specific number range (s) will not
be backed up by written contracts.

If I'm a SP I would never accept traffic unless A. I had positive and
authenticated knowledge of where the traffic is coming from and B. a signed
commercial agreement on how that traffic is to be handled.

There is no transit or peering agreement on the internet now that is not
backed up by commercial agreements. I see no reason that is going to change.

But I could be wrong.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 20 Sep 2006 14:31:13 +0000

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

> Sent: Tuesday, September 19, 2006 2:21 PM
> 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.
> 
> A lookup based on the federation helps to discover transit 
> SPs serving those federations.
> 
> > 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.
> > 
> >  
> > 
> >   _____
> > 
> 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: "Uzelac, Adam" <[email-masked]>
Date: Wed, 20 Sep 2006 11:07:47 -0400

The basis of the selection is a matter of local policy - therefore no
standardization.  If an enterprise is interconnected to both the VPF and
Xconnect, that enterprise might want to route to Xconnect because they
are nicer on Fridays.

A transit SP would be defined as a VSP that is a member of 2 or more
federations - Example: Global Crossing is interconnected to Xconnect and
Sunrocket - and now offers up the capability for Xconnect subscribers to
establish a session with Sunrocket subscribers via GC. Though there may
be a direct connection between Xconnect and Sunrocket, for reasons of
local policy, both Xconnect (and its subs) and Sunrocket (and its subs)
can route directly, or indirectly. 

To me, Federation-level interconnection can be assumed to a certain
extent based on the registry that they are defined in - most likely
private enum.

-AU

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

tim

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

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Sep 2006 17:25:58 +0200

>   standardization (e.g., publication of weights, priorities, etc.,).

The selection is always done by the originating VSP
If both the originating VSP and the terminating VSP have more than
one federation in common, which means the originator may choose between
two or more NNIs. IMO it is then a local decision depending e.g on load balancing
or preferred NNI, etc. Weight, priorities etc from the destination side may not be helpful here

>2. What does it mean for a transit SP to "serve a federation"?  
IMO there are (at least) two types of transit providers:
 
a. transit providers given by the terminating VSP
this can easily handled by federation policy records
as described in draft-lendl-speermint-federations
with a nor-terminal NAPTR
 
you look up the ttermination domain and find te.g. wo
NAPTRs:
first is say an IPX federation
second is a national carriers federation
 
if you are not member of IPX,, you go for the non-terminal pointing
to a VSP which is also part of the national federation (e.g. the incumbent carrier)
If you are also part of the national federation, you are done
 
b. you are a small operator an forward all traffic which does not belong to your federation
to a well-established transit operator, who cares about any traffic
 
>   Are we
 
could be, but not necessarily
 
Richard

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 20 Sep 2006 16:59:25 +0000

Thanks, Richard.  Other comments inserted below.

tim

> The selection is always done by the originating VSP If both 
> the originating VSP and the terminating VSP have more than 
> one federation in common, which means the originator may 
> choose between two or more NNIs. IMO it is then a local 
> decision depending e.g on load balancing or preferred NNI, 
> etc. Weight, priorities etc from the destination side may not 
> be helpful here

I assumed it would be up to the originating VSP, was just wondering if
there was value in letting the destination VSP provide input into that
decision.  I don't have a specific use case in mind.

> a. transit providers given by the terminating VSP this can 
> easily handled by federation policy records as described in 
> draft-lendl-speermint-federations with a nor-terminal NAPTR
>  
> if you are not member of IPX,, you go for the non-terminal 
> pointing to a VSP which is also part of the national 
> federation (e.g. the incumbent carrier) If you are also part 
> of the national federation, you are done
>  
> b. you are a small operator an forward all traffic which does 
> not belong to your federation to a well-established transit 
> operator, who cares about any traffic

I understand.  But in these examples (and in
draft-lendl-speermint-federations generally) the transit SP seems to
serve an individual VSP.  I'm still not sure in what sense a transit
provider serves a federation.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Sep 2006 14:29:24 -0400

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.

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.

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.

In the infrastructure ENUM system (ie164.arpa) this would be the appropriate
zone administrators' or  whomever the national regulatory authority
appoints.

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.

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. 

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.

I don't see finding federations as much different.

> To: Michael Hammer (mhammer); [email-masked]; Stastny Richard; Andrew
> Newton
> Cc: [email-masked]

---

From: Shawn Pouliotte <[email-masked]>
Date: Wed, 20 Sep 2006 11:53:14 -0700

Richard,

Don't disagree but have some comments listed below;

> 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
> 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"
> registries that can act as data aggregator for multiple service providers.

If they choose to publish. Some just won't
> zone administrators' or  whomever the national regulatory authority

I am referring to pure carrier enum. No regulator or registry
> 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.
> 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
> there is empirical evidence that the model works in large scaleable public

No argument that it scales

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Sep 2006 15:22:28 -0400

> From: Shawn Pouliotte [mailto:[email-masked]]
> Sent: Wednesday, September 20, 2006 2:53 PM
> To: [email-masked]; 'Dwight, Timothy M (Tim)'; 'Michael Hammer
> (mhammer)'; 'Stastny Richard'; 'Andrew Newton'
> Cc: [email-masked]
> 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
> philosophy and they choose to do such things.

Well that does defeat the purpose of the entire exercise doesn't it. Either
you publish your TN 2 URI mappings or you don't. Fine ..they can default
route to the PSTN and pay.

And if they say that they don't want to publish their mappings because they
think someone will steal their customers they are just plain foolish. Any
North American Provider, for instance, can find out who is authoritative for
any TN by looking up the underlying SPID. Sharing data does not create
customer poaching opportunities. Sharing data creates interoperability.

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

Fine .. walled gardens are nothing more than padded cells. The case of SMS
in the US is instructive. Once the mobile operators agreed to cooperate and
exchange traffic the use of the SMS service by consumers increased
exponentially as did their profits.

> I am referring to pure carrier enum. No regulator or registry

Well terminology is a problem ..this is Private ENUM. 3761 is only the
access method.

> >
> > 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.
> > provisioning interface and how the registry data is acquired is also out
> of band..for now.
> >
> > 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.

I didn't suggest it would only that that is the goal.

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

I know ..but we cant fix stupid, only create the technical requirements for
SIP service interoperability.

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

Just for a couple of billion transactions per day ..

Cheers.

> Andrew

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 20 Sep 2006 21:58:18 +0200

>provider serves a federation.

Transit providers may be normal members of the federation being also members
of other federations. 
 
Of course a federation may also choose to select one specific VSP as transit provider
 
Richard

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 22 Sep 2006 15:50:47 +0200

On 2006/09/20 12:09, Richard Shockey <[email-masked]> wrote:
> IMHO this is a very complex problem. 

.. which has been solved in 

$ wc -l *.[ch]
  934 domainpolicy.c
   66 domainpolicy.h
  268 domainpolicy_mod.c
   63 domainpolicy_mod.h
  118 regexp.c
   36 regexp.h
 1485 total

that 1485 lines of code.

The protocol issues are simple. It's the business decisions which are complex.

Which set of problems does the IETF try to solve?

>                                      I simply wonder if this is better done

That assumes that we will stay with "classical bi-lateral relationships 
between providers". True, that might be the case if you just look at
how the really big providers operate (now). I am pretty sure that other
players will bring other modes of operation (and thus peering) to the table.

Smaller VSPs or enterprises will approach that issue from a very 
different angle than a big old-school telephony operator.

Speermint needs to accomodate all three.

> commercial agreement on how that traffic is to be handled.

Even if there needs to be a written agreement, it does not follow that 
this must be a bi-lateral contract. It could just as well be the membership
contract with a federation which includes the technical and commercial
agreements concerning calls between fellow members. 

>From a legal point of view there is little difference. IANAL and all that.

> backed up by commercial agreements. I see no reason that is going to change.

If you're talking about Layer 3 peering (BGP based), you *are* wrong.

The very big boys with their "if you want to peer with me you have to
have a net at least $this big" policies do require contracts, but most
others don't. More often than not, peerings at IXPs are arranged by
email betweens techies and are established within a few hours.

Been there, done that. I just asked a few friends who are still in the L3
business: yep, there is still a lot of contract-free peering going on.
Between mid-size ISPs in Europe, contracts are actually the exception.

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

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 22 Sep 2006 16:07:31 +0200

> decision.  I don't have a specific use case in mind.

draft-lendl-speermint-federations allows destination VSPs to indicate
their preference. 

> provider serves a federation.

Yes, the examples do not cover that case explicitly.

Do you think this is a model I should explore in more depth?

/ol

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 25 Sep 2006 14:22:38 +0000

A few comments from the SP side...

tim 

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

_one_ would be ideal.  Some will be willing to extend this a bit.  Given
the probable existence of multiple private registries, it's at this
point not clear whether it's more expedient for service providers to
query them directly, have them query one another or some combination of
the two.

The more important question is how we can structure the registries so
that such a system can scale.  No matter who launches the queries a
linear search of all possible registries is not going to be viable.
Hence the focus on federations, which seems to me a clever and
potentially workable means of imposing such structure.

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

Again I think assuming "one" would be overly restrictive, but the desire
will be to join as few as necessary for the reasons you note.  One might
expect geography (think "country code") or in some cases business
affiliations (e.g., GSMA) to motivate federation membership, and some
number of "inter-federation carriers" to provide transit services
between carriers who had no federation in common.  

> 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 
> In the infrastructure ENUM system (ie164.arpa) this would be 
> the appropriate zone administrators' or  whomever the 
> national regulatory authority appoints.
> 
> 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.

SPs may also aggregate data from one another directly.  Bilateral
peering agreements aren't a universal solution but probably aren't going
to disappear either.

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

Sure.  This works for routing calls within CC1; because within CC1 there
is agreement on who maintains this shared registry.  Unfortunately in
VoIP there is no similar agreement (yet, anyway).

If we had such agreement, the registry providing the VoIP equivalent of
the LERG + NPAC would look like a federation in the general model under
discussion.  In the absence of an infrastructure such as might accompany
ie164.org, we'd still need mechanisms such as described in the lendl
federations draft to interoperate globally.

> 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

That sounds like the solution for intra-federation routing.

> 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.
> 
> > > 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.
> > >
> > > A lookup based on the federation helps to discover transit SPs 
> > > serving those federations.
> > >

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 25 Sep 2006 15:05:12 +0000

> > > b. you are a small operator an forward all traffic which does not 
> > > belong to your federation to a well-established transit operator, 
> > > who cares about any traffic
> > 

> Do you think this is a model I should explore in more depth?

To me it depends on whether we imagine the transit service being
provided to the federation or to an individual VSP.  I imagine the
latter to be more common, but others have noted that there are instances
of the former in the wild already.  So ideally our mechanisms should
support both.

tim