RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
"Khan, Sohel Q [CTO]" <Sohel.Q.Khan@sprint.com> Mon, 29 May 2006 14:31 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkimC-0001iS-St; Mon, 29 May 2006 10:31:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkimB-0001iN-QA for speermint@ietf.org; Mon, 29 May 2006 10:31:23 -0400
Received: from outbound-red.frontbridge.com ([216.148.222.49] helo=outbound1-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkimA-0003HM-Uy for speermint@ietf.org; Mon, 29 May 2006 10:31:23 -0400
Received: from outbound1-red.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-red-R.bigfish.com (Postfix) with ESMTP id 7AE54A131AF; Mon, 29 May 2006 14:31:22 +0000 (UTC)
Received: from mail95-red-R.bigfish.com (unknown [172.18.12.1]) by outbound1-red.bigfish.com (Postfix) with ESMTP id 6FFB3A131A6; Mon, 29 May 2006 14:31:22 +0000 (UTC)
Received: from mail95-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail95-red-R.bigfish.com (Postfix) with ESMTP id 620744F9375; Mon, 29 May 2006 14:31:22 +0000 (UTC)
X-BigFish: V
Received: by mail95-red (MessageSwitch) id 1148913082315994_4381; Mon, 29 May 2006 14:31:22 +0000 (UCT)
Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail95-red.bigfish.com (Postfix) with ESMTP id 271264F9426; Mon, 29 May 2006 14:31:22 +0000 (UTC)
Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k4TEV9Ag018345; Mon, 29 May 2006 09:31:13 -0500 (CDT)
Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k4TEUsI11070; Mon, 29 May 2006 09:31:09 -0500 (CDT)
Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 09:30:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
Date: Mon, 29 May 2006 09:30:06 -0500
Message-ID: <978886E57CC1D64EAFAC157B98E36F9E09159924@PLSWB08C.ad.sprint.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture
Thread-Index: AcaBZ8NpYEK5WaQeTtyFtyIYfY9SVQAAtO2wAAVy4pIAEEYoMAAEs7nCAACcsIAAAF4UfQAOV3R4AAcK35gAP5z0YA==
From: "Khan, Sohel Q [CTO]" <Sohel.Q.Khan@sprint.com>
To: Stastny Richard <Richard.Stastny@oefeg.at>
X-OriginalArrivalTime: 29 May 2006 14:30:10.0519 (UTC) FILETIME=[63F13670:01C6832C]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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
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] Updated Draft: SPEERMINT Peering Arch… Khan, Sohel Q [CTO]
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Khan, Sohel Q [CTO]
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Khan, Sohel Q [CTO]
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Henry Sinnreich
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Patrick Melampy
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Livingood, Jason
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- Re: [Speermint] Updated Draft: SPEERMINT Peering … David Meyer
- Re: [Speermint] Updated Draft: SPEERMINT Peering … David Meyer
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … James McEachern
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Patrick Melampy
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Nieminen Klaus
- Re: [Speermint] Updated Draft: SPEERMINT Peering … David Meyer
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Khan, Sohel Q [CTO]
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- VS: [Speermint] Updated Draft: SPEERMINT Peering … Nieminen Klaus
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Francois D. Menard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Khan, Sohel Q [CTO]
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Henry Sinnreich
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Livingood, Jason
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Livingood, Jason
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Livingood, Jason
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Malas, Daryl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Reinaldo Penno
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Pfautz, Penn L, GBLAM
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Malas, Daryl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Malas, Daryl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Malas, Daryl
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Patrick Melampy
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Brian Rosen
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Lee, Yiu
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Khan, Sohel Q [CTO]
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Duane
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Richard Shockey
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Uzelac, Adam
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Stastny Richard
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Uzelac, Adam
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Patrick Melampy
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Michael Hammer (mhammer)
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Otmar Lendl
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Uzelac, Adam
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Andrew Newton
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Livingood, Jason
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Livingood, Jason
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Paul Kyzivat
- RE: [Speermint] Updated Draft: SPEERMINT Peering … Patrick Melampy
- Re: [Speermint] Updated Draft: SPEERMINT Peering … Paul Kyzivat