Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

[Otmar Lendl <[e-mail]>]

On 2006/05/26 18:05, Patrick Melampy <[e-mail]> 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 ([e-mail]) | nic.at Systems Engineer >

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