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