Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Stastny Richard" <[email-masked]>
Date: Sun, 28 May 2006 10:07:20 +0200

I do not know how often I stated here that numbering issues 
(and therefore also NUMBER Portability issues) are out-of-scope
in SPEERMINT
 
So NUMBER Portablility cannot ne addressed in SPEERMINT LF
 
Or we change the SPEERMINT charter
 
Richard

________________________________

Von: Khan, Sohel Q [CTO] [mailto:[email-masked]]
Gesendet: So 28.05.2006 06:48
An: Stastny Richard; Reinaldo Penno
Cc: [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I think issues of mobility and number portability need to be addressed together in SPEERMINT LF.

Sohel Khan, Ph.D.
Sprint-Nextel

-----Original Message-----
From: "Stastny Richard" <[email-masked]>
To: "Reinaldo Penno" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 5/27/06 4:52 PM
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

What question?
Richard

________________________________

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Sa 27.05.2006 23:46
An: Stastny Richard
Cc: [email-masked]
Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Apart form your outside-of-the-us rhetoric the questions remains.

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Saturday, May 27, 2006 2:38 PM
> To: Reinaldo Penno
> Cc: [email-masked]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
>
> ENUM issues should not be discussed in SPEERMINT,
> just some questions
>
> >Enum? When I dial (650) 453 2312, what is there to resolve _inside_
the
> >wireless network that owns this number apart from the location of the
> >user?
>
> and _outside_?
> ENUM is about numbers like +16504532312
>
> hello, we are talking E.164 numbers in ENUM, which is international
> numbers
>
> >Now, in the scenario where an external call (for example, a cingular
> >customer calling a Verizon customer (which owns an original t-mobile
> >number). How that works today? If you say ENUM I would stand
corrected
> >(and surprised), since LNP has been fully deployed since 2003.
>
> Cingular?Verizon? ...
>
> we are talking about a global solution here
> You are a bit US centric here,
> there is also some 200 other nations ozt there.
>
> I have no access to the US LNP database from e.g. Austria
>
> So you want to consider US national databases only in speermint?
>
> Richard
>
>
>
> ________________________________
>
> Von: Reinaldo Penno [mailto:[email-masked]]
> Gesendet: Sa 27.05.2006 21:30
> An: Stastny Richard; Otmar Lendl
> Cc: [email-masked]
> Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
>
>
>
> Enum? When I dial (650) 453 2312, what is there to resolve _inside_
the
> wireless network that owns this number apart from the location of the
> user?
>
>
> Now, in the scenario where an external call (for example, a cingular
> customer calling a Verizon customer (which owns an original t-mobile
> number). How that works today? If you say ENUM I would stand corrected
> (and surprised), since LNP has been fully deployed since 2003.
>
> When a user takes its number with them, I assumed this punches a whole
> in the telephone prefix hierarchy and a specific entry somewhere is
> needed.
>
> Regards,
>
> Reinaldo
>
>
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Saturday, May 27, 2006 4:26 AM
> > To: Reinaldo Penno; Otmar Lendl
> > Cc: [email-masked]
> > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> > >I wonder how
> > >LNP is solved within wireless...A specific entry for each phone?
That
> > >would be crazy.
> >
> > Ahem, ENUM?
> >
> > I thought that is all what ENUM is about?
> >
> > Richard
> >
> >
> > ________________________________
> >
> > Von: Reinaldo Penno [mailto:[email-masked]]
> > Gesendet: Sa 27.05.2006 11:04
> > An: Otmar Lendl; Patrick Melampy
> > Cc: Khan, Sohel Q [CTO]; [email-masked]
> > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> >
> >
> > Hello,
> >
> > I believe the crux of the problem was missed.
> >
> > The issue is not really the number of domains. We have today some
> > 400.000.000 million hosts on the Internet. BGP peers to do not
> exchange
> > 400.000.000 million routes, they exchange in the low hundreds of
> > thousands.
> >
> > And why is that? (I guess you know where I'm getting at). That's
> because
> > IP addresses lend themselves very well to hierarchical deployment,
> > compression through prefix/CIDR usage and the like. DNS names are
> > strings and hence difficult to come up with a similar scheme.
> >
> >
> > I believe that if domains need to be exchanged between peers:
> >
> > 1 - Just a limited set would be exchanged and a "default layer 5
> route"
> > (equivalent to a traditional default route) would be used.
> >
> > 2 - Compression schemes like *.company.com, regular expressions or
the
> > like would need to be used. Having specific routes to AORs would be
> > hairy (maybe for the eventual roaming or visiting user). I wonder
how
> > LNP is solved within wireless...A specific entry for each phone?
That
> > would be crazy.
> >
> > 3 - Some new scheme that will make somebody rich....until then..
> >
> > I believe subscriptions would be used to exchange mostly "cost" and
> > policy information and some domains. I use cost here in the layer 3
> > sense (number of calls, jitter, whatever). Cost would be an abstract
> > value or a more specific one (up to the administrator).
> >
> > Regards,
> >
> > Reinaldo
> >
> > > -----Original Message-----
> > > From: Otmar Lendl [mailto:[email-masked]]
> > > Sent: Saturday, May 27, 2006 1:29 AM
> > > To: Patrick Melampy
> > > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> Architecture
> > >
> > > On 2006/05/26 18:05, Patrick Melampy <[email-masked]>
> wrote:
> > > > I suppose like in any distributed routing protocol, there are
some
> > > chicken
> > > > an egg issues. But consider the following.
> > > >
> > > > PREREQUISITES:
> > > > 1.) You know the destination DOMAIN from either ENUM or other
> means.
> > >
> > > [...]
> > > >
> > > > This technique is very similar to TRIP, only its for DOMAINS and
> not
> > > partial
> > > > E.164 numbers.
> > >
> > > [...]
> > >
> > > > Obviously, the data set could get large, as the list of domains
> can
> > be
> > > > really big. There are some possibilities here...
> > >
> > > Let's do a quick estimate on the number of domains involved:
> > >
> > > Right now, operators usually give customers URIs of the form
> > > <number>@<providerdomain>. As long as this is the state of
affairs,
> > > we're fine as the number of providers is quite finite (a few
> > > thousands, perhaps).
> > >
> > > This is like the state of affairs with respect to email, anno
1990.
> > > Back then customers started to notice that if they use their own
> > domain
> > > for email, then they can switch providers without having to change
> > > their email address. Thus a *lot* of people opted to use their
> > > own domain for email.
> > >
> > > My guess is that the same will happen to SIP. Once customers print
> > > their SIP uris on business cards, they will want to use their own
> > > domains. If providers won't support that feature then I suspect
that
> > > the regulators will step in and mandate an URI portability
solution
> > > just as they did in the PSTN with respect to numbers from number
> > blocks.
> > > (This could get really nasty protocol-wise, so I guess using
> customer-
> > > owned domains is the far better and likelier solution to the
porting
> > > question.)
> > >
> > > So: Anything we come up with here in SPEERMINT needs to cope with
a
> > > scenario where the use of customer domains in SIP URIs is just as
> > > widespread as it is for email.
> > >
> > > How many domains are used for email? That's hard to say. There are
> > > about 60 million gTLD domains and probably more than 20 ccTLD
ones.
> > > Assuming that only a tenth of that is used for email we're at
> > > 8 million domains. Given the exponential growth any system which
> > > doesn't scale to at least 10 million domains will be obsolete
before
> > > the ink is dry on the RFC.
> > >
> > > So what happens if we do some sort of BGP or TRIP with domains?
> > >
> > > Let's say we need at least 100 bytes of state information per
> domain.
> > > That makes a full routing table 1 GB worth of data. That also
means
> > > that a new border element needs to exchange that amount of data
> > > with its peers before it has learned the current state of the
> > > routing table.
> > >
> > > That is some serious amount of data.
> > >
> > > > 1.) Have notification point to a published document, and the
> > document
> > > lists
> > > > all of the relevant reachability in real time. Thus any change
to
> > the
> > > > document would generate a NOTIFICATION.
> > >
> > > + a download of up to 1 GB per peer.
> > >
> > > > 2.) User partial domains, broken up by the "dots". This may
allow
> > some
> > > > wildcarding to reduce the number of domains. For instance, a
> carrier
> > > like
> > > > Verizon may have many 100's of domains attached to it, and
version
> > is
> > > > willing to route and manage SIP traffic to any of them. The
NOTIFY
> > could
> > > > contain something like: Verizon.com or *.verizon.com to indicate
> > that
> > > any
> > > > domain in Verizon is reachable.
> > >
> > > That's helpful if a provider uses subdomains for internal
purposes,
> > > but that won't help you with customer owned domains.
> > >
> > > > This technique may work -- and fit nicely into an existing
> protocol.
> > All
> > > we
> > > > would need to do is define the data models (XML?) and or
documents
> > for
> > > > exchanging.
> > >
> > > I think this technique can work -- if you add an aggregation step
> > > before the routing scheme.
> > >
> > > Take another look at BGP: there you have the concept of an
> > > Autonomous System and not only that of prefixes. Maybe you need
> > > something similar.
> > >
> > > One approach to cope with hosted SIP domains could be to use the
> > > hostnames as found in SRV records. E.g. for settings like
> > >
> > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com
> > >
> > > run the routing algorithm on "sip.provider.com" instead
> > > of "customer.domain".
> > >
> > > Another option is to store some AS-equivalent in the customer
domain
> > > and have the routing algorithm operate on that. In my
domain-policy
> > > framework this could be expressed e.g. like
> > >
> > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > >
> > > stating that this domain can be reached using the Speermint
routing
> > > logic by using the learned route to RoutingID 1042.
> > >
> > > Or, even better, use non-terminals, and thus refer to the ingress
> > > policy stored in the provider's domain:
> > >
> > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com
> > >
> > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > >
> > > (+ whatever other facts provider.com wants to announce about his
> > > reachability.)
> > >
> > > This combination of our ideas can indeed work and scale to an
> > > unlimited number of customer-owned domains.
> > >
> > > /ol
> > > --
> > > < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint

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

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

---

From: "Nieminen Klaus" <[email-masked]>
Date: Sun, 28 May 2006 23:30:11 +0300

Hi folks,
 
Richard is right. From the charter:
 
> Issues that are out of scope for SPEERMINT include: 
>
> Routing of sessions which are not signaled using SIP. In
> particular, SPEERMINT is constrained to consider only those
> scenarios in which call routing is signaled using the SIP
> protocol and addressed by SIP or SIPS URIs. E.164 numbers and
> other national or private formats may only be used as defined
> within the SIP protocols, and 

So SPEERMINT is using only SIP/SIPS URIs, not E.164 numbers, so there is no number portability issue for SPEERMINT.
 
However, I understand that you need a mechanism to do cope with NP also in the SIP interconnection case and that can be done using infrastructure ENUM (in fact we are now discussing implementing one in Finland). The right place to discuss infrastructure ENUM is the ENUM WG.
 
I do not know if this is also out of our current scope, but I would like to discuss transferring charging/tariff information between providers in realtime. I want to raise this question, because at least in Finland we have been used to transferring charging information (pulse charging) in PSTN interconnection interface. This is for example used also in value added services that are billed by the caller's operator.

And I believe that we are not only ones that see this capability benefical. In fact it is required, if we want to enable SIP-based interconnection also for premium rate numbers and I consider it quite essential. 
 
Therefore, I want to ask that do you see that we need a mechanism to transfer charging data in SIP interconnection interface and do we have anything ready for that?
 
regards,
 
- Klaus -

Lähettäjä: Stastny Richard [mailto:[email-masked]]
Lähetetty: su 28.5.2006 11:07
Vastaanottaja: Khan, Sohel Q [CTO]
Kopio: [email-masked]
Aihe: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Richard

Sohel Khan, Ph.D.
Sprint-Nextel

---

From: "Francois D. Menard" <[email-masked]>
Date: Mon, 29 May 2006 09:45:49 -0400

Klaus,
 
I've always thought we could put some Open Settlement Protocol XML data in a
SIP invite.
 
F.
 
--
François D. Ménard
Chargé de projet
Xit télécom inc.
1350 rue Royale #800
Trois-Rivières, QC, G9A 4J4
Canada
[email-masked]
Tel: (819) 374-2556 ext. 268
Fax: (819) 374-0395
Cell: (819) 692-1383

  _____  

From: Nieminen Klaus [mailto:[email-masked]] 
Sent: 28 mai 2006 16:30
To: [email-masked]
Subject: VS: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Hi folks,

> within the SIP protocols, and 

So SPEERMINT is using only SIP/SIPS URIs, not E.164 numbers, so there is no
number portability issue for SPEERMINT.
 
However, I understand that you need a mechanism to do cope with NP also in
the SIP interconnection case and that can be done using infrastructure ENUM
(in fact we are now discussing implementing one in Finland). The right place
to discuss infrastructure ENUM is the ENUM WG.
 
I do not know if this is also out of our current scope, but I would like to
discuss transferring charging/tariff information between providers in
realtime. I want to raise this question, because at least in Finland we have
been used to transferring charging information (pulse charging) in PSTN
interconnection interface. This is for example used also in value added
services that are billed by the caller's operator.

And I believe that we are not only ones that see this capability benefical.
In fact it is required, if we want to enable SIP-based interconnection also
for premium rate numbers and I consider it quite essential. 
 
Therefore, I want to ask that do you see that we need a mechanism to
transfer charging data in SIP interconnection interface and do we have
anything ready for that?
 
regards,
 
- Klaus -

  _____  

Richard

I think issues of mobility and number portability need to be addressed
together in SPEERMINT LF.

Sohel Khan, Ph.D.
Sprint-Nextel

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 29 May 2006 18:03:35 -0400

You might think that and Alan Johnston did some work on this in SIPPING but
it seems no one cares…plus there are real issues of wether OSP can scale to
the number of transactions necessary to support this kind of thing.

Boys and Girls … in case you had not heard transaction pricing for voice is
not all that popular among consumers these days.

Transaction or distance based pricing for communications has not been
popular since the establishment of the penny post in the UK in the 1800’s.

http://www.dtc.umn.edu/~odlyzko/doc/history.communications0.pdf

BTW Content is not king.

http://firstmonday.org/issues/issue6_2/odlyzko/

  _____  

From: Francois D. Menard [mailto:[email-masked]] 
Sent: Monday, May 29, 2006 9:46 AM
To: 'Nieminen Klaus'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Klaus,

F.

--

François D. Ménard

Chargé de projet

Xit télécom inc.

1350 rue Royale #800

Canada

[email-masked]

Fax: (819) 374-0395

Cell: (819) 692-1383