Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 6 Oct 2006 10:38:25 -0400

Excellent list.  Glad to see we are capturing this in an ID.

Mike

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 6:38 PM
> To: [email-masked]
> Subject: [Speermint] Basic Peering Requirements
> 
> I was asked at the interim meeting to put together a list of 
> base-level peering requirements by Jean-francois.  I put 
> together a list and tried to send it to him, but I'm not sure 
> it ever made it.  In either case, I wanted to post it to the 
> list, so the WG will have ample time to pummel it before San 
> Diego. ;-)
> 
> ----------------------------------------------------------------------
> 
> Jean-Francois,
> 
> Per our conversation in Philadelphia, I have compiled a list 
> of basic peering requirements from one operators perspective. 
>  I can post these to the list if you would like.  Here is a 
> list of peering requirements (this is certainly not 
> exhaustive, but is a platform):
> 
> Transport (Layer 1  3):
> 
> Peering must utilize IP as the primary mechanism for peering. 
> 
> A federation must agree upon a common mechanism for IP 
> transport either private (e.g. IPVPN, IPSEC, etc.) or public. 
> 
> (Net of this...most operators will peer with these methods today.)
> 
> Billing:
> 
> If peering services involve billing, the peers or federation 
> must agree on a common monetary policy. 
> 
> The peers or federation must agree on a common currency. 
> 
> (Net of this...some customers may abuse peering, and 
> operators may want to bill for certain traffic pattern types 
> (e.g. Layer 3 IP Peering
> Leaches).)
> 
> Policy:
> 
> Policies may be implemented locally to the peer or via a 
> centralized mechanism within the federation. 
> 
> Local policies should be disclosed when creating direct 
> peering relationships with the applicable direct peer. 
> 
> Local policies may supersede centralized federation policies. 
> 
> (Net of this...some peering relationships will be 1:1, so 
> policies will likely be local only.  Some peering 
> relationships will be 1:N, so policies will likely be 
> implemented within DNS or some centralized
> mechanism.)
> 
> Membership:
> 
> A peer may be a member of multiple federations 
> 
> A peer must maintain compliancy for policies as defined by 
> each federation the peer is a member of. 
> 
> If a peer is providing connectivity to multiple federations, 
> it should disclose AoRs providing indirect peering 
> relationships to servicing peers or federations. 
> 
> Peers providing indirect peering must enforce federation 
> policies on behalf of the destination federation. 
> 
> A peer providing indirect peering may enforce undisclosed 
> policies for processing session requests between federations. 
> 
> (Net of this...some peers will only desire to be part of a 
> single federation, where wholesale carriers will likely be 
> members of multiple
> federations.)
> 
> Media:
> 
> Peers must agree on one or more CODECs, which is either 
> negotiated directly or via a transcoding mechanism. 
> 
> A transcoding mechanism may exist locally or centralized 
> within the federation. 
> 
> (Net of this...most operators only support a couple of CODECs 
> across the core of their network, but will transcode at the edge.)
> 
> Routing:
> 
> A peer must utilize the centralized federation routing 
> mechanism if it is available. 
> 
> A peer allowing another peer within a federation to provide 
> indirect peering on their behalf must select only one 
> indirect peer to host their AoRs. 
> 
> A peer must not copy routing information from or make assumed 
> routing choices on behalf of the centralized routing 
> mechanism for use locally unless it takes place through 
> standard caching methods. 
> 
> A common API must be utilized and available for subscriber 
> and route provisioning on any centralized federation location 
> function. 
> 
> Subscriber and routing information must be dynamically 
> updated as soon as applicable for accurate routing within the 
> federation. 
> 
> (Net of this...In small peering (e.g. 1:1), a REDIRECT model 
> is simple and not too inefficient.  In a larger peering 
> scenario (e.g. 1:N), a more efficient method is absolutely 
> necessary, in comes ENUM/DNS/NAPTR.
> Unfortunately, both methods will likely be necessary until 
> wider spread adoption of DNS methods takes place.)
> 
> Performance:
> 
> Performance metrics must be shared between peers as they 
> apply directly to peering signaling and media on a consistent 
> basis within the federation. 
> 
> (Net of this...this is just a reality otherwise; finger 
> pointing takes place anytime something breaks.)
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 16 Oct 2006 09:36:57 -0600

Brian wrote:
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 12:19 PM
> To: 'Daryl Malas'; Jean-Francois Mule
> Cc: [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> I've been thinking about this thread and while there are some
> conversation
> starters here, I wonder how really relevant a lot of this is.  Maybe
> "relevant" is the wrong word, but I mean how much time and effort (and
> words in a document) do we give it.
> 
> Generally speaking, the IETF designs protocols.  In this work, we are
> probably not going to do that, we're going to do "Best Current
> Practice"
> documents.  In the IETF, those are mostly "how best do you use the
> protocols
> the IETF defined, for a specific task".

Agreed. 
Here is a the proposed accounting section (edited from Daryl's text)
with *specific* IETF protocol references:

-----------------------
Accounting and Billing:
Call accounting may be required for tracking session usage on a peer's
network.  It is critical for peers to determine whether the support of
any SIP extensions for accounting is a pre-requisite for SIP
interoperability. In some cases, call accounting may feed data for
billing purposes but not always: some operators may decide to use
accounting as a 'bill and keep' model to track session usage and monitor
usage against service level agreements.

<xref target="RFC3702"/> defines the terminology and basic requirements
for accounting of SIP sessions.  A few private SIP extensions have also
been defined and used over the years to enable call accounting between
VSP domains such as the P-Charging* headers in  <xref
target="RFC3455"/>, the P-DCS-Billing-Info header in <xref
target="RFC3603"/>, etc.
------------------------

Note this is out of scope but it helps on three fronts:
	- bring folks on the same page re: terminology (count how many
times billing has been mentioned on this list when we meant accounting)
	- capture what's out there in some RFCs
	- start providing answers to folks who are not tracking the
list.  I note that some recent and esteemed reviewers asked about
billing and accounting.

Worse case, this is in an annex, we just delete it when the document
matures. At least, that was my thought.

> Generally speaking, IETF documents don't describe what would be in a
> contract between peers or between a peer and a federation.  

I agree and I have refrained from using the terms federation in the
edited text. To re-use your proposed definition of 'policy', I view
these as things that peers should talk about as part of policy
agreements.

> It is all
> well
> and good, and in fact I enthusiastically agree that the resolution of
> the
> codec discussion is that "The federation defines a codec policy to
> which all
> peers must adhere which would include designation of one or more
> mandatory
> to deploy codec and/or local transcode capability for each supported
> media
> type (audio, video, text) so that all calls can successfully complete
> offer/answer exchange.  Consideration should be given in specifying
> mandatory-to-deploy codecs to include at least one that has minimal
> degradation of signal fidelity when two transcodes are required to
> achieve
> actual end to end compatibility."

The proposed text for draft-01 based on the interim meeting reads:
--------------------
<t> Media-related parameters SHOULD be included as part of a Voice
Service Provider's policy. VSPs engaged in session peering SHOULD
support of compatible codecs. Transcoding SHOULD be avoided by proposing
commonly agreed codecs. 

Motivations:
The media capabilities of a VSP's network are either a property of the
SIP end-devices, or, a combination of the property of end-devices and
Data Path Border Elements that may provide media transcoding. The choice
of one or more common codecs for Voice over IP communications between
VSPs is outside the scope of speermint. As stated in introduction,
requirements applicable to end-devices of a VSP are out of scope.
---------------------

Jean-Francois.

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 18 Oct 2006 13:10:17 -0400

Given that they are peers, are the multihoming advertizements symmetric?

VSP    Transit VSP

SF<----->SF
    \ /
    / \
SF<----->SF

Mike

> Sent: Wednesday, October 18, 2006 11:56 AM
> To: Otmar Lendl
> Cc: [email-masked]
> Subject: Re: [Speermint] Basic Peering Requirements
> 
> On Wed, 2006-10-18 at 17:23 +0200, Otmar Lendl wrote:
> > On 2006/10/18 17:10, Daryl Malas <[email-masked]> wrote:
> > > On Wed, 2006-10-18 at 15:54 +0200, Otmar Lendl wrote:
> > 
> > > > Do you mean indirect peering *within* a federation? Let me name 
> > > > the parties here:
> > > > 
> > > > > A peer (X) allowing another peer (Y) within a 
> federation (F1) to 
> > > > > provide indirect peering on their behalf must select only one 
> > > > Is the idea here that all members of F1 who want to 
> place calls to 
> > > > X need to route the calls via Y? In that case, I would not 
> > > > consider X to be a member of F1. Instead, Y is 
> providing transit 
> > > > services for X.
> > > 
> > > Your assumption is correct, X is not a member of F1.  
> They can only 
> > > specify to allow Y (and not A, B, C, and D) to provide indirect 
> > > peering within F1.
> > > 
> > > > Or you want to restrict X to be able to only select one 
> other VSP 
> > > > to host it's AoRs in total?
> > > 
> > > Yes
> > > 
> > 
> > How does multihoming (e.g. a small VSP which wants to by upstream 
> > services from multiple transit VSPs) fit into that scheme?
> Again, I talked about this in a previous thread.  A small VSP 
> can be multi-homed to a single transit VSP (e.g. multiple 
> SF's).  They will also likely be connected "indirectly" to 
> multiple federations, which also may be contracted to provide 
> an indirect route back to this federation through one of the peers.
> 
> I think this simplifies it greatly.  If we must, then I 
> suggest a maximum of two peers in a federation may provide 
> indirect peering to an external VSP.
> > 
> > /ol
> 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 20 Oct 2006 13:58:46 -0400

Brian,

I am enjoying the challenging discussion.

You are correct, I think that any middlemen that add no value will be
disintermediated, sooner or later.  

I think that getting any more than 2 Transit VSPs involved only means
that a revenue pie gets split more ways, with each slice getting smaller
and smaller.  

It is also a good idea to have media go as directly as possible, else
quality suffers.

But, I think that having up to two is reasonable based on the idea that:
1) not everyone can agree to one federation/peering,
2) membership in federations/peerings will not overlap,
3) even Transit VSPs can't be members of all federations;
so Transit VSPs provide a valuable service to interconnect the islands.

Occum's Razor suggests that the less complex solution will be the better
one.

I also think that inefficient mechanisms could get bypassed if they
aren't part of an efficient process.  The revenue stream trajectory
won't support inefficiencies.

And finally, DNS worked, no?

Cheers,
Mike

> Sent: Friday, October 20, 2006 1:40 PM
> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar 
> Lendl'; 'Daryl Malas'
> Cc: [email-masked]
> This is fun, I think :)
> The fundamental disagreement seems to be in assumptions on 
> route complexity.
> You think it's possible to build a max three hop system: 
> origination to o-transit via o-federation, to t-transit via 
> x-federation, to termination via t-federation.  You think all 
> transit networks IN THE GLOBE will agree to federate with 
> each other (x-federation).
> 
> I find that preposterous.  I think routes will be much more 
> complex in international routing, involving several more hops 
> and lots of route choices.  I'm not even sure that 3 hops 
> will work for domestic cases, although I hope they will most 
> of the time.
> 
> The other disagreement is you think carriers will permit 
> SOME, but not all, of their routing data to be public.  I do 
> not agree, I think it will all be private.  I'm not happy 
> about that, but I think that is reality.  It's certainly the 
> case for all the existing federations.
> 
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Friday, October 20, 2006 12:25 PM
> > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas
> > Cc: [email-masked]
> > Brian,
> > I see a fundamental point of disagreement that runs through all your
> > comments:
> > 
> > You are focused on routing toward TNs.
> > I am focused on routing towards domains, where the domain 
> is the key 
> > to finding the route to it.
> > 
> > PSTN is about routing toward E.164 TNs.
> > Speermint is about routing toward domains.
> See my prior note to Otmar.
> 
> I'm all for peering on the Internet.  It works really quite 
> well.  The problem is, carriers don't want to do that.  I 
> agree that we need to route towards domains if you start with 
> a domain.  I think 99% of the problem is routing towards TNs. 
>  As I said to Otmar, we can use the same solution for both, 
> but I really want to optimize TN to domain, domain to next 
> hop to TN to next hop.
> 
> > 
> > More inline...  (Then I let it stew a bit.)
> > 
> > > You ask the sources you have (the federations or the transit
> > > networks) if they can terminate your call.  You don't 
> care HOW they 
> > > do it.
> > 
> > I think the idea of scanning the routing database of all potential 
> > partners will be resource intensive and in many cases a 
> waste of effort.
> > If you wait to do it at call setup, it may not be efficient.
> I think you are stuck with this.  You can cache the data, but 
> the reality is that since it changes, you need to do the 
> queries at call time.
> The biggest part of this problem is TN to domain.  Because of 
> number portability, caching is of limited usefulness. The 
> fact that you could cache the domain to route doesn't help 
> you if, as I propose, that's one query.
> 
> If you can actually aggregate TN to domain into one database, 
> it would be a big, but readily implementable database, and 
> you would get the answer in one query.  I don't think that 
> will happen. You will need referral.  That is where the time 
> will come.  I think referral can be made fast enough for the 
> problem at hand.
> 
> The real issue is how complex the transit network 
> arrangements become.  I believe that the simple cases will be 
> simple - likely one or two transit networks to two or three 
> federations (think something like cable MSO to cable 
> federation, transit to ILEC federation, transit to CLEC).  We 
> have to make things more complex work (same as above to ILEC 
> federation, but more than one choice of international transit 
> to more than one choice of international federation to 
> termination network). 
> 
> On the other hand, I don't think it's very hard to do this.  
> If we can really have the tail drop really low after 3 
> federations (2 referrals), then likely we can make that be 
> plenty fast enough.
> 
> > > Another is just a list (of VSPs reachable from this 
> federation); it 
> > > doesn't change very often.  You can arrange your own query 
> > > mechanism.
> > 
> > You know have a stale caching problem.
> Nah, you put TTL on the query and refresh when you need to.
> They don't change often, and the changes are planned.
> 
> A larger problem is the TNs.  You may have multiple routes to 
> TNs, and when they change, you could have a stale route.  You 
> can't preplan those changes in time frame less than minutes.  
> We need a solution for that.
> 
> 
> ..snip...
> > > Well, sort of.  You may have more than one federation 
> membership.  
> > > Since I don't see a God Box who could tell you which 
> federation YOU 
> > > BELONG TO can get you to the destination, you have to ask 
> them all 
> > > and, if more than one says yes, you have to have a way to decide 
> > > which one.  For the moment, I'm ignoring the how you 
> decide.  It's 
> > > "trial and error" in the sense that you ask each 
> federation, and get 
> > > an answer from each, some of which may be error reports 
> ("you can't 
> > > get there from here via me")
> > 
> > You only need to know the targets federation and your own 
> configured 
> > federation to do a simple comparison.  If there is no 
> match, you can 
> > send to a Transit VSP that could be derived from a couple 
> simple DNS 
> > lookups.
> You and Otmar/Klaus keep thinking that all transit networks 
> will provide transit to every TN on the planet.  Not 
> feasible.  You have a complex network diagram, and you have 
> to figure your way through the network.
> Feed forward reachability works.  Lookups don't work because 
> the thing you are looking up doesn't have the network map.
> 
> If there are 3 federations and two transit networks between 
> me and the termination VSP, what series of lookups do you do, 
> and how are you coping with more than one route in any link?  
> That is the likely path for an international call.  
> 
> ...snip...
> > > No, I'm assuming the federation can tell me next hop, and 
> that's all 
> > > it can tell me.  That's more or less the way all routing works.  
> > > It's more like you try all paths and see how many lead to your 
> > > destination, but in this case you only get the next hop.  
> But, like 
> > > all routing problems, you may have zero, one, or more 
> than one next 
> > > hop choices that are valid.
> > > Whether you have in your possession all the routing data, or you 
> > > query for it, or you query and cache for it, the result 
> is the same: 
> > > you ask every federation if they can route your call, and select 
> > > one.
> > 
> > But, I don't want to query a lot of federations hoping for 
> a hit.  I 
> > want each successive lookup to result in definitive answers 
> leading to 
> > a known next hop.
> You can't ever get that.  If you are a part of more than one 
> federation then you have to ask all of them if they can get 
> you to the destination.  You can aggregate data they give 
> you, preplan routes, and make the answer be a one step 
> lookup, but that would be something you do internally IFF the 
> federation gives you the data.  In general, in my world, they 
> don't; you don't get a full list of peers, ESPECIALLY 
> INDIRECT PEERS.  You can query for a route, and get an answer.
> 
> ...snip...
> > > Sure, as you say below, and I agree with your contention that a 
> > > transit network looks like a federation of 2.  And I 
> agree that if 
> > > you query that transit network's registry, you should see all the 
> > > TNs it can get you to.
> > > Why you care what federations it is using to terminate 
> your traffic, 
> > > or why you think it will TELL you what federations it is using is 
> > > beyond me.
> > 
> > Go back to the idea that a federation identity is short-hand for 
> > identifying whether you can both communicate by the same 
> rules.  You 
> > need to know this one way or the other, or you are just 
> making random 
> > calls that will likely fail because you aren't following the rules.
> Sure, but in this case it's you and the transit network 
> agreeing on rules.
> That DOES NOT mean that it has the same rules with each 
> federation it connects to, and DOES NOT mean it tells you HOW 
> it routes your calls.  It only tells you that if you give it 
> that call, it can, and will, route it according to the rules 
> it has agreed with you.
> 
> You may have more than one choice, each of which has a rule 
> set.  Any of those networks may have more than one route.
> 
> > 
> > 
> > > >The access to the private database
> > > > that gets from the Transit VSP to the terminating VSP can
> > > be private.
> > > Hmm, well somehow, the transit network has to tell you 
> that it CAN 
> > > terminate your call.  I agree it doesn't have to tell you how it 
> > > does that.  If the query is, as I posit, by TN, then it 
> has to give 
> > > you access to some mechanism that will tell you if it can 
> terminate 
> > > your call which you query by TN.
> > >  I think that is a registry.
> > 
> > Again, route to domains not TNs.
> > 
> > The "somehow" and "some mechanism" is what I am calling a 
> federation.
> > When you know you share a federation with the next hop, you 
> know the 
> > rules to follow.
> I'm working on how you know that the federation has any route 
> to the destination, and if it does, what the Request URI 
> should be for next hop.
> AFTER that, then I "know I share a federation with the next 
> hop".  Before I do, I don't really care what the rules are.
> 
> ..snip...
> > > If we all converge on a small set of federations, and those 
> > > federations are all interconnected by some kind of 
> indirect peering, 
> > > so that from anywhere there is a path to anywhere else, then what 
> > > you are looking for may happen.
> > > Right now, that isn't in anyone's horizon, even if they 
> would like 
> > > it to be true.  There is still way too much jockeying for 
> position 
> > > to get universal connectivity.
> > >
> > > Now if we gave up on federations, and just used the Internet, why 
> > > all of those problems disappear.
> > 
> > I am trying to use the Internet, by routing to domains, but 
> you keep 
> > focusing on routing to TNs.  But, the Internet alone is not 
> sufficient.
> > We need to know that we can connect to those domains via 
> well-defined 
> > rules.  Otherwise, we end up with no accountability and SPIT.
> Federations don't exist for that purpose.  Federations exist 
> because carriers refuse to peer on the Internet for revenue, 
> QoS and control issues.
> 
> 
> You don't need the kind of federations we are talking about 
> for identity, although it helps, and identity is the key to 
> accountability and SPIT.
> Eventually, we WILL route on the Internet, but then it will 
> be simple DNS domain resolution.  We won't need federations.
> 
> Federations don't want to use the Internet to route.  They do 
> that privately.  None of the routing data is allowed to be 
> public.  There are very, very few carriers who are willing to 
> put ANY form of routing data in the public DNS.
> 
> 
> > > > What is the means by which you identify the "route"?
> > > You ask each of your federations if they can terminate 
> your call.  
> > > Any of them who answer yes is a candidate route.  Then you need a 
> > > metric to choose.
> > 
> > Seems like a lot of quries with false hits.
> Well, it depends on exactly how you get the routing data.  
> True if the federation doesn't give you the entire database 
> for your internal use.  If it does, you can do your own 
> aggregation and make a single query to your own database and 
> get the answer in one query.  In reality, you probably don't 
> get that, especially for indirect peers, and you have to 
> launch actual queries to each federation, and they may have 
> to refer the query to their indirect connections if they 
> don't get a match.
> 
> "Getting the entire database" is the route advertisement 
> approach.  I don't think we want to go there yet.  It works, 
> and it's efficient, but it gets complex quick.  Query and 
> referral works (somewhat like DNS, but you don't have 
> hierarchy to help your caching resolver)
> 
> ...snip...
> > It is practical to have all Transit VSPs interconnecting with each 
> > other.  That was the idea behind having a Transit-oriented 
> Federation.
> I think this is laughably wrong.  You are positing that there 
> are a set of transit carriers who will ALL agree to peer with 
> ALL other transit networks in the world.  You are 
> re-inventing the U.S. IXC scheme.
> 
> Who would agree to such a thing?  Think international.  My 
> gosh, just think how you would do that in the U.S.?  Do you 
> seriously think there is ANY transit carrier who could wangle 
> transit from ALL federations?  Not a chance.  That would take 
> regulation.
> 
> It doesn't happen on the Internet.
> 
> I think there are a set of carriers who THINK they can do 
> this.  I wouldn't want to build a system that would fail if 
> it happened.  I just think it's not possible to ASSUME such a 
> thing globally. 
> 
> I think the interconnects will be much more complex.
> 
>  
> > 
> > > >
> > > > The Transit VSP routing table could also list thousands of VSPs 
> > > > associated with a route.  But, if those groups of 
> thousands were 
> > > > associated with respective federations, then your table
> > > could be much
> > > > smaller if each thousand were replaced with a single
> > > federation:route
> > > > entry.  Could the INVITE then be:
> > > >
> > > > SIP: Target URI
> > > > Route:Transit VSP
> > > > Route:Federation URN?
> > > Well, as I said way earlier, there is this idea some relatively 
> > > small number of SPEERMINT participants think will happen 
> where you 
> > > can query the public DNS by TN for VSP, and then you need 
> something 
> > > that tells you route by VSP.
> > > I don't think that is going to happen.  I think you query 
> a private 
> > > federation run database by TN, and you get next hop directly; you 
> > > don't know who the termination VSP is.  The result of the query 
> > > becomes your Request URI and there is no Route header.
> > > >
> > > > > The only scenario where you know the VSP before you know
> > > the route
> > > > > is where there is a registry independent of the federation.
> > > >
> > > > I would call that registry the DNS.  I think you are
> > > putting the cart
> > > > before the horse.  Find the destination peer, then the route to 
> > > > get there.
> > > Yeah, I would call that registry the DNS too.   That 
> isn't happening.
> > >
> > > Brian
> > 
> > Just wait and see!  :)
> > 
> > Mike
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 20 Oct 2006 17:36:09 -0400

Inline. 

> Sent: Friday, October 20, 2006 5:09 PM
> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl'
> Cc: [email-masked]
> This requires you to obtain information you will probably not 
> be allowed to know.  Specifically, it requires transit 
> carriers or federations to advertise all of their peers to anyone.
> 
> I don't think this is acceptable.
> 
> You can ask the question: can you get me to X?
> You cannot ask the question: who can I contact to get me 
> directly to X?

I am assuming that if A uses a Transit VSP X, then A certainly better
know how to get to X.

> You MIGHT get the end domain to tell you all of the paths to 
> them.  I suspect not, for all carriers, but maybe.  What I 
> don't think you will get is a complete list of peers for a 
> domain or a federation.

I am not looking for a list of peers in the federation.  I am looking
for a target domain to be able to tell me either what Transit VSP Y
serves it, or what federation it belongs to from which I can learn of a
list of Transit VSPs that serve that federation.  It might be in the
interest of a Transit VSP to advertize that they have federations
covered or perhaps run the federation. 

> Furthermore, unless you are part of a federation, you cannot 
> ask anything of them.  They certainly aren't going to put all 
> of their routes in a public database.

You mean like the LERG? or the LNP Database?  
Careful, this could become a regulatory issue.

> I believe federations and transit networks are NOT going to 
> advertise their peers.  That is competitive information, and 
> it's not going to be public, or even semi private (i.e. just 
> because you are part of some federation which has a route to 
> X doesn't mean that you can be told all of the peers of a 
> federation your federation has a transit network connection to). 
> 
> I'm not even sure they will allow a traceroute equivalent; 
> they may hide vias.  I hope we don't get to that level.
> 
> Also, if we are only looking at domains, an iterative search 
> as you suggest is not at all different from a referral 
> mechanism I suggest, especially if you allow multiple routes. 
>  Your mechanism would not work for TNs, while mine would.  

I definitely am not trying to route on TNs.

> You are searching from destination towards origination, and 
> I'm searching from origin towards destination.  I'm using 
> route aggregation data, you are using direct route listings.  
> It is a little simpler to use direct route data if you can 
> get it.  However, it doesn't work if you DO have to move to a 
> dynamic routing engine.  My solution would migrate to a BGP 
> like route engine.  Yours would not.

I think that a BGP like mechanism is the wrong way to go, so I don't see
that as a problem.

> Of course, the fundamental problem remains you assume you 
> know the termination domain.  I don't think you can figure 
> that out when you start with a TN unless all TNs are in a 
> public database.
> 
> Brian

Correct, I am starting from the ENUM assumption that defined the
boundary of the problem that Speermint was supposed to solve, namely
routability toward SIP URIs not routing on TNs.  If we want that, the
PSTN does it extremely well.

Mike

> > Sent: Friday, October 20, 2006 4:16 PM
> > To: Brian Rosen; Stastny Richard; Otmar Lendl
> > Cc: [email-masked]
> > It doesn't necessarily have to ALL be public.  The part 
> about how the 
> > originating Transit VSP knows how to connect to the Transit VSP 
> > serving the terminating VSP could very well be by private peering 
> > arrangements between the Transit VSPs.
> > 
> > This is a series of questions that should be answerable:
> >       Transit
> > A-----X-----Y-----B
> > 
> > Can A get to B directly?  Yes/No
> > If no, is B served by someone?  Yes:Y
> > Can A get to Y directly?  Yes/No
> > If no, is A served by someone?  Yes:X
> > Can X get to Y directly?  Yes/No
> >   (Note this is where it can spiral, but SPs do a good job
> >    of taking care of the X to Y connectivity.) If yes, A 
> sends call to 
> > X who sends to Y who sends to B.
> > Call successful because peering relationships exist on all segments.
> > 
> > Note also that each of those "directly" queries is simply asking if 
> > the sender has a peering relationship as identified by a name (i.e.
> > federation identity).  It is a simple question that should have a 
> > simply obtainable answer.
> > 
> > Mike
> > 
> > 
> > > Sent: Friday, October 20, 2006 3:57 PM
> > > To: 'Stastny Richard'; 'Otmar Lendl'
> > > Cc: Michael Hammer (mhammer); [email-masked]
> > > Then Richard, we are done.
> > >
> > > User ENUM, DNS SRV, Internet Peering.  We need nothing else.
> > >
> > > I do believe that eventually, carriers will be disintermediated, 
> > > especially at the enterprise level.
> > >
> > > But we aren't there yet, and we have a lot of service 
> providers who 
> > > want to do this, with the private stuff.
> > >
> > > It's not heresy.  The solutions WILL work on the Internet.
> > > They will also work on private IP networks.
> > >
> > > But if a proposed solution ASSUMES a public database, 
> then it won't 
> > > work.
> > >
> > > In this case, it also means if it assumes a single tree 
> it won't be 
> > > acceptable.  Nothing that assumes a single tree where any carrier 
> > > can see the whole tree will be acceptable.
> > >
> > > There isn't going to be ONE enum tree, there are going to be many 
> > > There isn't going to be ONE routing database, there are 
> going to be 
> > > many
> > >
> > > Brian
> > >
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Friday, October 20, 2006 3:27 PM
> > > > To: Brian Rosen; Otmar Lendl
> > > > Cc: Michael Hammer (mhammer); [email-masked]
> > > > >I don't LIKE that, but it's what is happening.  Carriers don't 
> > > > >put ANY
> > > > route
> > > > >data in the public DNS.
> > > >
> > > > I do not like it either.
> > > > So the IETF is taken over by the carriers?
> > > >
> > > > We dump 20-30 years of development and start rebuilding 
> the PSTN 
> > > > on IP?
> > > >
> > > > I do not think that this is the charter of SPEERMINT, this
> > > may be the
> > > > task of 3GPP, ETSI TISPAN and ITU-T
> > > >
> > > > I also agree with Mike here:
> > > >
> > > > > I think that any middlemen that add no value will be 
> > > > Richard
> > > > ________________________________
> > > >
> > > > Von: Brian Rosen [mailto:[email-masked]]
> > > > Gesendet: Fr 20.10.2006 20:00
> > > > An: Stastny Richard; 'Otmar Lendl'
> > > > Cc: 'Michael Hammer (mhammer)'; [email-masked]
> > > > Betreff: RE: [Speermint] Basic Peering Requirements
> > > >
> > > >
> > > >
> > > > > So 3GPP, GSMA and ETSI TISPAN have to rewrite their 
> specs (e.g.
> > > > >
> > > >
> > > 
> http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=pd
> > > f&
> > > > ns_u
> > > > > rl=[http://www.gsmworld.com/documents/ireg/ir67.pdf]
> > > > Maybe.  As I said, it's an optimization, but a useful one.
> > > >
> > > > > But they now detect that they also have to interconnect to 
> > > > > others and global interconnection can only be in the 
> long range 
> > > > > in the global DNS. So sometimes they have to come out 
> of their 
> > > > > private playgrounds
> > > > Nope, no routing will be in the global DNS.  The transit
> > > interconnects
> > > > will be private, and the reachability data will be private.
> > > >
> > > > I don't LIKE that, but it's what is happening.  Carriers
> > > don't put ANY
> > > > route data in the public DNS.
> > > >
> > > > It's pretty straightforward to describe the scheme so that
> > > it works on
> > > > the public DNS, I just don't think it will actually be
> > > deployed that way.
> > > > Also,
> > > > if you have more than one choice of path, you can't do 
> that with a 
> > > > simple lookup, and if you have to do a series of lookups,
> > > making one
> > > > choice from a list at every step, then you're playing my song.
> > > >
> > > > The problem here is a multi step route determination.  
> We have a 
> > > > constellation of federations, and set of transit 
> carriers making 
> > > > connections between them in non simple ways.  At any 
> point in the 
> > > > graph, you may have multiple choices.  The problem is to
> > > find a path.
> > > > It's not a simple one stage lookup, it's a path 
> discovery.  It's a 
> > > > ROUTING problem.  We know how to solve routing 
> problems.  In this 
> > > > case, we don't yet need a dynamic route advertisement
> > > protocol, we can
> > > > get away with simple query or query and referral.
> > > >
> > > > It's classical routing: you either start at the origin and look 
> > > > through all paths at every branch until you get to the
> > > destination, or
> > > > you feed forward the aggregated route advertisements from
> > > the next hop
> > > > to the leaf.  The former is easy if the graph is not
> > > horribly complex.
> > > > It would be better to feed forward aggregated routes.
> > > However, the TN
> > > > to domain mapping is highly unlikely to work that way (not all 
> > > > registries will allow their data to be aggregated).  If 
> you need 
> > > > to support referral, then you might as well make the whole 
> > > > mechanism query and referral.  You can cache, which helps with 
> > > > domains, but doesn't help with TNs.
> > > >
> > >
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 23 Oct 2006 15:48:32 -0400

And yet Number Portability lives!

Umm, I live about 7 miles from that beltway and my Congressman knows me
by name and sight.  And not all of them think the same way.

Mike

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 12:19 PM
> To: Michael Hammer (mhammer); 'Otmar Lendl'
> Cc: [email-masked]; 'Nieminen Klaus'
> > Sent: Monday, October 23, 2006 12:01 PM
> > To: Otmar Lendl; Richard Shockey
> > Cc: [email-masked]; Nieminen Klaus
> > Concerning de-regulation:
> > 
> > If a group were to try to keep the system closed and certain call 
> > routing information private, whether intentionally or 
> unintentionally 
> > to raise barriers to competition; I think the regulators would feel 
> > compelled to step in and make such call routing information 
> publicly 
> > available.
> 
> Now you are really waist deep in it ... what country are you 
> living in :-) ?
> 
> 
> Obviously you do not live in the proximity of US 495 aka the 
> "Beltway".
> 
> 
> 
> > 
> > So, if you want to keep the regulators idle, design the 
> system so that 
> > any VSP that can reliably authenticate themselves can take the 
> > sequence of steps that leads them to the ingress points and allows 
> > them to deliver calls to another VSP.  The key is having secure 
> > controls versus having static clubs.
> > 
> > Mike
> > 
> > >
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 23 Oct 2006 16:10:59 -0400

Penn,

Well stated.

Mike

> From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 2:51 PM
> To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; 
> Richard Shockey
> Cc: Nieminen Klaus; [email-masked]
> We can continue to beat this topic to death (and I'm sure we 
> will) but I want to make one point.
> 
> We need to distinguish between peering for voluntary exchange 
> of traffic (not currently regulated at least in the US) and 
> Peering as a replacement for legally required interconnection 
> in the current PSTN. 
> For the former carriers (and anyone else) can and will do 
> what they want. The latter is likely to eventually be subject 
> to some rules. But consider also that where interconnection 
> is mandated it comes with rules and is not open to all parties.
> You want to interconnect with the PSTN in the US you need to 
> be certified; otherwise you buy end user services.
> 
> BTW If you put all allocated (including unassigned) numbers 
> in the DNS then you provide no more info than can be obtained 
> by war dialing every legitimate sequence.  
> 
> Sent: Monday, October 23, 2006 2:34 PM
> To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey'
> Cc: 'Nieminen Klaus'; [email-masked]
> Well, here in the U.S., the stated reluctance of the 
> regulator to permit TNs in a public database is due to the 
> fact that people's telephone numbers would be in a public 
> database.  They are concerned with the privacy aspects of the 
> problem.  So, they actually WANT private databases where 
> people's telephone numbers are concerned.  And this concern 
> started in User ENUM, not just infrastructure ENUM.  I 
> understand there are other regulators who have this concern.
> 
> I do think there is some validity to your concern about one 
> carrier, or a group of carriers, restricting access to their 
> customers for termination from other carriers, and I agree 
> the regulators would probably not allow it.
> Making routing data public has not yet been, and I don't 
> think will be, the remedy.  
> 
> Brian
> 
> > Cc: Nieminen Klaus; [email-masked]
> to
> > raise barriers to competition; I think the regulators would feel 
> sequence
> > of steps that leads them to the ingress points and allows them to 
> > deliver calls to another VSP.  The key is having secure controls
> versus
> > having static clubs.
> > 
> > Mike
> > 
> > 
> > > From: Otmar Lendl [mailto:[email-masked]]
> > > Sent: Monday, October 23, 2006 11:40 AM
> > > To: Richard Shockey
> > > On 2006/10/23 17:10, Richard Shockey <[email-masked]> wrote:
> > > >
> > > > > There are several arguments why carriers will never put
> > > there TNs in
> > > > > public ENUM trees, e.g.:
> > > > > - "Carriers are afraid that others can query how many
> > > > > numbers(customers) they have."
> > > > > - "Carriers are afraid that other carriers can find out
> > > the current
> > > > > carrier-of-record of an enterprise and to poach this customer"
> > > >
> > > > Both of these arguments as you mention are completely specious..
> > >
> > > We know. Klaus just quoted what we sometimes hear from carriers.
> > > You know, they don't always make sense.
> > >
> > > > > maybe others can tell us why carriers never will put
> > > there numbers
> > > > > into public infrastructure ENUM?
> > > >
> > > >
> > > > The real reason carriers will never put their numbers into
> > > any form of
> > > > public infrastructure ENUM is two fold.
> > > >
> > > > A. Only a mad man would put the location of critical 
> VoIP ingress 
> > > > elements edge or otherwise into a public DNS 
> infrastructure. The 
> > > > potential for DDoS alone is massive.
> > >
> > > Agreed. That's the reason we developed the domain policy DDDS 
> > > proposal which can used to really de-couple the URI from 
> the ingress 
> > > elements.
> > > E.g. if the only things you can learn from the public DNS is that 
> > > example.com is a member of federation X and Y, and uses
> > >
> > > fedx-ingress.example.com 	A	10.0.0.42
> > >
> > > and
> > >
> > > fedy-ingress.example.com 	A	172.27.10.10
> > >
> > > as the ingress elements on the respective shared L3 
> infrastructure 
> > > then I don't see the DDoS potential here.
> > >
> > > > B. Infrastructure ENUM as it has been proposed almost 
> guarantees 
> > > > national regulatory delegation and oversight and most
> > > carriers are in
> > > > favor of DE-Regulation of telecom not RE-Regulation.
> > >
> > > Wait a second: you're now switching from the issue of a 
> public tree 
> > > to the question of whether that should be a NRA-approved 
> one under 
> > > ie164.arpa.
> > >
> > > If the regulator proves to be a burden in all this, then nothing 
> > > stops an industry consortium to establish a tree under a 
> different 
> > > apex. (As the forest of trees out there shows.)
> > >
> > > > C. Some form of trusted registry of TN 2 URI mappings is
> absolutely
> > > > necessary to insure interoperability but I suspect it will
> > > be carriers
> > > > them selves that attempt to control the organization and
> > > distribution
> > > > of such data.
> > >
> > > Oh yes. Who argued against the carriers establishing a 
> such a tree?
> > >
> > > IMHO the best case is if the regulators *and* the carries 
> agree on 
> > > someone who runs that trusted registry. Whether that will 
> then be a 
> > > private tree or a public one, is an independent question.
> > >
> > > Given the fact that the number of "carriers" is bound to increase 
> > > and international resolution of TN->URI will be an issue, I doubt 
> > > that it will be easy to establish a sensible, universal 
> rule which 
> > > describes who should have access to that private tree.
> > >
> > > Once the number of organizations which have access to a 
> private tree 
> > > exceeds as certain number, the security benefits you get from 
> > > keeping it non-public are dwarfed by the complexities of 
> maintaining 
> > > access control rules.
> > >
> > > Or, as other events prove every now and then, the PSTN method of 
> > > maintaining security ("trust all other carriers") is already 
> > > breaking down right now. So why perpetuate that model?
> > >
> > > It's just case of security by obscurity.
> > >
> > > /ol
> > > --
> > > < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> > >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 23 Oct 2006 16:49:30 -0400

What is visible depends on how you set things up.  If the public aspect
points you to the next hoop through which you need to authenticate and
get authorized to pass, then very little has been revealed.

Mike

> From: Jim Reid [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 4:38 PM
> To: Reinaldo Penno
> Cc: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; 
> Richard Shockey; Nieminen Klaus; [email-masked]
> On Oct 23, 2006, at 21:10, Reinaldo Penno wrote:
> 
> > I must be missing something here.
> 
> True. :-)
> 
> > Telephone numbers are already public in the US (they have to be).  
> > To be de-listed you have to pay extra but law enforcement in the US 
> > are still notified of such unlisted phones. I can get a paper 
> > telephone directory and lookup any telephone number. I can go to 
> > Verizon's or ATT's (in the US) home page and perform a 
> reverse lookup 
> > and find the telephone number associated with a name (and 
> vice-versa).
> 
> Although phone numbers are sort of public, other things 
> related to telephony service are not. [Or at least not easily 
> determined by the general public.] These include stuff like 
> which company provides service for a given number, which 
> number(s) in a company's "allocation block" have been ported 
> or are not in use, where the telco's interconnect points are, 
> what type of hardware they use, etc, etc. With SIP peering, 
> the analogues of these things could become visible to 
> everyone: eg the name and addresses of the company's SIP 
> servers that act as their internet/PSTN gateways. Telcos tend 
> to consider this kind of thing to be sensitive data.
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 24 Oct 2006 15:17:05 -0400

Brian,

Standards are a part of education when they show how it could be done
for those that have doubts about its technical feasibility.  You also
seem to miss the key point that terminating VSPs can choose to publicly
advertize their reachability, if they so choose, just as I hand out my
phone number on a business card.

But, the ugliest fact of all is that voice revenues are falling, and any
dilution of those revenues across extraneous carriers will bring ruin on
all of them.  So, it is in their best interests to devise the most
efficient mechanism possible.

If making a phone call were as simple as clicking on a Web site, do you
think all those arbitrarily complex ways you hold dear will last long?
Take heed, "google you" may some day mean a click to dial SIP session
rather than just a web search.

Mike

> Sent: Tuesday, October 24, 2006 2:56 PM
> To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar 
> Lendl'; 'Richard Shockey'
> You seem to have fallen into the trap of believing that you 
> can right a regulatory wrong by defining standards that only 
> permit "right" behavior.
> 
> That never works.
> 
> You can try to change behavior by education, but not by 
> standardization.
> All the attempts to do that fail, and usually make poorer 
> results; the folks left on their high horses are all alone, 
> the rest of the world is somewhere else, perhaps not as 
> righteous, but functioning.
> 
> Penn and company think they can fix the issues.  I have my 
> doubts, and until they succeed, I think we should concentrate 
> our efforts in working with today's reality and not tomorrow's hope.
> 
> With respect to route simplicity, again I think you are in 
> the wishing and hoping crowd rather than the ugly reality 
> crowd.  Here among the uglies, we don't assume miracles like 
> all federations agreeing to admit any transit carrier who 
> comes a'callin, or transit carriers that step up to 100% 
> interconnect right off the bat, or other fanciful dreams.  In 
> this case, there isn't regulatory or customary practice 
> problem, there are just immensely complex, and expensive 
> buildout requirements and commercial rivalries that get in 
> the way of nice simple solutions.
> 
> In any event, a solution that had a hard limit is definitely 
> not possible; you HAVE to assume that some routes will be 
> long.  If the usual case was 3 hops, we might engineer 
> systems that were optimal there, and made other situations 
> less optimal.  Right now, I don't even see the common 
> international case being that easy, although the domestic 
> calls might often be 1-2 federations and 0-1 transit carriers.
> 
> Brian
> 
> 
> 
> > Sent: Tuesday, October 24, 2006 2:39 PM
> > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey
> > > Sent: Tuesday, October 24, 2006 12:55 PM
> > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar 
> > > Lendl'; 'Richard Shockey'
> > > I'm sure we can converge.  Any public database can be 
> made private 
> > > and vice versa, if the parties agree.  One of the things that IS 
> > > hard to do is to make assumptions that the origination 
> network can 
> > > find out things about the termination network.  I think if you 
> > > insist on that, we would have problems.
> > 
> > I understand the complexities and obstacles that some of 
> the current 
> > regulations impose that are counter-productive to an 
> effective solution.
> > That doesn't mean I am willing to accept the status quo.  
> Rules change 
> > as their makers learn what impacts they have.
> > 
> > The information about what numbers are assigned to what provider is 
> > public information and trying to obscure that will be easily 
> > circumvented.
> > 
> > > If you ask information about next hop to entities you have a 
> > > relationship with, then it works.  You can cascade that 
> out to the 
> > > termination network, but you may have some restrictions 
> on what can 
> > > be revealed backwards.
> > 
> > Unfortunately, this way of thinking runs counter to 
> liberalization and 
> > de-regulation.  It also gives false hope to those who would seek to 
> > restrict access to public number resources versus just being the 
> > fastest easiest most efficient VSP to help one connect.
> > 
> > 
> > > Unless you have some evidence that carriers are a lot 
> more friendly 
> > > than they seem to be now, I think the notion of simple routes is 
> > > doomed.  I know there are carriers who THINK they will arrange 
> > > transit to all "interesting"
> > > networks and all "interesting" federations, but I don't see an 
> > > environment where that will actually happen any time soon.
> > >  I think we will need to have
> > > 3-8 hop routing.  I don't see a problem with that.
> > 
> > But, I do see a problem with that.  The service value is at 
> the edge 
> > serving the end users.  There is very little value in the 
> middle.  I 
> > could only agree with you if the incremental billing of 
> adding those 
> > additional transit SIP hops is substantially zero.
> > 
> > > I don't
> > > even see a real problem with 10-20 as long as the media 
> doesn't have 
> > > to go that way.  That IS an argument that media might not want to 
> > > transit some active element in a
> > > federation.   We might want to give some thoughts to how we
> > > can provide
> > > transitive trust to SBCs so that we can cut out the 
> middleman in the 
> > > media path.  I'm sure each carrier will want an SBC 
> between it and 
> > > the rest of the world.  Right now, I think we're headed down 
> > > restrictions that media can only come from federation 
> partners.  If 
> > > we stay with that, the MEDIA will go through all those 
> hops.  That 
> > > would be a mistake I think.  I do understand the QoS 
> issues, but I 
> > > think we can work them out for inter federation traffic.
> > >
> > > Brian
> > 
> > Agree with the objective, but I think you achieve that by 
> getting The 
> > Max Two Transit VSPs to the point where they can connect directly 
> > using some optimal IP/MPLS path.  Additional SIP/SBC hops at that 
> > point justs muddies the picture.
> > 
> > Mike
> > 
> > >
> > > > Sent: Tuesday, October 24, 2006 12:39 PM
> > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard 
> > > > Shockey
> > > > We may not be so far apart as it might appear.  I am 
> not adverse 
> > > > to options that allow a choice of technology or privacy at
> > > each step, or
> > > > to the possibility that several steps may be combined.  
> But, we do 
> > > > need to define those steps and how policy is applied 
> and security 
> > > > assured along the way.
> > > >
> > > > We can perhaps be sure that the role of domains and the 
> > > > information from knowing a domain can lead to is better 
> understood.
> > > >
> > > > I also do not want to go the BGP-like route.  The IP layer
> > > addresses
> > > > that type of routing quite well.
> > > >
> > > > But, I do feel that complex, multi-SIP-hop routes is a sure
> > > sign that
> > > > the process is sub-optimal, both technically and
> > > business-wise.  The
> > > > quality assurance measurement aspects probably won't 
> keep up.  And 
> > > > media path optimization will probably work better with 
> fewer call 
> > > > segments involved.  We'll see.
> > > >
> > > > Mike
> > > >
> > > >
> > > > > Sent: Tuesday, October 24, 2006 7:06 AM
> > > > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar 
> > > > > Lendl'; 'Richard Shockey'
> > > > > I think federations are a useful exercise for a long
> > > time.  I want
> > > > > to do SPEERMINT, with federations, with private data.
> > > > >
> > > > > Although I can deal with TN to domain, and domain to
> > > ingress point,
> > > > > that is not ENUM, and it's not particularly efficient.
> > > > >  I'm willing to define it two step, and then allow
> > > optimization if
> > > > > it makes people feel better.
> > > > >
> > > > > I want to focus on routing by TN because the folks 
> who are all 
> > > > > worked up about private routing data only use TNs.  I'm
> > > not opposed
> > > > > to having federation solutions involving domains, but 
> I'd prefer 
> > > > > they were explicitly domains and not URIs.
> > > > > Whatever we base routing on, I really want to work with the 
> > > > > basic Internet routing scheme of reachability advertisements.
> > > > >  I can, and prefer, to do this in a very simplistic way now.
> > > > > I don't want to deal with BGP like issues for a long 
> time.  I do 
> > > > > think we have to deal with number porting with several minute 
> > > > > updates.  I think we have to deal with complex, 
> multihop routes, 
> > > > > especially for international routes.  I think we have to
> > > deal with
> > > > > federations who compete, and transit providers who 
> compete, and 
> > > > > carriers who compete at multiple levels.
> > > > >
> > > > > I want to do something new.  I have no interest in
> > > re-inventing the
> > > > > PSTN.  I just have to deal with carriers who grew up with
> > > the PSTN
> > > > > and think a certain way.  We can move them a great 
> deal, but we 
> > > > > can't get them to give up on a few ideas yet, like how public 
> > > > > the routing data is.
> > > > >
> > > > > Brian
> > > > >
> > > > > > Sent: Monday, October 23, 2006 4:43 PM
> > > > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar 
> Lendl; Richard 
> > > > > > Shockey
> > > > > > You don't want to talk about federation, yet that 
> is just an 
> > > > > > expression for a type of peering.  So, you want to do
> > > > > Speermint, you
> > > > > > just don't want to do peering???
> > > > > >
> > > > > > You want to skip dealing with domains, which is the host
> > > > > part of a SIP
> > > > > > URI and remain focused on routing based on TNs.  So, I
> > > > > presume we just
> > > > > > use tel:URIs?
> > > > > >
> > > > > > Today, DNS is how you end up with an IP address which is
> > > > > routing data
> > > > > > that allows you to put a data packet into the network.
> > > > > But, you don't
> > > > > > want any of that to be "public", but rather shared among a
> > > > > closed group.
> > > > > >
> > > > > > Sounds like you already have the ideal solution.  It's
> > > > > called the PSTN.
> > > > > > You seem to be arguing against doing anything new.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > > > Sent: Monday, October 23, 2006 4:10 PM
> > > > > > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 
> > > > > > > 'Otmar Lendl'; 'Richard Shockey'
> > > > > > > > We need to distinguish between peering for voluntary
> > > > > exchange of
> > > > > > > > traffic (not currently regulated at least in the US) and
> > > > > > > Peering as a
> > > > > > > > replacement for legally required interconnection in the
> > > > > > > current PSTN.
> > > > > > > > For the former carriers (and anyone else) can and
> > > will do what
> > > > > > > > they want. The latter is likely to eventually 
> be subject 
> > > > > > > > to some
> > > > > > > rules. But
> > > > > > > > consider also that where interconnection is mandated it
> > > > > comes with
> > > > > > > > rules and is not open to all parties.
> > > > > > > In the U.S., and I suspect in other countries, if anyone,
> > > > > including
> > > > > > > a less regulated (can't really say unregulated) carrier
> > > > > were to put
> > > > > > > its numbers in a public database, I am quite certain
> > > > > there would be
> > > > > > > an uproar, and I'm pretty sure the regulator would act.
> > > > > That kind
> > > > > > > of thing is just too sensitive these days.
> > > > > > >
> > > > > > > Since there were some objections even to OPT-IN
> > > > > scenarios, I think
> > > > > > > the whole area is fraught with difficulty.  YMMV.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > in the DNS
> > > > > > > > then you provide no more info than can be obtained by
> > > > > war dialing
> > > > > > > > every legitimate sequence.
> > > > > > > And I repeat, I am firmly in the camp that believes
> > > security by
> > > > > > > obscurity is not real security.  However, we deal with
> > > > > perceptions
> > > > > > > as well as truths and since we're looking for practical
> > > > > answers to
> > > > > > > real world problems here, I think we need solutions for
> > > > > all routing
> > > > > > > data not in public databases.
> > > > > > >
> > > > > > > If the world ran the way I, personally, wanted, we'd
> > > peer on the
> > > > > > > Internet, and we wouldn't need federations.  The 
> reality is 
> > > > > > > quite different.  I'd like to not waste my time 
> in this WG 
> > > > > > > working on solutions that don't get widespread adoption.
> > > > > > > Been there, done that.
> > > > > > >
> > > > > > > If you assume ANY public routing data, it's my
> > > opinion you have
> > > > > > > a solution that will not be widely implemented.  If
> > > you have a
> > > > > > > solution that works with all private databases, we have a
> > > > > chance.
> > > > > > > That means the word "DNS", at least a public DNS,
> > > can't appear
> > > > > > > in the answer.  I don't like that situation.  I'd like to 
> > > > > > > eventually change the perceptions that make that 
> situation 
> > > > > > > arise, but in the mean time, I'd like to get VoIP to VoIP 
> > > > > > > traffic off the
> > > > > PSTN please.
> > > > > > >
> > > > >
> > >
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 26 Oct 2006 11:15:19 -0400

> regarding public routing info:
> There are several arguments why carriers will never put there 
> TNs in public ENUM trees, e.g.:

Most carriers are traded on public stock exchanges where regulatory
rules dictate the disclosure of subscriber counts.  I am not sure this
is a big deal in reality.

> - "Carriers are afraid that other carriers can find out the 
> current carrier-of-record of an enterprise and to poach this customer"

Probably a valid fear on some level.  But you could just as easily
figure out who hosted an enterprises' website or email domain and try to
poach that service.  If someone wants to find this information out, they
can.  I'd suggest, therefore, that this fear, if it exists pervasively
inside of enterprise service providers, is irrational (like many fears
perhaps). 

> IMO this arguments are not valid, because this information 
> can be retrieved easily also in the current TDM world - at 
> least in Austria.

And in other places as well, especially those with number portability.  

> maybe others can tell us why carriers never will put there 
> numbers into public infrastructure ENUM?

I think perhaps there are two concerns I have heard (not that I agree
with them) -

1 - Security through obscurity of the interconnection points on public
and private IP networks.  But these gateways must be secure no matter
whether the address is published in a public database or not - someone
will find it and probe it eventually and it must be secured with this
assumption in mind.

2 - Security of the TNs / user portion of the SIP URIs.  In email, many
SPs try to hide the list of users (perhaps similar to list of TNs) to
prevent spam.  So perhaps they want to extend that and hide the user
portion of the URI, which is the TN, to prevent SPIT.  The only problem
is that you need such a TN in order to discover the SIP URI and discover
the domain portion - so this position kind of falls apart...

Jason