RE: [Speermint] Defining Location Function (RE: Updated Draft:SPEERMINT Peering Architecture)
"Richard Shockey" <richard@shockey.us> Mon, 29 May 2006 22:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkqDf-0008By-3X; Mon, 29 May 2006 18:28:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkqDd-0008Bl-Fy for speermint@ietf.org; Mon, 29 May 2006 18:28:13 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkprq-0006u9-34 for speermint@ietf.org; Mon, 29 May 2006 18:05:42 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fkpgt-0003mk-Rd for speermint@ietf.org; Mon, 29 May 2006 17:54:26 -0400
Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4TLsgwr004480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 May 2006 14:54:44 -0700
From: Richard Shockey <richard@shockey.us>
To: "'Khan, Sohel Q [CTO]'" <Sohel.Q.Khan@sprint.com>, 'Stastny Richard' <Richard.Stastny@oefeg.at>
Subject: RE: [Speermint] Defining Location Function (RE: Updated Draft:SPEERMINT Peering Architecture)
Date: Mon, 29 May 2006 17:54:10 -0400
Message-ID: <00f401c6836a$6c27fd90$24f0a544@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <978886E57CC1D64EAFAC157B98E36F9E091599CE@PLSWB08C.ad.sprint.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Thread-index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YAAA2P8gAAgEsSAABqXeoA==
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: -2.6 (--)
X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org
NO .. that was called TRIP ( go do a RFC search) and no one in their right mind wants to put a BGB like layer on VoIP routing. > -----Original Message----- > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > Sent: Monday, May 29, 2006 2:56 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: [Speermint] Defining Location Function (RE: Updated > Draft:SPEERMINT Peering Architecture) > > > Is it possible to take lessons from hierarchical eBGP routing? > We can consider each provider as the Autonomous System (say Level 0), a > federation is a hierarchical Autonomous system (say Level 1) that > contains a group of Autonomous-system (level 0). Hierarchical > Autonomous system's (Level 1) SIP route-database (as opposed to the BGP > routing table) is the Location Function (LF). SIP call routing feature > will be destination-based, path-vector based, and policy based similar > to BGP features. > I am trying to initiate a discussion in a different angle. > > Thanks, > > Sohel Khan, Ph.D. > Technology Strategist > Sprint-Nextel > 913-794-1470 (office) > 913-486-3145 (cell) > > > > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Monday, May 29, 2006 10:06 AM > To: Khan, Sohel Q [CTO] > Cc: speermint@ietf.org > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > Sohel, > > I posted this already on Friday, but I think everybody (including me) > lost track already;-) > > So here once again: > > "May I try my summary: the Location function is a process containing > eventually more then one step: > > "If you start with the CRD (e.g a SIP AoR entered by the User or derived > from ENUM)" > > Remark: Whith this I ment that the E.164 to SIP URI mapping is already > done, because this is out-of-scope of SPEERMINT. > In addition, SPEERMINT MUST be able to work in the same way if the user > has entered a SIP URI direct. This is why I prefer that the result of an > ENUM query is an AoR and not directly the ingress element to the > destination network. > > > "1. The AoR gives you the destination network > > 2. You need to locate the peering club (= federation) for exchanging SIP > messages (L5 )with the destination network > > 3. so you need to locate the policy you want to use and make a decision > on the federation > (note: a destination network may belong to more then one federations)" > (Remark: both origination network and destination network may be members > of more then one federation. They may need to locate a common one. If > more then one federation is in common, it is the choice of the > origination network to select one - So the Policy Function is embedded > in the LF) > > 4. "having chosen a federation, you need to locate the ingress > proxy(ies) the destination network is using within this federation. > > 5. If you are using a separate peering for exchanging media, you now may > locate these" > > Additional remark: In step 4. and 5. some geographic location magic > could come into play as requested by some on this list. > > Regards > Richard > > > -----Original Message----- > > From: Khan, Sohel Q [CTO] [mailto:Sohel.Q.Khan@sprint.com] > > Sent: Monday, May 29, 2006 4:30 PM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > Richard, > > > > Would you please describe what LF should perform (in your opinion)? > > > > > > Thanks, > > > > Sohel > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Sunday, May 28, 2006 3:07 AM > > To: Khan, Sohel Q [CTO] > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > 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:Sohel.Q.Khan@sprint.com] > > Gesendet: So 28.05.2006 06:48 > > An: Stastny Richard; Reinaldo Penno > > Cc: speermint@ietf.org > > 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" <Richard.Stastny@oefeg.at> > > To: "Reinaldo Penno" <rpenno@juniper.net> > > Cc: "speermint@ietf.org" <speermint@ietf.org> > > Sent: 5/27/06 4:52 PM > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture > > > > What question? > > Richard > > > > ________________________________ > > > > Von: Reinaldo Penno [mailto:rpenno@juniper.net] > > Gesendet: Sa 27.05.2006 23:46 > > An: Stastny Richard > > Cc: speermint@ietf.org > > 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:Richard.Stastny@oefeg.at] > > > Sent: Saturday, May 27, 2006 2:38 PM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org > > > 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:rpenno@juniper.net] > > > Gesendet: Sa 27.05.2006 21:30 > > > An: Stastny Richard; Otmar Lendl > > > Cc: speermint@ietf.org > > > 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:Richard.Stastny@oefeg.at] > > > > Sent: Saturday, May 27, 2006 4:26 AM > > > > To: Reinaldo Penno; Otmar Lendl > > > > Cc: speermint@ietf.org > > > > 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:rpenno@juniper.net] > > > > Gesendet: Sa 27.05.2006 11:04 > > > > An: Otmar Lendl; Patrick Melampy > > > > Cc: Khan, Sohel Q [CTO]; speermint@ietf.org > > > > 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:lendl@nic.at] > > > > > Sent: Saturday, May 27, 2006 1:29 AM > > > > > To: Patrick Melampy > > > > > Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering > > > Architecture > > > > > > > > > > On 2006/05/26 18:05, Patrick Melampy <PMelampy@acmepacket.com> > > > 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 (lendl@nic.at) | nic.at Systems Engineer > > > > > > > > > > > _______________________________________________ > > > > > Speermint mailing list > > > > > Speermint@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > > > > > > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
- [Speermint] Defining Location Function (RE: Updat… Khan, Sohel Q [CTO]
- RE: [Speermint] Defining Location Function (RE: U… Richard Shockey
- RE: [Speermint] Defining Location Function (RE: U… Reinaldo Penno