Subject: RE: [Speermint] Basic Peering Requirements

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

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

> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Tuesday, October 24, 2006 12:39 PM
> > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey
> > Cc: Nieminen Klaus; [email-masked]
> > Subject: RE: [Speermint] Basic Peering Requirements
> > 
> > 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 14:55:51 -0400

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