Subject: [Speermint] latest in speermint terminology

From: David Meyer <[email-masked]>
Date: Fri, 18 Aug 2006 07:16:15 -0700

With all (most?) of the comments I've received
	(including, Otmar, s/CRD/CAD/ :-))

	http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt

	I'll post it to the internet-drafts repository on Monday
	if we're close to converging.

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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 18 Aug 2006 13:56:57 -0400

> 	http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-04.txt

Regarding 4.5:

4.5.  Assisted Peering

    In this case a federation employs a central SIP proxy (which is not
    itself a VSP) to bridge calls between participating networks.

First, by the term "bridge", do you mean that the signaling actually passes 
through the proxy?  If so, what about cases where the SIP proxy routes calls 
by issuing redirects?  Also, what about that same functionality (the routing 
of calls between peers) using a directory style technology, such as ENUM (or 
maybe LDAP, though I don't know if anybody is doing that).

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 21 Aug 2006 11:37:33 +0200

On 2006/08/18 19:08, Andrew Newton <[email-masked]> wrote:
> through the proxy?  If so, what about cases where the SIP proxy routes 
> calls by issuing redirects?  Also, what about that same functionality (the 
> routing of calls between peers) using a directory style technology, such as 
> ENUM (or maybe LDAP, though I don't know if anybody is doing that).

My intention with that term is the following context:

* "direct peering" is for when the SIP elements of both networks
  talk directly to each other. In between are only layer 0 to 3 devices.

* "transit case": there a call is passed through a L5 transit network.

I thought we need a definition for a middle case: 

Here a fabric provider is involved in the SIP signalling (thus it's
not a simple direct peering). It shouldn't matter whether it's done
by redirect or forwarding SIP signalling. In these cases I'd rather
avoid using the "transit" word, as the SIP proxy there is just a helper
for the peering and not a fully fledged SIP Network provider who is
providing transit services.

ENUM (or LDAP) is a different issue: you can have someone provide
ENUM services to facilitate direct peering. The term "direct peering"
isn't affected by anyone providing ENUM services. 

Andy, do you agree with that classification? Should we change the
definition of "direct peering" to include such models? 
Or what's your preferred definition of "assisted peering"?
Would you prefer a different name for that concept?

Cheers,

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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 21 Aug 2006 10:44:22 -0400

> Would you prefer a different name for that concept?

There does need to be a "middle" case.  I just see no difference  
between my SIP redirects and ENUM.  In the end, my SIP servers will  
directly talk to your SIP servers.

The entire section (Section 4) also seems to be lack an important  
operational distinction regarding the termination of calls.  The  
relationship an ITSP may have with another ITSP is different than the  
relationship an ITSP may have with a carrier.  An ITSP can only send  
calls to another ITSP than it knows can be terminated on that  
network, whereas any call can usually be terminated by a carrier.

-andy

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 21 Aug 2006 16:57:43 +0200

> The

?
I cannot completely follow what you want to say here:

A carrier and an ITSP can only terminate calls to subscribers he is
providing service to.

Anything else is transit.

Richard

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Aug 2006 08:09:56 -0700

> Anything else is transit.

	That, and we don't have a definition of ITSP (yet). I'm
	assuming that the definition of ITSP is as on
	http://en.wikipedia.org/wiki/ITSP. If so, we already have
	VSP, which is a synonym (unless someone disagrees). 

	--dmm

---

From: Andrew Newton <[email-masked]>
Date: Mon, 21 Aug 2006 12:48:53 -0400

> 	VSP, which is a synonym (unless someone disagrees). 

No disagreement here.  Perhaps the document should mention in the definition 
  for VSP that ITSP is a common synonym.  However, the document should only 
use VSP any place else (or vice versa... I'm not wed to either).

-andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 21 Aug 2006 13:07:06 -0400

> Anything else is transit.

Perhaps this miscommunication comes from my misuse of the word "carrier". 
I'm not sure what the bell-centric meaning of the word is, but in the 
environment I am in carriers are different than peers in that peers can only 
terminate some calls (i.e. those of their subscribers) while carriers can 
terminate any call.  Looking at the definitions, this view does not have to 
be directly tied to Indirect Peering or Direct Peering.  There certainly 
could be Indirect Peering that can only terminate a subset of calls (within 
a namespace).  But then that makes me ask, what is the difference between 
Indirect Peering and Assisted Peering... they are both transit providers.

And this all of this leaves out the case where a federation or exchange runs 
an ENUM directory or SIP redirect server that always results in Direct Peering.

-andy

---

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 21 Aug 2006 13:35:40 -0400

I complete agree that we are missing another model here that encompasses
the "assisted peering" notion.  Do we need to create a new term for it?
I don't know and lean towards "NO".  Think of the call flow where the
originating SP queries a SP that is NOT the terminating SP to satisfy a
location request. This would be a communication in the Location Function
portion of the SIP Peering Architrave ID.  The sole purpose is to
determine "Where and how do I route this call please?!?" That would be a
relationship with a 3rd party apart from Originating/Termination SP
relationship.  This might be done for many reasons, but the most common
today would probably be the "peering fabric" play.  It's only a direct
peering relationship for the sole purposes of identifying a route to the
termination point.  Once known, we have another direct peering
relationship with the VSP that has the registered subscriber.  If a
direct peer is not accessible, then a transit peering path would be
selected.

As a side note and I know we are ahead of ourselves but I will bring it
up anyways - this 3rd party peering or assisted peer is going to be a
relationship that we will probably have to address with respects to
CALEA-like requirements.  The LEA will not be the SP of termination, but
rather an "independent" (or parasitic) peering arrangement. Before I get
flamed, I know it's out of scope, just mentioning.

-AU

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Monday, August 21, 2006 5:38 AM
To: Andrew Newton
Cc: [email-masked]
Subject: Re: [Speermint] latest in speermint terminology

> First, by the term "bridge", do you mean that the signaling actually 
> passes through the proxy?  If so, what about cases where the SIP proxy

> routes calls by issuing redirects?  Also, what about that same 
> functionality (the routing of calls between peers) using a directory 
> style technology, such as ENUM (or maybe LDAP, though I don't know if
anybody is doing that).

Here a fabric provider is involved in the SIP signalling (thus it's not
a simple direct peering). It shouldn't matter whether it's done by
redirect or forwarding SIP signalling. In these cases I'd rather avoid
using the "transit" word, as the SIP proxy there is just a helper for
the peering and not a fully fledged SIP Network provider who is
providing transit services.

ENUM (or LDAP) is a different issue: you can have someone provide ENUM
services to facilitate direct peering. The term "direct peering"
isn't affected by anyone providing ENUM services. 

Cheers,

/ol

---

From: Andrew Newton <[email-masked]>
Date: Mon, 21 Aug 2006 14:00:21 -0400

> flamed, I know it's out of scope, just mentioning.

Regardless of how you see it, I think IETF working groups are forbidden from 
purposefully making standards work with CALEA.  It isn't just a working 
group scope issue.

http://www.wired.com/news/politics/0,1283,32455,00.html ... including a 
quote from Brian Rosen.

Though I'm not sure which RFC it is.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 21 Aug 2006 14:30:01 -0400

RFC2804.  I was not quoted well, typical selective quoting.  The point I
made was that it was going to be done, to our work, and if we did it, it
would be done well, and if someone else did it, it would likely be done
poorly, and we'd all have to live with it anyways. 

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, August 21, 2006 2:00 PM
> To: Uzelac, Adam
> Cc: [email-masked]; Otmar Lendl

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Aug 2006 10:23:43 -0700

On Mon, Aug 21, 2006 at 12:48:53PM -0400, Andrew Newton wrote:
> No disagreement here.  Perhaps the document should mention in the 
> definition for VSP that ITSP is a common synonym.  However, the document 
>  should only use VSP any place else (or vice versa... I'm not wed to 
> either).

	Alreay done...

	--dmm

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 22 Aug 2006 17:18:27 +0200

On 2006/08/21 19:08, Andrew Newton <[email-masked]> wrote:
> environment I am in carriers are different than peers in that peers can 
> only terminate some calls (i.e. those of their subscribers) while carriers 
> can terminate any call.  

All that is an issue for the call routing logic. The actual peering
interface should not change in any way just because traffic passing
it is not just peering, but also transit.

>                         Looking at the definitions, this view does not 
> have to be directly tied to Indirect Peering or Direct Peering.  There 
> certainly could be Indirect Peering that can only terminate a subset of 
> calls (within a namespace).  

I think we should take a page out of the BGP playbook. There the
protocol itself doesn't care whether one announces just one's own
networks, that plus some customers, the default route or a
full BGP table. The distinction between a transit relationship
and a pure peering relationship is just one of route announcements
and not one of the selection of the peering protocol.

We should strive for the same. We shouldn't hardwire business decisions
into the protocol design.

In terms of terminology, I maintain it's beneficial to have a 
term between direct peering an transit. 

>                             But then that makes me ask, what is the 
> difference between Indirect Peering and Assisted Peering... they are both 
> transit providers.

I think there is a point to that decision when you look at the
inter-federation routing architecture: From a high level point of view,
you are only interested whether two networks peer which each other or not.

If VSPs X, Y, and Z are connected to the VoIP-peering point maintained
by company A, then from the standpoint of routing I don't care whether
calls from X to Y involve a SIP proxy operated by A. That's why the
definition of "federation" does not require "direct peering", but
also allows "assisted peering".

/ol

---

From: Andrew Newton <[email-masked]>
Date: Tue, 22 Aug 2006 12:44:44 -0400

> it is not just peering, but also transit.
[..snip..]
> into the protocol design.

You are cavalierly dismissing a real world consideration for an 
as-yet-to-be-defined specification.

Additionally, the whole notion of designing for federations, as has been 
talked about in this working group, goes against the very principle from 
which you have drawn your conclusion.

-andy