Re: [Speermint] Questions for Clarification
Michael Haberler <mah@inode.at> Thu, 23 March 2006 10:34 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMN8l-0008Mj-Cz; Thu, 23 Mar 2006 05:34:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMN6h-0006A2-P1 for speermint@ietf.org; Thu, 23 Mar 2006 05:31:55 -0500
Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMN3a-0003Du-5T for speermint@ietf.org; Thu, 23 Mar 2006 05:28:43 -0500
Received: from mah9.inode.at ([204.96.112.194]) by server (8.12.8/8.12.8) with SMTP id k2N91R2x010215; Thu, 23 Mar 2006 04:01:38 -0500
Message-Id: <7.0.1.0.2.20060323103555.038b9bb8@inode.at>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Thu, 23 Mar 2006 11:28:29 +0100
To: Stastny Richard <Richard.Stastny@oefeg.at>, speermint@ietf.org
From: Michael Haberler <mah@inode.at>
Subject: Re: [Speermint] Questions for Clarification
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4904@oefeg-s04.oefeg.loc >
References: <32755D354E6B65498C3BD9FD496C7D462C4904@oefeg-s04.oefeg.loc>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"; x-avg-checked="avg-ok-73693FDA"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc:
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
At 21:18 21.03.2006, Stastny Richard wrote: >I am also confused about the statement from Rohan that nobody will >use this because no >provider will make public to which federation he belongs to. I'd be very interested what people believe to be a viable alternative to runtime policy discovery - in particular visavis the fact that the draft-lendl-domain-policy-ddds-00 proposes to pubish a unique ID for a policy to enable runtime matching, but NOT requiring to publish what that policy ID actually stands for. In BGP speak this amounts to: "Here is my AS number. You might find that AS number tacked to other domains if you scan a lot of them, but no, we are not publishing our peering and transit relations in an RIR database". As for the BT example, saying that the sip.bt.com ingress point supports the BT IP interconnect policy, which is likely to be found on a BT website as their Reference Interconnect Offer in the first place. So much for the danger of "private parts exposure". I have a hard time believing we are back to static local configuration as the "preferred" solution, be that bilateral setup or "everything goes to my peering shop". Here's a paper exercise for you to tinker with alternatives: With SIP capabilites as they stand today, please emulate the GSM association - that's 600+ operators with some 23.000 interconnect agreements. In the first attempt, try to avoid the "big SIP hub" scenario for extra intellectual challenge. After done with defining pathetic access lists and local routing tables, I assume you're motivated to think about alternatives. Then again, if one has gobs of staff managing interconnect relations, that staff could well eventually be retrained to edit access control lists and tables. From a commercial point of view, there likely is a business case for the SIP hubs/peering providers. I think they have real value as SIP/RTP cleansing shops. I'm not sure that approach should be the IETF entropy solution to fabric discovery. And, while lashing out at the unsuitability of draft-lendl-domain-policy-ddds-00 for current service provider mindsets, keep in mind it does not limit itself to "carriers" - it does address groups of users, and in fact the user-service provider interface policy discovery problems just as well. Bonus value: it also includes "go to my peering shop" - besides keeping the end-to-end option open. -Michael _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
- [Speermint] Questions for Clarification Stastny Richard
- Re: [Speermint] Questions for Clarification Michael Haberler
- RE: [Speermint] Questions for Clarification Livingood, Jason