Subject: RE: [Speermint] Basic Peering Requirements

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

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 07:06:26 -0400

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

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

---

From: "David Schwartz" <[email-masked]>
Date: Tue, 24 Oct 2006 13:16:41 +0200

While I missed the deadline for submission I felt there was value in
sharing this with the community so I am posting a link where the draft
can be found.

http://www.kayote.com/web/docs/Drafts/draft-schwartz-speermint-use-cases
-federations-00.txt 

Please feel free to comment.

David

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 24 Oct 2006 10:51:09 -0400

David - excellent draft and thank you for compiling!  One thing that I
noticed and thought a bit odd was your definition of "Bi-Lateral or
direct peering".  You state - "For the purposes of this document, VSPs
upload their numbers to an externally reachable location service denoted
as D-PSP." - To me, this is not direct because the location function
that you define is done outside of the
originating-domain/terminating-domain relationship.  

Per the speermint terminology draft:
"Direct peering describes those cases in which two service providers
interconnect without using an intervening layer 5 network."  

-AU

-----Original Message-----
From: David Schwartz [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2006 7:17 AM
To: [email-masked]
Cc: Livingood, Jason
Subject: [Speermint] Use Case draft

David

---

From: "David Schwartz" <[email-masked]>
Date: Tue, 24 Oct 2006 17:36:42 +0200

Hi Adam.

Inline.

> originating-domain/terminating-domain relationship.  

DS: The point I am trying to make here is as follows. When 2 VSPs want
to share their user information with each other they can:

    1. Do the equivalent of a zone transfer of all their users to each
other so that a local copy of this information is available to the
O-VSP.
    2. Have the O-VSP send an INVITE to the T-VSPs registrar and have
T-VSP either proxy the INVITE or send a 3XX back
    3. Same as 2 only use ENUM to query a private tree operated at T-VSP
    4. Store this information in a mutually accessible location
        4a. Possibly push/pull this information to a local copy at both
O-VSP and T-VSP

Options 1 will almost never happen. Why? Because in reality new users
are constantly being added/removed not to mention porting in/out of
numbers and since each VSP has many bilateral relationships each
possibly of a different nature, this model will not scale as well as
other options.

Options 2/3 will also probably not happen since again there are multiple
relationships and O-VSP will have to send many INVITES to different VSPs
to get an answer. Forking in this case is a kludge and doesn't really
help. 

Option 4 (and 4a) is the only reasonable approach. This is the reason
for the worldwide push for either ENUM or Infrastructure ENUM. To try to
get all the location information into 1 place. Remember. The signaling
and media are still traveling between VSPs and hence I still consider
this Direct. Would you agree that public ENUM in this case fits the
direct model? I think so. So just replace the public ENUM with a private
ENUM that does nothing more than hold the data for all interested
parties and you have the same thing.

> interconnect without using an intervening layer 5 network."  

DS: I interpret this as intervening in terms of signaling or media NOT
number lookup. Am I wrong?

> -AU

Thanks for your comments Adam.

D.