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

From: "Stastny Richard" <[email-masked]>
Date: Sat, 27 May 2006 13:26:23 +0200

>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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sat, 27 May 2006 15:30:22 -0400

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

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Saturday, May 27, 2006 4:26 AM
> To: Reinaldo Penno; Otmar Lendl
> Cc: [email-masked]

---

From: Duane <[email-masked]>
Date: Sat, 27 May 2006 15:36:46 -0400

> (and surprised), since LNP has been fully deployed since 2003. 

ENUM can quite easily handle LNP in a single root tree, but as soon as 
you start issuing NS records you can forget it...

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 28 May 2006 13:57:37 -0400

Here .. read the soon to be RFC.

Richard is right anything that looks like number translation is a ENUM issue
everything else is SPEERMINT.

############

two week WG last call on this document concluded on Feb 6, 2006.

The document listed below is being proposed for Standards Track RFC.

Status- Proposed Standard

Title  : IANA Registration for an Enumservice Containing PSTN Signaling
Information
 Author(s) : J. Livingood, R. Shockey
 Filename : draft-ietf-enum-pstn-03.txt
 Pages  : 12
 Date  : 2006-1-18
 
This document registers the Enumservice type "pstn" and subtype "tel"
    using the URI scheme 'tel', as well as the subtype " sip" using the
    URI scheme 'sip' as per the IANA registration process defined in the
    ENUM specification, RFC 3761.  This Enumservice is used to facilitate
    the routing of telephone calls in those countries where Number
    Portability exists.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-03.txt

--

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Saturday, May 27, 2006 3:30 PM
> To: Stastny Richard; Otmar Lendl
> Cc: [email-masked]
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 28 May 2006 14:33:08 -0400

Richard,

It seems we are not communicating at all. Did you actually read the
thread from the beginning? What this "soon to be" RFC has to do with the
original discussion between Otmar and me?

What is the "Richard is right" thing? Are you talking about yourself in
the third person, forwarding an email or what?

-Reinaldo

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Sunday, May 28, 2006 10:58 AM
> To: Reinaldo Penno; 'Stastny Richard'; 'Otmar Lendl'
> Cc: [email-masked]
> > > > > 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