Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 19 Oct 2006 15:20:58 -0400

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?
I think we both want to know that sending the next signaling message
will result in a call setup.

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

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

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

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

> 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).  The access to the private database
that gets from the Transit VSP to the terminating VSP can be private.
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?

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.

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

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

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

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?

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

Mike

> That just isn't really happening except in a 
> very few isolated places.  I suppose we need to give them 
> some kind of solution, but I don't care much about it, 
> because I think it's not going to be common.
> 
> Brian
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, October 19, 2006 1:00 PM
> > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Basic Peering Requirements
> > 
> > "The point is that for each route, what I want is the 
> complete set of 
> > VSPs that route can get me to."
> > 
> > So, you have entries for all VSPs on Earth?
> > 
> > When 1 Federation = N VSPs, where N can be many orders of magnitude 
> > above 1, I would contend that:
> > 
> > "The point is that for each route, what I want is the 
> complete set of 
> > Federations that route can get me to."
> > 
> > would scale better.
> > 
> > Mike
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Thursday, October 19, 2006 12:29 PM
> > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl'; 
> > > 'Daryl Malas'
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Basic Peering Requirements
> > >
> > > Which scaling limits are you working from, PSTN or the Internet?
> > >
> > > Reachability to thousands (or tens of thousands, or a 
> couple hundred
> > > thousand) VSPs is what I want.
> > >
> > > I want the "best" route to a VSP (which I may only know 
> by a TN in a 
> > > registry). A federation is one potential route.
> > >
> > > Scaling to tens or hundreds of thousands of routes is usually 
> > > considered to be quite reasonable, and even millions is quite 
> > > reasonable for L5 routing since we don't need to keep the 
> routes in 
> > > memory.  Certainly a federation returning VSP 
> reachability to that 
> > > many VSPs is easy.
> > >
> > > If all I have is one transit peer, and no federations, then I can 
> > > launch my call and if it doesn't work, all I can do is 
> send it via 
> > > the PSTN.  Same if I am only a member of one federation.
> > >
> > > As soon as I have two routes, I need to know where to send it for 
> > > the next hop.  I have the destination VSP, I choose a
> > > route: VSP in, route out.  I check my routes for 
> reachability.  If 
> > > there is only one route, I send out the call that way.  If I have 
> > > more than one route, then I need a cost metric, and we 
> don't have to 
> > > go there right now.  The point is that for each route, 
> what I want 
> > > is the complete set of VSPs that route can get me to.
> > >
> > > Seems like getting that information directly is the 
> simplest way to 
> > > go.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > > > Sent: Thursday, October 19, 2006 10:46 AM
> > > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas
> > > > Cc: [email-masked]
> > > > Subject: RE: [Speermint] Basic Peering Requirements
> > > >
> > > > Brian,
> > > >
> > > > Which would you rather maintain and advertise:
> > > >
> > > > reachability to a hundred federations, or reachability to
> > > millions of
> > > > VSPs?
> > > >
> > > > What you suggest doesn't scale.
> > > >
> > > > The idea here was that once you know that a VSP belongs to a 
> > > > federation (via ENUM and DNS), you are now looking for 
> information 
> > > > that your Transit VSP supports that federation and to which
> > > signaling
> > > > address of the Transit VSP to send the next signaling message.
> > > >
> > > > Isn't that simpler?  Don't know why you want to make it harder.
> > > >
> > > > There can be an address from which a federation 
> membership can be 
> > > > fetched, but I would rather be pointed to the answer, than 
> > > > scanning through lengthy membership lists to discover 
> relationships.
> > >  I think
> > > > the main value is in having a federation point to the Transit 
> > > > providers serving a federation only.  That should be a much 
> > > > smaller list.  But, that step would not be needed by the
> > > originating VSP if it
> > > > already knows what federations its own Transit VSP 
> serves and the 
> > > > terminating federation is on that list.
> > > >
> > > > In summary, routing towards federations as an aggregation 
> > > > mechanism rather than individual VSPs scales better.
> > > >
> > > > Mike
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Brian Rosen [mailto:[email-masked]]
> > > > > Sent: Wednesday, October 18, 2006 1:55 PM
> > > > > To: Michael Hammer (mhammer); 'Stastny Richard'; 
> 'Otmar Lendl'; 
> > > > > 'Daryl Malas'
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [Speermint] Basic Peering Requirements
> > > > >
> > > > > To me, this is off the deep end.
> > > > >
> > > > > I think we don't care what federations a destination
> > > network belongs
> > > > > to.
> > > > > Sorry Otmar.
> > > > >
> > > > > I think a federation may advertise what peers it can get
> > > you access
> > > > > to.
> > > > > That may include transit peers, and those transit peers
> > > may get you
> > > > > to other peers through other federations.  The federation
> > > advertises
> > > > > the aggregate of what networks it can reach, direct 
> or indirect.
> > > > >
> > > > > I don't want a peer to have to keep relationships 
> (how it gets 
> > > > > to Fed X) straight, I want it to be able to ask the 
> federations 
> > > > > or transit networks it deals with if they have a route to the 
> > > > > destination network.
> > > > >
> > > > > If you take this view, then you always get what you want to 
> > > > > know, regardless of how convoluted the routes are, by simple 
> > > > > queries to each federation/transit network.  If you 
> try to trace 
> > > > > routes in advance (let's see, I want to get to 
> network A, he is
> > > part of Fed 1
> > > > > and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of
> > > fed 2 and
> > > > > he is also part of Fed 3, and I'm in fed 3, so I can 
> send it to 
> > > > > Z via fed 3, and he can send to fed 2 to get to A).
> > > > >
> > > > > Much better if Fed 3 advertises it can reach A.
> > > > >
> > > > > This is how route advertisements work, and I think we
> > > should assume
> > > > > that's the best way until proven otherwise.
> > > > >
> > > > > So let's not talk about Federations a network belongs to, and 
> > > > > specifically, don't talk about routes TO A FEDERATION, but 
> > > > > rather routes to a destination network FROM a federation.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > > > > > Sent: Wednesday, October 18, 2006 1:01 PM
> > > > > > To: Stastny Richard; Otmar Lendl; Daryl Malas
> > > > > > Cc: [email-masked]
> > > > > > Subject: RE: [Speermint] Basic Peering Requirements
> > > > > >
> > > > > > I had taken this to mean that the Transit VSP would be
> > > > > advertising to
> > > > > > originating VSPs reachability to various federations of
> > > the form:
> > > > > >
> > > > > > (to get to)      (contact)
> > > > > > Federation X --> [email-masked]  (Fed-X etc. could be an
> > > arbitrary
> > > > > > string)
> > > > > > Federation Y --> [email-masked] Federation Z --> 
> [email-masked]
> > > > > >
> > > > > > or:
> > > > > >
> > > > > > Federation X --> [email-masked] Federation Y --> 
> > > > > > [email-masked] Federation Z --> [email-masked]
> > > > > >
> > > > > > If not, count me as misunderstanding too.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stastny Richard [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, October 18, 2006 10:05 AM
> > > > > > > To: Otmar Lendl; Daryl Malas
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: Re: [Speermint] Basic Peering Requirements
> > > > > > >
> > > > > > > >> If a peer is providing connectivity to multiple
> > > > > federations, it
> > > > > > > >> should disclose AoRs providing indirect peering
> > > > > relationships to
> > > > > > > >> servicing peers or federations.
> > > > > > >
> > > > > > > >Sorry, I don't understand that sentence.
> > > > > > >
> > > > > > > >Do you mean that when a VSP adds an AoR to a federations 
> > > > > > > >routing database, then it needs to discluse whether
> > > that is a
> > > > > > > >direct
> > > > > > > customer
> > > > > > > >or just a transit offer?
> > > > > > >
> > > > > > > Sorry, but I do not understand the whole issue:
> > > > > > >
> > > > > > > An AoR is a a special type of SIP URI (a Public User
> > > > > > > Identity) defining the destination network (administrative
> > > > > > > domain)
> > > > > > >
> > > > > > > How can it be disclosed or not, especially for a
> > > transit network?
> > > > > > > It is always public.
> > > > > > >
> > > > > > > Richard
> > > > > > >
> > > > > > >
> > > > > > > ________________________________
> > > > > > >
> > > > > > > Von: Otmar Lendl [mailto:[email-masked]]
> > > > > > > Gesendet: Mi 18.10.2006 15:54
> > > > > > > An: Daryl Malas
> > > > > > > Cc: [email-masked]
> > > > > > > Betreff: Re: [Speermint] Basic Peering Requirements
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Daryl,
> > > > > > >
> > > > > > > > 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):
> > > > > > >
> > > > > > > Here are my comments to that list:
> > > > > > >
> > > > > > > General: this seems to be a list providing 
> details on what 
> > > > > > > federations have to do (or agree on).
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > Fine.
> > > > > > >
> > > > > > > > Billing:
> > > > > > >
> > > > > > > Good.
> > > > > > >
> > > > > > > > Policy:
> > > > > > > >
> > > > > > >
> > > > > > > Could you be a bit more specific on what you mean 
> by "policy"
> > > > > > > in this context?
> > > > > > >
> > > > > > > > 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.)
> > > > > > >
> > > > > > > Could you provide some examples of such policies?
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > Sorry, I don't understand that sentence.
> > > > > > >
> > > > > > > Do you mean that when a VSP adds an AoR to a
> > > federations routing
> > > > > > > database, then it needs to discluse whether that 
> is a direct 
> > > > > > > customer or just a transit offer?
> > > > > > >
> > > > > > > > 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.)
> > > > > > >
> > > > > > > ok.
> > > > > > >
> > > > > > > > Media:
> > > > > > >
> > > > > > > ok.
> > > > > > >
> > > > > > > > Routing:
> > > > > > > >
> > > > > > > > A peer must utilize the centralized federation routing
> > > > > > > mechanism if it
> > > > > > > > is available.
> > > > > > >
> > > > > > > ok.
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > 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 indirect
> > > > > > > > peer to host their AoRs.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Or you want to restrict X to be able to only select one
> > > > > other VSP to
> > > > > > > host it's AoRs in total?
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > ok
> > > > > > >
> > > > > > > > Performance:
> > > > > > > >
> > > > > > > > Performance metrics must be shared between peers as
> > > they apply
> > > > > > > > directly to peering signaling and media on a consistent
> > > > > > > basis within
> > > > > > > > the federation.
> > > > > > >
> > > > > > > ok
> > > > > > >
> > > > > > > /ol
> > > > > > > --
> > > > > > > < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Speermint mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Speermint mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Speermint mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > >
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Oct 2006 19:38:58 -0400

Wow, lots to disagree with ;)

> Sent: Thursday, October 19, 2006 3:21 PM
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.

> will result in a call setup.
Agree, of course
> Not sure what you mean by info.  What type of query are we talking
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.

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

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

> 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.
> 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 :)
> Just having the VSP is unsufficient; that doesn't gurantee they will
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.
> 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.

>The access to the private database
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.  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.

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

> the smallest federation possible; membership=2.
YES! as above

> 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
> approach, if a TN is a SIP phone terminated on a VSP and you end up on
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.

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

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.

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

> entry.  Could the INVITE then be:
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.
> before the horse.  Find the destination peer, then the route to get
Yeah, I would call that registry the DNS too.   That isn't happening.

Brian