Subject: [Speermint] Regarding the term "federation"

From: Otmar Lendl <[email-masked]>
Date: Wed, 25 Oct 2006 16:37:13 +0200

The term federation in the context of Speermint appeared (AFAIK)
first in draft-lendl-sip-peering-policy-00.txt, then the definition
got moved to draft-ietf-speermint-reqs-and-terminology-01.txt,
then draft-ietf-speermint-terminology-06 plus draft-lendl-speermint-federations-03.

>From the current terminology draft:

   A federation is a group of VSPs 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 interconnection.

My basic premise for this definition was the idea that federations
should play the same role in SIP routing as subnets play in L3 routing:
If the higher level routing algorithm notices that his host and
the destination share a common subnet, then use his interface into
that subnet to directly route to the destination.

That routing step only works if all members of a federation can talk
to each other.

Some other drafts have picked up the "federation" terminology. 
I'm not sure they agree on the definition, though. Thus this mail.

To recap what I think a "federation" should be:

* Full mesh between members.

  No "we both members of $WHATEVER, but we don't peer with each other there".

  Corrolary: there is no need for the federation to maintain detailed
  information on what routing information should be disclosed to which
  member.

* A federation is a mathematical set of VSPs. There can, but need not
  be some organization (with associated services) behind a federation.

>From what I read between the lines of other drafts, a federation there
needs to be operated by someone who provides various business and technical
services, including a DB which stores who has agreed to peer with whom.

Now, I'm not saying that this is a bad idea. In fact, for some scenarios
this is the likely outcome. 

I'm just worried about keeping the terminology consistent. 

What about calling such managed federations "peering fabrics"?

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Oct 2006 11:11:33 -0400

By our definition, a federation has rules.  The rules state when two members
can exchange traffic.  While I do think the most common rule is everyone can
talk to everyone else, I don't think we can or should have a blanket
prohibition on one peer refusing traffic from another peer within the rules.
Consider, for example, non payment of compensation, if there is any, or
receipt of what the termination network considered SPIT.

Federations have rules, so there has to be SOMETHING that defines the rules.
In that sense, there is some kind of organization, but it might be pretty
weak.

I do think it is currently the case that federations run databases.  I don't
think there is a flat requirement that they do, but most of the practical
solutions I see involve them.  It's possible to build databases that are
distributed enough that each peer can keep his part of it by himself.
Sometimes such databases have a common portion (root) that SOMEONE runs, but
again, that could be pretty simple.

So, I'm not afraid of having federations running databases.  I guess I think
we probably ought to separate the functional parts, allowing someone to run
the federation, and someone else to run the database.  If we, for example,
agreed that a common registry made sense, but a single federation did not,
then we would separate at least one database from actual federation
ownership.

Brian

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2006 10:37 AM
> To: [email-masked]
> Subject: [Speermint] Regarding the term "federation"
> 
>