Subject: [Speermint] Use cases and categorization

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 14 Feb 2007 13:14:27 -0500

Couple questions for folks...

We are working on a consolidation of use cases for SPEERMINT - and in
that effort, we have acknowledged 3 categories of use cases: Direct,
Indirect and Assisted.  This falls inline with the terminology draft.
With that in mind...

1) Per the definition of a 'Federation' in the terminology draft - "A
federation is a group of SPs 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."  I read this to mean that any
and all of the above peering categorizations involve the use of a
Federation.  Do we have consensus on that?

2) Should we address any nuances between Enterprises and SPs as it
pertains to the above categorizations?  

I appreciate any and all thoughts on the topics.

Adam Uzelac
Principal Network Eng./Sr. Manager Converged Arch.
Global Crossing
585-255-8916

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

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Wed, 14 Feb 2007 18:11:00 -0500

Regarding question (2) - Enterprise peering cases should be addressed
but I don't think they impact the categorization. John Elwell and I have
a draft on enterprise use-cases to be submitted very shortly, and it is
in line with the direct/indirect categories.

Benny 

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 1:14 PM
To: [email-masked]
Subject: [Speermint] Use cases and categorization

Adam Uzelac

---

From: "David Schwartz" <[email-masked]>
Date: Thu, 15 Feb 2007 10:34:37 +0200

Hi Adam

> pertains to the above categorizations?  

I have always preferred the term aggregator to service provider as the
point to focus on is that peering involves interconnection between two
(or more) parties that represent many more entities. With that in mind I
see no reason to differentiate between SP's and enterprises (some of
which are larger than many SP's) since both are performing the
"aggregation" function.

IMHO, the relationship between the "aggregator" (SP or enterprise) and
its subscriber base should be of no concern to us.

D.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 15 Feb 2007 11:26:16 +0100

To Adam and David,

> > Federation.  Do we have consensus on that?

IMO the federation encompasses all:
On one hand you have a federation of two (in a pure bilateral agreement)
and on the other hand you may have a federation of all service providers
for a global federation

> its subscriber base should be of no concern to us.

I am not so sure: technically yes, but not legally

At least in the current legal regime (PSTN) enterprises are below
service
providers and numbers are assigned from NRA to service providers, which
in
turn assign numbers to subscribers. SP interconnect with NNIs.
Enterprises are connected via UNIs. There are also differences in number
portability.

Since regulations claim to be "technology" neutral, we have to be
careful.

Richard

---

From: "David Schwartz" <[email-masked]>
Date: Thu, 15 Feb 2007 13:05:30 +0200

Hi Richard.

I am not sure I understand why application based peering (which is what
I thought SPEERMINT was all about) needs to be concerned with UNI vs.
NNI considerations.

As for number portability this brings up many of the "ownership" issues
that have been discussed before. In many (most?) cases SP's are not
carriers of record for the numbers so in a sense they do not "own" the
numbers they then assign to the enterprise. Differentiating between the
two based on levels down the "ownership" tree is artificial.

Cheers,

D.

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 12:26 PM
To: David Schwartz; Uzelac, Adam; [email-masked]
Subject: RE: [Speermint] Use cases and categorization

To Adam and David,

Richard

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 15 Feb 2007 12:27:15 +0100

Hi David,

Yes and no

For pure Speermint issues (peering with AoR) this is not an issue,
as is NP not an issue

And the term carrier-of-record is only used with E.164 numbers
But as numbering always pops up in Speermint too, it may be an issue

> two based on levels down the "ownership" tree is artificial.
First, nobody "owns" a number

Numbers are allocated to SP and assigned to end-users

Enterprises are also end-users like normal subscribers,
e.g. in Austria there is no difference in principal

I have the number +43 1 9793321 at home and may decide tomorrow
to add a PBX with two digits in addition such as +43 1 9793321 xx

I can port this number (the pilot) to IP (it is, in fact) and run a SER.
I am now a SP for the +43 1 9793321 xx number range, am I?

What is not possible is that e.g. +43 1 9793321 24 is ported to another
SP.

What is now the difference between Siemens, IBM and my home enterprise?
The size?

Or is anybody running a proxy a SP?
Can I port a number to myself?

Or do we have different rules for numbers on IP and on the PSTN?
As I said, this is not (only) a technical issue, it is mainly a legal
issue.

Cheers
Richard

> > > technical details of the interconnection."  I read this to mean
that
> > any
> > (or more) parties that represent many more entities. With that in
mind
> I

---

From: "Uzelac, Adam" <[email-masked]>
Date: Thu, 15 Feb 2007 08:17:09 -0500

Generally speaking, what are the differences between the use cases that
you have captured versus the use cases that have already been captured?
At an interim Speermint meeting last summer (Philly) there was some
rather lively discussions on this point, as well as in San Diego.  

Thanks in advance.

-AU 

> From: Rodrig, Benny (Benny) [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 6:11 PM
> To: Uzelac, Adam
> Cc: [email-masked]
> Regarding question (2) - Enterprise peering cases should be 
> addressed but I don't think they impact the categorization. 
> John Elwell and I have a draft on enterprise use-cases to be 
> submitted very shortly, and it is in line with the 
> direct/indirect categories.
> 
> Benny 
> 
> We are working on a consolidation of use cases for SPEERMINT 
> - and in that effort, we have acknowledged 3 categories of 
> use cases: Direct, Indirect and Assisted.  This falls inline 
> with the terminology draft.
> With that in mind...
> 
> 1) Per the definition of a 'Federation' in the terminology 
> draft - "A federation is a group of SPs 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."  I read this to mean that 
> any and all of the above peering categorizations involve the 
> use of a Federation.  Do we have consensus on that?
> 
> 2) Should we address any nuances between Enterprises and SPs 
> as it pertains to the above categorizations?  
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Thu, 15 Feb 2007 08:28:32 -0500

Richard,

Very interesting with the NNI versus UNI analogy and phone numbers.
With a focus on the NA market - allow me to look more into this NNI
versus UNI analogy as it pertains to the Speermint.  Level3 and Global
Crossing (two SPs) exchanging traffic is, I believe, a NNI scenario.
Take any Enterprise and any SP, and we have ourselves a UNI scenario.
Now what about the gray areas?  We could possibly categorize some
non-LERG SPs (or "Aggregators") as only accessible via an UNI due to the
fact that they are not a CLEC/LEC/IXC/etc.  I think that it could be a
very slippery slope.  

For this work we are doing here, I don't think we should make a
distinction.

-AU

> Sent: Thursday, February 15, 2007 5:26 AM
> > > technical details of the interconnection."  I read this 
> to mean that
> > any
> On one hand you have a federation of two (in a pure bilateral 
> agreement) and on the other hand you may have a federation of 
> all service providers for a global federation
> 
> 
> > >
> > (or more) parties that represent many more entities. With 
> that in mind
> I
> At least in the current legal regime (PSTN) enterprises are 
> below service providers and numbers are assigned from NRA to 
> service providers, which in turn assign numbers to 
> subscribers. SP interconnect with NNIs.
> Enterprises are connected via UNIs. There are also 
> differences in number portability.
> 
> Since regulations claim to be "technology" neutral, we have 
> to be careful.
> 
> Richard
> 
> 
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 15 Feb 2007 15:18:14 +0100

Adam,

> fact that they are not a CLEC/LEC/IXC/etc.  I think that it could be a

Indeed

We have basically three major scenarios:

-Interconnection of SP (Carrier-of-Records, CLEC/LEC/IXC, 
whatever you name it) direct or via aggregators

-Interconnections of SP with end-users having proxies
This is the UNI the SIP Forum already specified

-Interconnections of end-users having proxies, e.g. enterprises
or corporations (small and large), direct or via aggregators

In this case we have in addition to look at the requirements from them
These where e.g. articulated at TISPAN from ECMA TC32/TC17
They want to build so-called NGCN (C for corporate), which may both
interconnect with SPs, but also directly between them, in all
combinations

> For this work we are doing here, I don't think we should make a

Now, as long as we stick to our charter and keep E.164 numbers out of
the picture and use only SIP AoRs, we do not need to make a distinction,
because we only talk about administrative domains

But some people here say (and I know them all ,-), in practice we
deal only with the mapping from E.164 numbers to ingress points
in "networks"

In this case this is an issue and we have to make a distinction

Richard

> > > > 1) Per the definition of a 'Federation' in the terminology draft
-
> > "A
> > > > other via SIP, and who agree on a set of administrative rules
for
> > such
> > > > calls (settlement, abuse-handling, ...) and the specific rules
for
> > the

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 15 Feb 2007 10:42:35 -0500

> as it pertains to the above categorizations?  

I would consider this an implementation detail.  The "charter" for the
federation can cover details as this or even any arrangements as to
whether calls are billed or not, and if so, how; and other details of
the business layer overlayed on top of the basic connectivity
possibilities.

Such business details can be a tarball.  Best not to go there.

Mike

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Thu, 15 Feb 2007 11:23:31 -0500

Adam,

The enterprise peering use cases we have captured are actually similar
to service-provider cases and don't show a major difference, but only
potential differences in some details e.g. regulatory aspects and the
possibility of using low-granularity number ranges for routing. 

Benny

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 8:17 AM
To: Rodrig, Benny (Benny)
Cc: [email-masked]
Subject: RE: [Speermint] Use cases and categorization

Thanks in advance.

-AU 

> but I don't think they impact the categorization.
> John Elwell and I have a draft on enterprise use-cases to be submitted

> very shortly, and it is in line with the direct/indirect categories.
> 
> Benny
> 
> - and in that effort, we have acknowledged 3 categories of use cases: 
> Direct, Indirect and Assisted.  This falls inline with the terminology

> draft.

> technical details of the interconnection."  I read this to mean that 
> any and all of the above peering categorizations involve the use of a

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 16 Feb 2007 06:33:54 +0100

How do you come to the conclusion that 

> Take any Enterprise and any SP, and we have ourselves a UNI scenario.

?

That may be the status quo with the ISDN at the moment, where the
distinction is enforced by a different protocol, but when we move to a
SIP environment, the difference to me seems more regulatory than
technical.

A public network operator is different from a private network operator
only because the regulatory regime defines a class called public network
operator.

Or do you actually identify something technical?

Regards

Keith

> Sent: 15 February 2007 13:29
> To: Stastny Richard; David Schwartz; [email-masked]
> With a focus on the NA market - allow me to look more into 
> this NNI versus UNI analogy as it pertains to the Speermint.  
> Level3 and Global Crossing (two SPs) exchanging traffic is, I 
> believe, a NNI scenario.
> Now what about the gray areas?  We could possibly categorize 
> some non-LERG SPs (or "Aggregators") as only accessible via 
> an UNI due to the fact that they are not a CLEC/LEC/IXC/etc.  
> I think that it could be a very slippery slope.  
> 
> For this work we are doing here, I don't think we should make 
> a distinction.
> 
> -AU
> 
> > > > 1) Per the definition of a 'Federation' in the 
> terminology draft -
> > "A
> > > > other via SIP, and who agree on a set of administrative 
> rules for
> > such
> > > > calls (settlement, abuse-handling, ...) and the 
> specific rules for
> > the
> > agreement) and on the other hand you may have a federation of all 
> > service providers for a global federation
> > 
> > 
> > > >
> > service providers and numbers are assigned from NRA to service 
> > providers, which in turn assign numbers to subscribers. SP 
> > interconnect with NNIs.
> > Enterprises are connected via UNIs. There are also differences in 
> > number portability.
> >

---

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 16 Feb 2007 10:47:54 -0500

Keith,

Absolutely nothing technical in the comments I made. ;) Some more
thoughts...the NNI/UNI scenarios are within the context of E164
addressing and regulatory rule-sets.  Because of that context, it's
really out of scope for Speermint. If you remove the regulatory context,
then I agree with you 100% my statement "Take any Enterprise and any SP,
and we have ourselves a UNI scenario." makes no sense.

On a bit of a different topic, I have recently been trying to understand
the utter lack of engaged folks in this working group.  I don't believe
it's due to a lack of "sip peering" in the world. Could it be that the
technical discussions often become clouded with non-technical
(regulatory, business) requirements?  Could it be explained by a lack of
non-technical appreciation within the discussions, therefore any
solutions are immediately marginalized?  My intention is not to support
the regulatory regime, rather to understand the lack of engagement.

Let the flames begin.

-AU

> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: Friday, February 16, 2007 12:34 AM
> To: Uzelac, Adam; Stastny Richard; David Schwartz; [email-masked]
> That may be the status quo with the ISDN at the moment, where 
> the distinction is enforced by a different protocol, but when 
> we move to a SIP environment, the difference to me seems more 
> regulatory than technical.
> 
> A public network operator is different from a private network 
> operator only because the regulatory regime defines a class 
> called public network operator.
> 
> > versus UNI analogy as it pertains to the Speermint.
> > Level3 and Global Crossing (two SPs) exchanging traffic is, 
> I believe, 
> > a NNI scenario.
> > non-LERG SPs (or "Aggregators") as only accessible via an 
> UNI due to 
> > the fact that they are not a CLEC/LEC/IXC/etc.

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 16 Feb 2007 16:09:01 -0500

That draft is available at
http://www.ietf.org/internet-drafts/draft-elwell-speermint-enterprise-us
ecases-00.txt

This will be reviewed in Prague.  Assuming the WG finds the draft's
cases worthwhile, we will seek to consolidate them into the draft Adam
was discussing.  You all may want to get a head start on looking at the
draft and considering how to do this work.

Thank you
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 16 Feb 2007 16:12:45 -0500

I hope you are not seriously suggesting yet another term "aggregator"
for the terminology draft?  I know we all like to be creative in our own
ways with word-smithing, but can we stick with existing terms unless
there's a major disconnect?  ;-)

Jason 

> From: David Schwartz [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2007 3:35 AM
> To: Uzelac, Adam; [email-masked]
> draft - "A 
> rules for such 
> I have always preferred the term aggregator to service 
> provider as the point to focus on is that peering involves 
> interconnection between two (or more) parties that represent 
> many more entities. With that in mind I see no reason to 
> differentiate between SP's and enterprises (some of which are 
> larger than many SP's) since both are performing the 
> "aggregation" function.
> 
> IMHO, the relationship between the "aggregator" (SP or 
> enterprise) and its subscriber base should be of no concern to us.
> 
> D.
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 16 Feb 2007 16:15:42 -0500

I think what I hope to see is that you two guys can "sit down together"
(in the virtual sense) and see where there is overlap and where there
are new use cases, that would end up dictating additional/special
requirements...

We'll hear a presentation on this draft in Prague but if you guys are
able to do some work beforehand, that would be helpful.  Heck, I'll even
buy a round of beers for you.  ;-)

Jason 

> Sent: Thursday, February 15, 2007 11:24 AM
> To: Uzelac, Adam
> Cc: [email-masked]
> The enterprise peering use cases we have captured are 
> actually similar to service-provider cases and don't show a 
> major difference, but only potential differences in some 
> details e.g. regulatory aspects and the possibility of using 
> low-granularity number ranges for routing. 
> 
> Benny
> 
> Generally speaking, what are the differences between the use 
> cases that you have captured versus the use cases that have 
> already been captured?
> At an interim Speermint meeting last summer (Philly) there 
> was some rather lively discussions on this point, as well as 
> in San Diego.  
> 
> Thanks in advance.
> 
> -AU 
> 
> addressed 
> use cases: