Subject: RE: [Speermint] Basic Peering Requirements

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

Brian,

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

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Friday, October 20, 2006 3:57 PM
> To: 'Stastny Richard'; 'Otmar Lendl'
> Cc: Michael Hammer (mhammer); [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> 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
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [Speermint] Basic Peering Requirements
> > 
> > >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 
> > >disintermediated, sooner or later.
> > 
> > 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=pdf&
> > 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.
> > 
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 17:08:55 -0400

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?

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.

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.

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

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

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Friday, October 20, 2006 4:16 PM
> To: Brian Rosen; Stastny Richard; Otmar Lendl
> Cc: [email-masked]

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 20 Oct 2006 21:30:09 +0000

Finally this issue is raised... 

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

I too wonder how this can be done on a global basis.

tim

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 16:39:20 +0200

> I don't think this is acceptable.

I always wonder why carriers won't publish any ingress options. Carrying 
phone calls is money, and if they don't tell others there ingress points 
they won't have voice traffic.

> is a complete list of peers for a domain or a federation.

You do not need the list of all peers of a federation - you only need 
the federations of a domain.
> Furthermore, unless you are part of a federation, you cannot ask anything of

Yes - but it is not necessary. The key is the domain, not the federation.

> them.  They certainly aren't going to put all of their routes in a public

The federation need not to publish there members - the members publish 
there federations. Also I guess most federation do not provide any 
traffic. The mission of a federation is direct peering between its 
members. For transit there will be transit providers, which bridge 
federations. And this transit providers will tell you where they can get 
you - not the federations.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Oct 2006 17:09:10 +0200

> I don't think this is acceptable.

It's done for IP transit/peering. Just have a look at the RIR's routing
registries. e.g. have a look at what's public for MCI EMEA:
http://www.ripe.net/fcgi-bin/whois?searchtext=AS702

> is a complete list of peers for a domain or a federation.

On IP Layer3, you can.

> federation your federation has a transit network connection to). 

Once again, that "competitive information" *is* public for the
rather competitative IP transit market. 

> BGP like route engine.  Yours would not.

You're re-inventing TRIP.

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

---

From: Jim Reid <[email-masked]>
Date: Mon, 23 Oct 2006 16:56:32 +0100

> registries. e.g. have a look at what's public for MCI EMEA:

Er, what's in the RIR databases for routing entries doesn't  
necessarily reflect how ISPs actually route packets and do peering in  
reality. Whether any discrepancies are due to lack of clue,  
insufficient engineering resources, laziness, incompetence or  
security through obscurity is for others to decide. [And before  
anyone from MCI takes offence, I'm not implying that the public  
routing data they publish in the RIPE NCC database is inaccurate.]  
BTW, RIPE53 had an interesting talk on the accuracy of peering info  
in the RIPE NCC database. It's at:
http://www.ripe.net/ripe/meetings/ripe-53/presentations/ 
irr_analysis_services.pdf

I suspect you'd get the same types of discrepancies if the RIRs (or  
any comparable "neutral" organisation) maintained a (voluntary?)  
database of SIP peering arrangements. Some SIP providers would get it  
100% right, others less so.

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Oct 2006 18:16:40 +0200

On 2006/10/23 17:10, Jim Reid <[email-masked]> wrote:
> reality. 

Yes, it isn't an operational database, though some people use
(or at least used) the data contained therein as the input
to AS path / prefix filters.

Nevertheless I think the RIR databases show that the network does
not break down if the peering/upstream information is public.

/ol

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 18:29:34 +0200

> I too wonder how this can be done on a global basis.

The mapping from TN to domain, and domain to ingress point are 2 
different, orthogonal tasks. And there are different solution for both 
of them.

e.g. for TN->domain there is user ENUM, infrastructure ENUM, private 
ENUM trees, lookup tables, number portability databases, ...

for domain->ingress points there is RFC 3263, federation defined lookup 
rules, lookup tables, lookup in private DNS trees (e.g. 3GPP GRX), ...

of course both steps can be performed in a blackbox operated by a 3rd 
party - but as this are 2 separated problem there should be 2 separated 
solutions.

-- 
Klaus Darilion
nic.at

---

From: Jim Reid <[email-masked]>
Date: Mon, 23 Oct 2006 17:54:34 +0100

> not break down if the peering/upstream information is public.

True, but this is a false analogy Otmar. The internet has  
traditionally always been open about operational data: IP addresses,  
domain names, AS numbers, routing objects, etc. Telephony hasn't.  
Simply telling telcos and other SIP providers that the sky won't fall  
in if they publish their SIP peering policies isn't going to convince  
them to do that. Some of their concerns are justified IMO -- eg  
potential for DDoS attacks on ingress points. Others are layer-9  
problems that should probably be out of scope for the IETF.

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 23 Oct 2006 17:07:44 +0000

Klaus, 

> >> 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.
> > 
> The mapping from TN to domain, and domain to ingress point 
> are 2 different, orthogonal tasks. And there are different 
> solution for both of them.
> 
> e.g. for TN->domain there is user ENUM, infrastructure ENUM, 
> private ENUM trees, lookup tables, number portability databases, ...

I agree that the act of mapping a TN to a domain is straight-forward.
The problem I worry about is doing this on a global scale.  As Brian
notes, a theoretical solution is for all TNs (and the identify of the
SPs providing services to them) to be in a public database.  That would
solve the routing problem but raises other concerns (e.g.,
administrative, regulatory, privacy).  

Obviously there are a couple of approaches in play.  One assumes that
such a public database will emerge.  The other assumes that it will not,
or will not soon, and attempts to stitch together some functional
equivalent out of a set of private databases. 

The gist of my comment is that solutions to the second problem, while
interesting to contemplate, are not implementable without a real
solution to the first problem.  

tim

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Oct 2006 13:45:04 -0400

> ENUM trees, lookup tables, number portability databases, ...
Klaus, that is rewriting history.  ENUM is TN to URI, not domain.  It was
intended that the URI be the place the call was sent to, period.  If we were
to get a domain, then it wouldn't be a NAPTR, right?  

The ingress point thing is an add-on.  You are suggestion that we rewrite
the ENUM documents to describe what you get out of ENUM as a domain, and
then there is another step you want to add that is domain to URI.

Furthermore, you really want 3 steps, right?  TN to domain, domain to
federation, federation to ingress point.  You have to do that; ingress point
is definitely dependent on origination side, and thus both the peer and the
federation who is sending the destination the call.

Brian

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 23 Oct 2006 13:02:30 -0700

Reliving the past (using phone numbers and their regulations) is quite a
trip!

Henry

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 24 Oct 2006 15:05:32 +0200

> Klaus, that is rewriting history.  ENUM is TN to URI, not domain.  It was

Uups. Sorry. Of course I meant TN->URI

> then there is another step you want to add that is domain to URI.

No, as stated above. I do not want a new mapping, I just meant TN->URI

> Furthermore, you really want 3 steps, right?  TN to domain, domain to

IMO 3 steps are not a problem. If it is DNS based, the first call will 
have little higher call setup delay, but all subsequent calls will be 
cached and answered fast.

regards
klaus

-- 
Klaus Darilion
nic.at