Subject: Re: [Speermint] Some words on the federation concept

From: Dan York <[email-masked]>
Date: Fri, 2 May 2008 05:29:31 -0400

Going back through older email, I saw this note from Otmar and (at  
least in my mail program) zero replies.  Did everyone agree with Otmar  
or did everyone miss his message in the chaos of being at IETF 71?

For what it's worth, Otmar's definition seems fine by me.

Dan

On Mar 13, 2008, at 12:45 PM, Otmar Lendl wrote:

>
> At yesterday's session, someone (I forgot, who) voiced his suspicion
> that everybody has his own view of what a federation is and what not.
>
> We need to clear that up to make progress.
>
> Here is my PoV:
>
> The definition (from terminology-16) is:
>
>  A federation is a group of SSPs which agree to receive calls from
>  each other via SIP, and who agree on a set of administrative rules  
> for
>  such calls (settlement, abuse-handling, ...) and the specific rules
>  for the technical details of the peering.
>
> (this is basically unchanged from
> http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.txt
> of december '05)
>
> My motivation for this definition was the following idea:
>
> * The numbers of SSPs worldwide could be in the same order as the  
> number
>  of mailservers in the Internet. This is a huge number.
>
> * As I don't assume that every possible pair of two SSP will peer with
>  each other, we will need some sort of transit routing.
>
> * To make that manageable, the number of routes needs to come
>  down. We need an aggregation step.
>
> * Thus federations: If reaching a federation equals having a
>  path to all members of this federation, then we can base the
>  call routing on federation IDs, and not on SSPs
>
>  Only within a federation, routing is towards a specific SSP.
>
> This is in analogy to layer 3 routing. The routing table contains
> routes to subnets. Once a router notices that it has an interface
> within the same subnet as the destination address of the IP
> packet it needs to route, then the IP routing layer has done
> its job and packet routing is passed to whatever L2 network
> implements this shared subnet.
>
> Translated to federation based VoIP routing, this means that
> once a source SSP detects that he shares a common federation
> with the destination SSP, then the high-level routing algorithm
> is finished and a federation-specific one starts.
>
> All this (just as for IP routing) works only if every SSP in a
> federation talks to every other SSP in this federation.
>
> ------
>
> Second point: A federation is per definition not more than a
> mathematical set of SSPs. This set of SSPs might have decided that
> they need some sort of federation infrastructure, be it a common L2
> network, a X.509 CA, an ENUM tree, or a central SIP proxy. Of  
> course, a
> federation can be run by a commercial entity.
>
> But it's not needed. The set of all SSPs implementing RFC 3263 on the
> public Internet is by definition a federation. (as mentioned during  
> the
> session, this the purest form of an on-demand peering)
> Just as well is a private peering between two SSP a federation.
> (probably the most extreme case of a static one)
>
> The 10000 feet view of the overall call routing scheme does not care.
> Just look at the words of the definition.
>
> (The same applies btw to IP routing: a subnet can be a point-to-point
> link just as well as a X.25 or ISDN on demand dialing network spanning
> thousands of hosts. The L3 routing algorithm doesn't care a jota.)
>
> ------
>
> It is certainly worthwhile to consider peering fabrics where not all
> members peer with each other (just as on IP Exchange Points).
>
> That, too, is a useful concept. But it's not a federation according to
> the definition in terminology-16.
>
> /ol
> -- 
> // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
> // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
> // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

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

---

From: "Michael Hammer (mhammer)" <[email-masked]>
Date: Mon, 5 May 2008 13:43:46 -0400

Dan,

We had discussed this way back at the beginning of Speermint and this is
consistent with that.

My assumption was silence was consent.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan York
> Sent: Friday, May 02, 2008 5:30 AM
> To: Otmar Lendl
> Cc: [email-masked]
> Subject: Re: [Speermint] Some words on the federation concept
> 
> Going back through older email, I saw this note from Otmar 
> and (at least in my mail program) zero replies.  Did everyone 
> agree with Otmar or did everyone miss his message in the 
> chaos of being at IETF 71?
> 
> > each other via SIP, and who agree on a set of 
> administrative rules for  
> > number  of mailservers in the Internet. This is a huge number.
> >
> > * To make that manageable, the number of routes needs to 
> come  down. 
> > We need an aggregation step.
> >
> > * Thus federations: If reaching a federation equals having 
> a  path to 
> > all members of this federation, then we can base the  call 
> routing on 
> > federation IDs, and not on SSPs
> >
> packet it 
> > needs to route, then the IP routing layer has done its job 
> and packet 
> > routing is passed to whatever L2 network implements this shared 
> > subnet.
> >
> > Translated to federation based VoIP routing, this means that once a 
> > source SSP detects that he shares a common federation with the 
> > destination SSP, then the high-level routing algorithm is 
> finished and 
> > a federation-specific one starts.
> >
> > network, a X.509 CA, an ENUM tree, or a central SIP proxy. 
> Of course, 
> > a federation can be run by a commercial entity.
> >
> > the session, this the purest form of an on-demand peering) Just as 
> > well is a private peering between two SSP a federation.
> > // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 // 
> > nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // 
> > http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg