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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 6 Jun 2006 10:50:52 -0400

All, I am back from vacation and find a very long and interesting
thread.  I was trying to hold off responding till I read all 130+
messages but am finding it difficult to remember and resist, so pardon
me if I restate something here.

First, the goal is to reach domains, so the routing to E.164 numbers
should be out of scope -- no reinventing TRIP.  We turn E.164 into sip
addresses and then route on the domains.

>From the domain we should be able to look up direct signaling points or
indirectly policy points.  In some cases, we may find federation
information, then need to think about how to route to that federation.

I think the discussion about number of domains and BGP-like stuff is
barking up the wrong tree.  Oh, BTW there are about 3000 carriers in the
USA alone and roughly 8000 public enterprises (publicly traded stock) in
the USA.  But, I think that misses the point.

I believe the reality will be that there will ultimately be two options:
 - from one SP (carrier/enterprise) to another there is direct peering,
 - from one SP to another there is no direct peering and a "Tier 1" SP
will be used for transit.

There will be some rather large SPs (think ATT, Sprint, name you
favorite PTT) that will be all too willing to be the transit carrier and
solve the bridging problem, and many enterprises or individuals will be
all too willing to let them do that.

The federations may thus be a means of aggregating the sip routing
problem and making it scalable.  The federation then becomes a default
route for the Tier 2 SP.  I suspect that the sequence will look
something like:

E.164 -> sip:[email-masked]

   - at this point the originating SP can determine if it has a peering
throug internal means,
   - if not:

termination-SP.com -> terminating-federation.com

   - at this point the originating SP can determine if it belongs to
that same federation,
   - if not, the end result will be:

Request-URI: sip:[email-masked]   -- points to target SP
Route: originating-federation.com           -- points to near side if
not common federation
Route: terminating-federation.com           -- points to far side
federation

originating-federation -> translates to my transit SP.

I may have abused the federation concept a bit, given that there is both
the qualitative aspect of having a common agreement on how to
interconnect, and the routing aspect which anticipates that a federation
may be formed around a large SP that has the IP network to connect to
all the SPs that sign up for that "federation".  I'll confess that there
is some legacy precedent here.  But, that may be the most viable short
term evolution path.

My thinking, if it is not obvious is that the optimal number of SPs is 2
(direct peering).
Second best is 3 (one transit).  
Maximum number is 4 (one originating and one terminating transit).  

I believe that hopping across 10 SIP signaling networks would be a sure
sign that our work here has failed, and that is what I fear the BGP
discussion would lead us to.

Mike

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Saturday, May 27, 2006 7: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: "Uzelac, Adam" <[email-masked]>
Date: Wed, 7 Jun 2006 10:35:23 -0400

Mike - I agree with what you are saying here, or more importantly how I
am reading what you are saying.  Some points below:

-It's important to avoid the "hopping across 10 SIP signaling networks"
scenario. AGREED.
-I think it's important to state and acknowledge that we aren't going to
ever see one big globally pertinent "CRD database" in the sky that is
mutually owned and shared.  Hence the value of "routing to a Federation"
instead of the ultimate terminating network. Does it make any difference
that access to the Federation is via a transitory relationship (your
"tier 1" provider example)?!?!  If both the originating and terminating
networks were members of the same Federation, then a direct relationship
can be established and or facilitated be the "authoritative" body of the
Federation.
-It's been identified on this list before that there is a finite limit
to the number of "peering relationships" that an orig domain can
maintain effective. With that in mind, there must be some summary
mechanism.  As you note, the ultimate goal is to reach domains.  That
reachability can either be direct, or through Federation alignment.  The
Federation concept alleviates the burden of both the central db in the
sky, as well as of the orig domain to peer with everyone to facilitate a
full mesh.  

Otmar Lendl via draft-lendl-speermint-federations-00 suggests a method
to disseminate Federation membership, but this is via DNS, and therefore
out of scope for Speermint.  At the end of the day, Speermint routes to
either the terminating domain and/or the Federation where terminating
domain is a member.  

Adam

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 10:51 AM
To: Stastny Richard; Reinaldo Penno; Otmar Lendl
Cc: [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Mike

> 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.
> 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.
> 
> 
> 1 - Just a limited set would be exchanged and a "default layer 5 
> route"
> 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.
> 
> 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
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 7 Jun 2006 12:25:33 -0400

I make the out of scope statement because I am of the mindset that the
SPEERMINT scope kicks in after resolution of the AoR - to me this means
that Speermint can assume knowledge of domain and federation from DNS,
and then use that CRD appropriately.  I might have this wrong though -
but that was what I was thinking.

-Adam 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Wednesday, June 07, 2006 12:11 PM
To: Uzelac, Adam
Cc: Michael Hammer (mhammer); Stastny Richard; Reinaldo Penno;
[email-masked]

> reachability can either be direct, or through Federation alignment.  
> The Federation concept alleviates the burden of both the central db in

> the sky, as well as of the orig domain to peer with everyone to 
> facilitate a full mesh.

Correct.

> to disseminate Federation membership, but this is via DNS, and 
> therefore out of scope for Speermint.

ENUM is out of scope for speermint, as it deals with E.164 numbers.

draft-lendl-speermint-federations-00 operates on the domain part of SIP
URIs. I see no conflict with the SPEERMINT charter.

Can you elaborate why you think that
draft-lendl-speermint-federations-00
is out of scope?

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 7 Jun 2006 18:10:53 +0200

Correct.

> out of scope for Speermint.  

draft-lendl-speermint-federations-00 operates on the domain part of
SIP URIs. I see no conflict with the SPEERMINT charter.

Can you elaborate why you think that draft-lendl-speermint-federations-00 
is out of scope?

/ol

---

From: "Patrick Melampy" <[email-masked]>
Date: Mon, 12 Jun 2006 21:34:27 -0400

I'd like to comment as follows:

>  will be used for transit.

Unless somebody representing a carrier makes this statement, it's safe to
say we are just guessing. I find this statement your making to lack any
backing. How many Autonomous Systems do your communications go through
today? When you're at work? When you're at home? I'm guessing you have no
idea. Why should this group ever designate a role for a Tier 1 SP as a
required internetworking element? If you worked at a competitive Tier 2 you
might take exception to your statement.

> My thinking, if it is not obvious is that the optimal number of SPs is 2

Optimal in whose frame of reference? The internet's? The caller? The callee?
The carrier(s)? My guess is your thinking of the internet. 

> Second best is 3 (one transit).  
Why is one transit carrier better than 2 or 3? Is it cost? Quality? Where
did this conclusion come from? Are there any IP based models where a single
backbone carrier is considered optimal? Doesn't this limit competition and
choice? Wouldn't it be anti-competitive, and thus not be net-neutral?

>Maximum number is 4 (one originating and one terminating transit).

Why is this the maxium? 

I hate to argue with your statements, but they should be better defended.
There are a lot of managed networks that are both legislated and or
pre-existing. The owners of long haul fiber networks want to use them for
signaled media. My guess is we will not only have One Tier 1 to choose from,
but the following:

1.) Each Enterprise will desire at least 2 interconnect carriers to ensure
they have the lowest cost and best level of service with redundancy.

2.) Each Tier 1 Carrier will want to purchase termination services for its
customers and have multiple paths to each major desination domain

3.) Many Tier 2 and Tier 3 carriers will exist by selecting specific target
markets and verticals.

4.) Governments will continue to try to enforce regulations guaranteeing a
competitive landscape for communication interconnects (requiring access for
2nd and 3rd carrier options.

I could go on and on. I would suggest that we embrace the realities of our
world as requirements for this standards group.