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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 26 May 2006 11:24:05 -0400

Otmar,

I like the way you laid this out.  

My intent was to have something more like the O(n) scaling you describe
in your first option, only you don't get the information needed to peer
from the DNS, but from the Policy Server handling Subscriptions.   

I don't know what it means to "almost require".  Just as with your
DNS-oriented case, if you set up policies and Subscription responses to
be conditioned on the federation that a querier claims to be part of,
backed up  by valid certificates signed by that federation, then you can
respond positively without previous manual configurations for that
specific peer.  The peer only needs proof that it is part of the
federation.

Bottom line:  It doesn't matter which server type provides the data.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Thursday, May 25, 2006 3:36 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.
> > 
> > These are just suggestions being thrown out for discussion. 
>  I'd like 
> > to hear what folks think about them.
> 
> Re-reading your mail I found one aspect I'd like to highlight:
> 
> If you talk about a "subscription" of some sort, I assume 
> that you mean that the originating network kind of registeres 
> at the destination network and receives updates about the 
> state of this peering relationship. In a way, this sound 
> similar to what BGP does.
> 
> Have I interpreted this correctly? If not, please ignore the 
> rest of this mail.
> 
> The reason we decided NOT go this route is the following:
> 
> Once you require that the border element of a SIP operator 
> establishes a permanent session with the ingress elements of 
> its peer before any calls can traverse this peering, then you 
> almost require the manual configuration of this peering.
> 
> That's fine if you take the peering model of BGP as reference.
> Layer 3 peering requires a physical connection (except at 
> exchange points), peering is thus always an explicit and 
> human decision and thus the manual BGP configuration is no issue.
> 
> Peering at the SIP layer is different: you usually don't need 
> build any extra physical connection. You can instantly peer 
> with all other SIP services connected to the Internet once 
> you're connected to it. The range of peering partners thus 
> isn't limited to the ones to which you build a direct 
> physical link. The set of potential peering partners is huge 
> and reaching them does not involve any additional lower layer work.
> 
> In the spirit of the Internet end-to-end model, I consider it 
> thus essential to design a system with which all these VoIP 
> operators can in effect establish peering relationships with 
> each other.
> I won't force ubiquitous peering on all VSPs, but the system 
> should make it possible.
> 
> As an example, consider the following scenario:
> 
>   A set of VoIP service providers form an association and 
> exchange traffic
>   via the public Internet using SIP with the TCP/TLS 
> transport protocol
>   for confidentiality and peer authenticity by using X.509 
> certificates
>   signed by the association's certificate authority.
> 
> If a new operator joins such a club, what needs to happen?
> 
> With domain policies the following:
> 
> * the new guy get's his TLS cert signed
> * the new guy configures his ingress points to allow connections
>   via TLS and a correct cert
> * he announces his membership in that federation by adding a NAPTR
>   record to his domain
> 
> That gives us O(n) scaling.
> 
> Imagine what needs to happen if you have to configure BGP-like links:
> 
> * the new guy has to estabish links to all existing members
> * and the reverse: all existing members have to be told about this
>   new guy and have to configure their side of the peering link.
> 
> This has complexity of O(n*n).
> 
> (or do you have something similar like the BGP 
> route-reflectors in mind?)
> 
> ---------------
> 
> If some group of operators want pre-configured links (and 
> thus O(n*n) complexity), fine, let them do that within their 
> federation. 
> My proposal doesn't rule that out. 
> 
> On the other hand I think we should be extremely careful not 
> to build something with precludes setups with far better 
> scaling properties.
> 
> /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 22:54:42 +0200

Michael,

> I like the way you laid this out.  

Thanks.

> from the DNS, but from the Policy Server handling Subscriptions.   

Ok, fine. So you need to discover the location of the Policy Server
so that you can contact him and subscribe to his policies.

If that contact is done via the SIP SUBSCRIBE mechanism, then I guess that
means the RFC3263 procedure which involves a NAPTR, SRV and A lookup. 
In any case: the discovery of the location of such the policy server is
certainly a task for the DNS.

Maybe this SIP based policy server should be distinct from the
normal SIP ingress point (load-balancing, DoS protection, whatever...),
so we need some modification to 3263 to distinguish between the
two SIP server types.

Whereas RFC3263 would look for

   IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.

your modification might look for

   IN NAPTR 50   50  "s"  "SIPS+D2T:policy"    ""  _sips._tcp.policy.example.com.

or some other suitable variant.

That's *very* close to what you can do in my Domain Policy framwork:

There the NAPTRs can look something like this:

   IN NAPTR 50   50  "u"  "D2P+SIP:subscribe" "!.*!sip:[email-masked]"  .

(For some suitable definition of the "subscribe" policy-type.)

As an added benefit you get the power of non-terminal naptrs to simplify
the hosting of customer SIP domains.

> I don't know what it means to "almost require".  Just as with your

Read the last mail from Patrick Melampy, he describes a system where
a manual setup of the subscription link is a precondition to the exchange
of routing information.

> specific peer.  The peer only needs proof that it is part of the

Yes. That's what I'm aiming for. Whether that proof if a TLS cert,
access to a VPN, or whatever doesn't matter in the first stages of
the process.

> Bottom line:  It doesn't matter which server type provides the data.

Correct.

We need a system that's very lightweight for the simple case but
flexible and powerful enough to cope with complex and dynamic data as
well.

I still think that my proposal covers the simple cases and can
easly refer to complexer protocols if that's needed.

/ol