Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 24 Oct 2006 12:38:41 -0400

Brian,

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

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 7:06 AM
> To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar 
> Lendl'; 'Richard Shockey'
> Cc: 'Nieminen Klaus'; [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> Mike
> 
> 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
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Monday, October 23, 2006 4:43 PM
> > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey
> > Cc: Nieminen Klaus; [email-masked]
> > Subject: RE: [Speermint] Basic Peering Requirements
> > 
> > Brian,
> > 
> > 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
> > 
> > 
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Monday, October 23, 2006 4:10 PM
> > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar 
> > > Lendl'; 'Richard Shockey'
> > > Cc: 'Nieminen Klaus'; [email-masked]
> > > Subject: RE: [Speermint] Basic Peering Requirements
> > >
> > > > 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.
> > > 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.
> > >
> > >
> > > >
> > > > 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.
> > > 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.
> > >
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Oct 2006 12:54:31 -0400

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

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

> Sent: Tuesday, October 24, 2006 12:39 PM