Subject: RE: [Speermint] Re: comments on terminology document

From: "David Schwartz" <[email-masked]>
Date: Sun, 12 Mar 2006 12:48:56 +0200

Hi David.

Nice draft.

Following up on Rohan's comment regarding carrier clubs or federations I think that this document should actually have a definition of these as well.

The reason it is so important to have this definition appear in this document is because I have seen many definitions cropping up that IMHO confuse the matter and since this document is sort of a baseline it is probably better that it is dealt with here. 

Compare for example the definitions given for a federation in "draft-ietf-sipping-trait-authz-02" (TRAIT) and "draft-lendl-speermint-federations-00" (FEDS). 

TRAIT defines a federation as "...a set of administrative domains that implement common policies regarding the use and applicability of traits for authorization decisions".

FEDS on the other hand defines this same entity as "...a group of VoIP service providers which
      *  agree to receive calls from each other via SIP,
      *  agree on a set of administrative rules for such calls
         (settlement, abuse-handling, ...), and
      *  agree on specific rules for the technical details of the
         Interconnection".

As can be seen, FEDS has a much narrower definition and since as Rohan has pointed out we are "not precluding" connections via some sort of intervening network it is possible to have federations where the peers do not "agree" on policy with anyone other than the intervening network. TRAIT is general enough to allow for this model while FEDS is not.

Accepting the TRAIT definition and "base-lining" it is therefore more in line with the current revisions to your document.

(In general I feel that the TRAIT document should migrate over to the SPEERMINT working group) 

Any thoughts?

David Schwartz

.
> 
> 3) It seems like a lot of folks are interested in federation and 
> carrier clubs.  I think our first responsibility is direct peering, but 
> we should be flexible enough to accommodate federation without jumping 
> through a lot of hoops. I like the new wording in 5.1 for example.  I 
> still think the definition of Layer 5 could be more accommodating.  
> I've proposed some text below:
> 
> current wording in -01
> >3.6.2.  Layer 5 Peering
> >
> >   Layer 5 peering refers to interconnection of two service providers
> >   for the purposes of SIP signaling.  Note that in the layer 5 peering
> >   case, there is no intervening network.  That is, for purposes of 
> >this
> >   discussion, there is no such thing as a "Layer 5 Transit Network".
> 
> Proposed wording:
> Layer 5 peering refers to interconnection of two service providers for 
> the purposes of exchanging SIP signaling. Note that in the layer 5 
> peering case, there is no requirement for any intervening "Layer 5 
> Transit Network".  Each service provider is expected to interconnect 
> directly with other service providers, although a service provider is 
> allowed to interconnect through another domain (ex: a federation) to 
> act on its behalf. This document neither precludes nor encourages this 
> behavior.
> 
> 
> thanks,
> -rohan
> 

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

---

From: David Meyer <[email-masked]>
Date: Mon, 13 Mar 2006 10:33:28 -0800

> Nice draft.

	Thanks. Just surfacing after a brutal travel spin-cycle.

> The reason it is so important to have this definition appear in this document is because I have seen many definitions cropping up that IMHO confuse the matter and since this document is sort of a b…

	Agreed.

> (In general I feel that the TRAIT document should migrate over to the SPEERMINT working group) 

	On first blush, seems reasonable. What does the WG think?

	Dave

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 15 Mar 2006 15:23:46 +0100

On 2006/03/12 11:03, David Schwartz <[email-masked]> wrote:
> 
> Following up on Rohan's comment regarding carrier clubs or federations
> I think that this document should actually have a definition of these
> as well.
>
> The reason it is so important to have this definition appear in this
> document is because I have seen many definitions cropping up that IMHO
> confuse the matter and since this document is sort of a baseline it is
> probably better that it is dealt with here.

The concept of federations will be important. They are popping up
in various concepts (e.g. IM federations), and I doubt that one
definition will be suitable for all applications.

>
> Compare for example the definitions given for a federation
> in "draft-ietf-sipping-trait-authz-02" (TRAIT) and
> "draft-lendl-speermint-federations-00" (FEDS).
>
> TRAIT defines a federation as "...a set of administrative domains
> that implement common policies regarding the use and applicability of
> traits for authorization decisions".
>
> As can be seen, FEDS has a much narrower definition and since as Rohan
> has pointed out we are "not precluding" connections via some sort
> of intervening network it is possible to have federations where the
> peers do not "agree" on policy with anyone other than the intervening
> network. TRAIT is general enough to allow for this model while FEDS is
> not.

My wording in FEDS may be ambiguous, but as one example shows I tried
to include the options of having a layer 5 node in the middle in
the definition of a federation:

   o  Peering fabric based on SIP: A company sets up a SIP proxy which
      acts as a forwarding proxy between the SIP proxies of all
      participating VSPs.  The group of these VSP form a federation
      whose technical rules state that calls have to be routed via that
      central proxy.

In the context of draft-lendl-speermint-federations-00, the only important
aspect of a federation is the notion that if VSP A is a member of
the federations X and Y and VSP B is a member of Y and Z then A can use
the federation-framework of Y to complete a call to B.

At this level, the details of Y's inner working (direct SIP? proxied SIP? 
Public Internet? Private L3? QoS? TLS? Codecs? srtp?) is irrelevant.

The TRAIT concept fits in nicely into draft-lendl-domain-policy-ddds-00.
I see two ways of incorporating TRAITs there:

a) if e.g. 10 universities trust each other's traits, then they can
   form a FEDS federation where the technical rules state that inter-university
   calls need to carry the trait "valid-user" (signed by one of the universities).

b) assuming traits will be standardized as RFC9999, and the appropriate
   policy-types are introduced:

   $ORIGIN example.edu.
      ;      order pref flags service regexp replacement
       IN NAPTR 10 10   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:9999!" .
       IN NAPTR 10 11   "U" "D2P+SIP:ca-list" "!^.*$!CACERT,THAWTE,XXXX!" .

> Accepting the TRAIT definition and "base-lining" it is therefore more
> in line with the current revisions to your document.

I'm not sure whether that's a good idea. TRAIT addresses a different application
than FEDS. Forcing a definition to suit both may have benefits in terminology
but will dilute the applicability of the concepts regarding the respective use-cases.

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

---

From: "David Schwartz" <[email-masked]>
Date: Wed, 15 Mar 2006 22:15:22 +0200

Hi Otmar.
 
Nice hearing from you.
 
I guess what concerns me about the definition in your draft is the word "agree". Various DA's can coexist in a federation without agreeing on anything. They merely need to support a common set of rules so that they can understand each others requirements. Agreement sound awfully close to bilateral relationships and as I stated before that is just on use case for a federation. Entities may federate and yet not agree to accept direct traffic from each other for business, security, trust, protocol, codec or just about any other reason. 
 
While there may definitely be more than one definition for a federation, we should strive for a more general (supporting more use cases) definition at the expense of the more restrictive one.
 
Cheers,
 
David Schwartz
________________________________

מאת: Otmar Lendl [mailto:[email-masked]]
נשלח: ד 15/03/2006 16:23
אל: David Schwartz
עותק לידיעה: David Meyer; Rohan Mahy; [email-masked]
נושא: Re: [Speermint] Re: comments on terminology document

   $ORIGIN example.edu.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 15 Mar 2006 23:24:27 +0100

Hi David,

[the Cc: via the speermint list didn't reach me yet, thus the extensive quote]

On 2006/03/15 21:03, David Schwartz <[email-masked]> wrote:
> Hi Otmar.
>  
> Nice hearing from you.
>
> I guess what concerns me about the definition in your draft is the
> word "agree". Various DA's can coexist in a federation without
> agreeing on anything. They merely need to support a common set of
> rules so that they can understand each others requirements. Agreement
> sound awfully close to bilateral relationships and as I stated before
> that is just on use case for a federation. Entities may federate and
> yet not agree to accept direct traffic from each other for business,
> security, trust, protocol, codec or just about any other reason.

?DA?

I'm open to alternative wordings. The really critical thing for me
is the following:

  If A and B are members of federation Y, then they can use
  some means (as defined in the rules of Y) to route calls to
  each other via SIP.

(I don't care whether what SIP routings (direct or via a central
proxy) a federation defines for its members. That's out of scope
for my draft. It doesn't matter for the domain policy draft.)

This doesn't necessarily mean they have a bilateral contract.

They could have a contract with a central authority which defines
how two members can connect to each other.

As an example of that concept on a layer 3 exchange, look at
the route servers operated by various internet exchanges
(e.g. http://www.linx.net/www_public/our_services/other_services):
Everybody peering with such a route server effectively peers
with everybody else who peers with this server.

A SIP-Layer transit network X is just another special case, as long
as ALL customers of X can reach ALL other customers of X via the 
transit network X. The set of customers of X is a valid federation
according to my definition.

What doesn't work is selective peerings within a fabric: that way
the fabric membership information is no longer enough to make
the call routing decision. 

> While there may definitely be more than one definition for a
> federation, we should strive for a more general (supporting more use
> cases) definition at the expense of the more restrictive one.

As I said, I'm open to wording suggestions.

/ol