Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 25 May 2006 12:07:05 -0400

Otmar,

If an address is advertized in public ENUM or DNS, then it ought not be
unreachable due to use of private networks or NATs, which is the basis
for some of your arguments about why not SIP.

My thinking was that one would need to progress through a series of
steps/functions where the bootstrap steps are very public, but the later
steps depend on the previous step enabling it.  The chicken or egg
problem shouldn't occur for first steps.  (I do understand your model
where you advertise what is only reachable by a few, but then it is
working as you intended with selective unreachability being part of your
design.)

Hopefully, any delays to call setup occur only because of initial
contact to previously unknown domains.  For, previously contacted
domains or for federations that use a central SIP proxy or some
interconnect SIP fabric, the call can be quickly handed to the heavily
used local contact point for that federation, since they were learned
previous to the call.

Anyway, it may be possible through configuration to address both ways,
with some heuristic to guide when to transition from the "policy is
simple" approach to the "policy is complex" approach.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 5:05 PM
> To: Michael Hammer (mhammer)
> Cc: Khan, Sohel Q [CTO]; [email-masked]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> 
> Michael,
> 
> On 2006/05/24 16:05, "Michael Hammer (mhammer)" 
> <[email-masked]> wrote:
> > 
> > I think our main difference is that I am suspecting that the policy 
> > will be large and possibly very dynamic, thus less suitable for 
> > locating in DNS.  Also, instead of pointing directly to a single 
> > policy document, which seems like a one-size-fits-all periodic user 
> > poll option,; rather, use Subscriptions where the resulting 
> document 
> > may depend on authentication and who is asking, and can be 
> pushed on 
> > the schedule of the server when the policy changes.
> 
> My guess is that the size of the policy will vary a great deal.
> 
> We don't know yet what the market will establish in the future.
> 
> That's why I used URIs are policy element identifiers. This 
> gives us a wide range of options:
> 
> * Simple IDs which refer to offline established policies. (= 
> federation
>   names)
> 
> * References to standards
> 
> * References to documents describing a complex policy
> 
> and (if you want a dynamic protocol)
> 
> * the location and connection parameters for any routing /
>   policy-exchange / ... protocol.
> 
> As an example (and not meant as a real proposal): let's 
> assume that the destination requires the use of the Open 
> Settlement Protocol.
> We could standardize an URI scheme for that, e.g. 
> "osp://hostname:port/"
> and a suitable policy-record could thus be
> 
> 	NAPTR 10 10 "u" "D2P+SIP:osp" "!.*!osp://hostname:port/! .
> 
> You can do the same for your subscription model.
> 
> ----
> 
> As for why you don't want to do all that with SIP, I refer to 
> http://www1.ietf.org/mail-archive/web/speermint/current/msg00218.html
> 
> > These are just suggestions being thrown out for discussion. 
>  I'd like 
> > to hear what folks think about them.
> 
> So do I.
> 
> > I'm also questioning how much information about SIP needs to be 
> > embedded in other protocols like DNS, DHCP, etc. and how 
> much might be 
> > more cohesive if handled via SIP-based mechanisms.  Finding 
> the right 
> > balance, if you will.
> 
> Indeed. My problem with a pure SIP solution is the following:
> Assuming that members of some federations will opt to move 
> their SIP ingress points to private IP networks and/or 
> firewall them heavily I see a severe chicken and egg problem 
> if the discovery of the correct SIP ingress point is done by 
> a SIP exchange.
> 
> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 

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

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 26 May 2006 17:11:39 +0200

Michael,

> for some of your arguments about why not SIP.

We're moving a bit into ENUM WG turf here, but anyway.

We're in a bit of a dilemma here regarding infrastructure ENUM:

On a national level it's manageable to build a private DNS which only
proper (whatever than means) operators can access. Thus you can
build a system that has the feature "if you can see the URI, then
you can reach it".

On an international level I consider this to be impossible. The
definitions about who is a proper carrier or not will vary a
great deal and I doubt that a big incumbent in one country will
want to directly talk to an upstart VoIP operator two continents away. 
Keeping that tree hidden from public view is quite impossible
if you consider the scope of the legitimate readers. Consistent 
selective visibility in a distributed DNS tree is very tricky.

[e164.info managed to do so on a small scale, but they use a 
central DB. I doubt that you can scale up their system to 
worldwide, non-centralized one.]

My conclusion from that is that

* infrastructure ENUM will be public (if it wants to enable more than
  just national peerings).

* Thus the reachability assumption will have to yield.

I wish it weren't so. But I haven't found a way to avoid this conclusion.

Do you see other options?

> problem shouldn't occur for first steps.  

That's why we put the bootstrapping steps into the DNS. Any other
system SPEERMINT will come up with, e.g. some SUBSCRIBE/NOTIFY
would fit in very nicely: the domain policy the can reference
this framework as the requirement to reach the destination.

> (I do understand your model

As I see the market right now, we already have a very selective
reachability on the SIP layer between VoIP operators.

I can't see a way to move the state of affairs to "interconnection on
SIP basis between all commercial VoIP-operators worldwide" without either

* building a SIP routing protocol complete with transit networks
  (the BGP model)

or 

* require the possibility of direct connections between all 
  operators worldwide. 
  Determining whether the caller from halfway around the globe 
  is a legitimate operator is massively difficult, thus we
  end running open servers. (the email model)

Thus I think selective reachability on SIP will stay with us for
the medium term.

> used local contact point for that federation, since they were learned

That sounds good.

> simple" approach to the "policy is complex" approach.

Even if the policy record just states "this is a carrier URI,
calls must use RFC-SPEERMINT-SUBSCRIPTIONS", this is helpful
for callers.

I see domain policies as the meta-protocol to bootstrap various
other peering mechanisms. 

The adoption of my draft thus does not preclude further work in
speermint. Quite the contrary.

/ol

---

From: "Francois D. Menard" <[email-masked]>
Date: Fri, 26 May 2006 21:15:06 -0400

> * infrastructure ENUM will be public (if it wants to enable more than just
national peerings).

This is why I had the Canadian ENUM trial framework modified to hold
non-terminal NAPTRs in Tier 1B which is unlike the US enum trial framework.

F.

--
François D. Ménard
Projet manager
Xit telecom inc.
1350 rue Royale #800
Trois-Rivieres, QC, G9A 4J4
Canada
[email-masked]
Tel: (819) 374-2556 ext. 268
Fax: (819) 374-0395
Cell: (819) 692-1383

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: 26 mai 2006 11:12
To: Michael Hammer (mhammer)
Cc: Khan, Sohel Q [CTO]; [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Michael,

On 2006/05/25 18:05, "Michael Hammer (mhammer)" <[email-masked]> wrote:
> 
> If an address is advertized in public ENUM or DNS, then it ought not 
> be unreachable due to use of private networks or NATs, which is the 
> basis for some of your arguments about why not SIP.

On a national level it's manageable to build a private DNS which only proper
(whatever than means) operators can access. Thus you can build a system that
has the feature "if you can see the URI, then you can reach it".

On an international level I consider this to be impossible. The definitions
about who is a proper carrier or not will vary a great deal and I doubt that
a big incumbent in one country will want to directly talk to an upstart VoIP
operator two continents away. 
Keeping that tree hidden from public view is quite impossible if you
consider the scope of the legitimate readers. Consistent selective
visibility in a distributed DNS tree is very tricky.

[e164.info managed to do so on a small scale, but they use a central DB. I
doubt that you can scale up their system to worldwide, non-centralized one.]

> steps/functions where the bootstrap steps are very public, but the 
> later steps depend on the previous step enabling it.  The chicken or 
> egg problem shouldn't occur for first steps.

That's why we put the bootstrapping steps into the DNS. Any other system
SPEERMINT will come up with, e.g. some SUBSCRIBE/NOTIFY would fit in very
nicely: the domain policy the can reference this framework as the
requirement to reach the destination.

> working as you intended with selective unreachability being part of 

As I see the market right now, we already have a very selective reachability
on the SIP layer between VoIP operators.

I can't see a way to move the state of affairs to "interconnection on SIP
basis between all commercial VoIP-operators worldwide" without either

or 

Thus I think selective reachability on SIP will stay with us for the medium
term.

That sounds good.

> simple" approach to the "policy is complex" approach.

Even if the policy record just states "this is a carrier URI, calls must use
RFC-SPEERMINT-SUBSCRIPTIONS", this is helpful for callers.

I see domain policies as the meta-protocol to bootstrap various other
peering mechanisms. 

The adoption of my draft thus does not preclude further work in speermint.
Quite the contrary.

/ol

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 28 May 2006 14:03:21 -0400

> From: Francois D. Menard [mailto:[email-masked]]
> Sent: Friday, May 26, 2006 9:15 PM
> To: 'Otmar Lendl'; 'Michael Hammer (mhammer)'
> Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> just

Yes but many of us really dislike the use of non terminal NAPTRS since their
behavior is not sufficiently documented.

> Thus I think selective reachability on SIP will stay with us for the

They are called bi-lateral agreements.