Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 20 Oct 2006 12:25:02 -0400

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.

More inline...  (Then I let it stew a bit.)

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 7:39 PM
> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar 
> Lendl'; 'Daryl Malas'
> Cc: [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> Wow, lots to disagree with ;)
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, October 19, 2006 3:21 PM
> > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Basic Peering Requirements
> > 
> > Inline.
> > 
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Thursday, October 19, 2006 2:27 PM
> > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl'; 
> > > 'Daryl Malas'
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Basic Peering Requirements
> > >
> > > I'm not advocating a particular solution, but, in 
> general, I do want 
> > > the ability to determine if a particular route (=federation or 
> > > transit network I directly peer to) can get my call terminated 
> > > correctly.
> > 
> > This seems like chicken and egg problem.  Were did your 
> route come from?
> 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 we both want to know that sending the next 
> signaling message 
> > will result in a call setup.
> Agree, of course
> > 
> > > It's quite acceptable, and
> > > maybe optimal to just give me the info (which might be 
> list of VSPs, 
> > > but see below).  It may be acceptable to just let me 
> query for that 
> > > (can I reach this VSP from you?).
> > 
> > Not sure what you mean by info.  What type of query are we talking 
> > about?
> One way to do this is to provide a query to the federation: 
> can you terminate a call to this VSP?  As I discuss below, I 
> don't think you really do this, because I think you don't 
> have a TN to VSP database, but if you did, then a query to 
> the federation by VSP with a yes/no answer is a satisfactory solution.
> 
> 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.

> Another is an announcement.  That really is a routing 
> protocol, and I don't think we need that, at least yet.

Agree, I don't want a protocol to spam the network with.

> > What does the query get you?  Are you talking a trial an 
> error approach?
> 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.

> > > What I don't need is the set of federations a VSP belongs to.
> > >  I don't care a whit what federations they belong to.  I 
> only want 
> > > to know which of my routes can get me to them.
> > 
> > The federation is only a mechanism for finding a route.  You are 
> > positing the existence of a route in advance.  In other words, you 
> > seem to be assuming a solution and then some test to verify 
> that it works.
> 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.

> > 
> > > The number of VSPs is a small number in today's technology.
> > 
> > What do you mean by VSP?  I am assuming any organization 
> that operates 
> > a voice service and serves endpoints, which would include IP-PBX of 
> > enterprises.  If you aren't counting them, then you have 
> underestimated.
> Well, one of the reasons I say it's a TN based query is that 
> I don't really care how many VSPs there are.  I further posit 
> that some federations will deliberately obscure what happens 
> behind their curtain; they won't tell you WHO they peer with 
> directly, they will only give you the aggregate data.
> 
> So, I don't care if it's 100, 1000, a million, or tens of 
> millions.  I'd rather it be billions (one per TN).  Works for me :)
> > 
> > > It's entirely feasible to have a single database with every TN in 
> > > the world.
> > > That is a big database, but not beyond current single database 
> > > technology.
> > > The number of VSPs is small in database terms.  This is a 
> database 
> > > problem.
> > >
> > > Let's open this up a little more.
> > >
> > > If some kind of public enum tree is built, whether it's 
> user enum or 
> > > infrastructure enum in the public DNS, then we can do 
> real two step 
> > > lookups of TN to VSP and then do some kind VSP to 
> something lookup.  
> > > Right now, I don't see that happening much.
> > 
> > Just having the VSP is unsufficient; that doesn't gurantee 
> they will 
> > accept your call.
> Yes, I agree with that.  Presumably if a federation 
> advertises reachability to a VSP, then the VSP will accept 
> your call via that federation, however it is done.  So, if 
> you knew the VSP, you can ask the federations if they can 
> route to that VSP and if they say yes, then that's a valid route.
> Similarly, you do know the TN, so you ask your federation(s) 
> if they can route your TN and if they say yes, then that's 
> your valid next hop route.
> > 
> > > What will happen is private databases (ENUM or otherwise).
> > > We can argue if the federation runs the database.  I 
> think it will, 
> > > one way or another.  We have some problems.
> > >
> > > One is how indirect peering TNs are handled.  Either they are 
> > > imported into the database, or the query is proxied to another 
> > > database.  Either way, you launch a query and you get 
> back either a 
> > > URI within the federation or you get an error (not 
> found).  If you 
> > > are a member of more than one federation, you may launch 
> more than 
> > > one such query, and you can get back zero, one or more 
> than one URIs 
> > > (from each query and the aggregate of all the queries).
> > 
> > If the caller must go through a Transit VSP which runs its own 
> > federation, then the TN lookup can point to the Transit VSP 
> directly, 
> > as well as identify the federation(s).
> 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.

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

> What you as originating network 
> see is the aggregated information from the transit network's 
> downstream arrangements.  You get to see something that lets 
> you figure out if this transit network can terminate your 
> call.  All of the URIs you would get back from a query would 
> be URIs in the transit network's domain (federation of 2, 
> right?).  Now, HE has access to some other registries that 
> contain different
> data: how he routes the call once you give it to him.  You 
> don't get to see them.  You see a registry that (one way or 
> another) is an aggregation of all of the downstream registries.
> 
> > The problem has now morphed into how does the caller get to that 
> > Transit VSP?  Does the calling VSP have a peering relationship 
> > directly, or must it go indirectly through yet another Transit VSP?
> Ah, yes, that is the point.  Your transit network may be a 
> peer in a federation.  Another peer in that federation may 
> itself be a transit network to yet another federation.  Your 
> transit network doesn't know how one of the peers of its 
> federation gets to the other federation, and it doesn't care.
> It doesn't even know there is another transit network; all it 
> knows is that the registry its connected to can terminate the 
> call.  The federation your transit network belongs to 
> provides it with a registry of all of the TNs it can reach.  
> That is in turn reflected to you via your transit provider, 
> along with the TNs it can reach through any other 
> arrangements it has (perhaps it is a member of several federations).
> 
> Again, this is really like route advertisements moving up the 
> chain.  You don't get in those advertisements the 
> intermediate connections, you only get your next hop route, 
> expressed as reachability by one of your peers.
> 
> > 
> > Don't get hung up on the term federation, it is just a 
> generalization 
> > of the bilateral peering arrangement.  That is, bilateral 
> peering is 
> > just the smallest federation possible; membership=2.
> YES! as above
> 
> > 
> > > This means you end up doing TN to URI in one step.  We 
> then have to 
> > > decide if you get the ingress point directly, or there is another 
> > > query for that; I suspect you get the ingress point in one step.
> > 
> > No disagreement here.  Saying that I can go from the 
> originating VSP 
> > to the terminating VSP directly, means that there is a 
> direct peering 
> > arrangement.  Saying that they both belong to the same 
> federation is 
> > saying exactly the same thing.  The more interesting question is 
> > determining when you don't have a direct peering 
> relationship (i.e. no 
> > common federation) what to do.
> Well, there is no common federation between the originating 
> carrier and the terminating carrier, and there is that 
> circumstance (no common federation), but there is a route, 
> via at least one of your federations, due to indirect peering 
> relationships it has.  Of course there is also the case of no 
> route at all, meaning even with all the indirect 
> relationships for all of your federation memberships taken 
> into account, you still can't get the call routed to the 
> destination VSP
> > 
> > > If you have one answer, that's where you send the call.  
> If you have 
> > > zero answers, PSTN gateway gets the caLL.
> > 
> > No, no, no!  The goal of this exercise is to avoid the 
> PSTN.  The only 
> > reason the PSTN should be used is when the TN is terminated 
> to a TDM 
> > switch and not reachable by IP.  You are identifying a gap in your 
> > approach, if a TN is a SIP phone terminated on a VSP and 
> you end up on 
> > the PSTN.
> Well, it would be very nice if we had some way to guarantee 
> that there always is an IP route, but so far, I don't see 
> that happening any time soon.
> 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.

> > 
> > > If you
> > > have more than one answer, you are into some kind of cost metric.
> > >
> > > The point is that you get an answer that is the route TO the VSP, 
> > > not the federation the VSP belongs to, OR EVEN THE 
> IDENTITY OF THE 
> > > VSP.
> > 
> > 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.

> 
> In my world, each of those federations has a database; you 
> query that database by TN.  You get a URI (which is the next 
> hop) or you get no record found.
> 
> > 
> > > You query by TN. You may not even be given the identity of the 
> > > destination VSP.  Your query by TN only yields next hop.
> > 
> > The next hop could also be just a default value and defer 
> the problem 
> > to the originating side Transit VSP.
> Not unless the transit VSP had direct or indirect peering 
> with each and every VSP on the planet.  I don't think such a 
> thing is practical any time soon.

It is practical to have all Transit VSPs interconnecting with each
other.  That was the idea behind having a Transit-oriented Federation.

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 13:40:27 -0400

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.

> Sent: Friday, October 20, 2006 12:25 PM
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.

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

> 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...
> send to a Transit VSP that could be derived from a couple simple DNS
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...
> want each successive lookup to result in definitive answers leading to a
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...
> 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.

> When you know you share a federation with the next hop, you know the
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...
> 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.

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

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 15:31:28 +0200

Hi Brian!

Brian Rosen wrote:
> you have to ask all of them if they can get you to the destination.  

No. Have you ever read Otmar's drafts? It is the other way round: You 
have a SIP URI, thus you have a domain. Make a NAPTR lookup of the 
domain and it will tell you to which federations it belongs.

Then you compare the result with the federations you are belonging too.

No need for asking the federation for all members and planing in advance.

regards
klaus

 > You can

-- 
Klaus Darilion
nic.at