From speermint-bounces@ietf.org Mon Oct 02 05:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKE7-0002xo-4U; Mon, 02 Oct 2006 05:36:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKE5-0002pS-Tz for speermint@ietf.org; Mon, 02 Oct 2006 05:36:41 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKE5-0002Dn-2o for speermint@ietf.org; Mon, 02 Oct 2006 05:36:41 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id E8F70210026; Mon, 2 Oct 2006 11:36:25 +0200 (CEST) Message-ID: <4520DDA0.4060906@pernau.at> Date: Mon, 02 Oct 2006 11:36:32 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: David Meyer Subject: Re: [Speermint] comments on draft-ietf-speermint-terminology-06.txt References: <451D25EB.70801@pernau.at> <20060929150107.GA2408@1-4-5.net> In-Reply-To: <20060929150107.GA2408@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi David! one more: > 4.2. Layer 5 Peering > > Layer 5 (Session) peering refers to interconnection of > two service providers for the purposes of ... ^ | voice regards Klaus David Meyer wrote: > Thanks Klaus. I'm working on an update (major rewrite, > really, it seems), and I'll incorporate your comments. > > Thanks, > > --dmm > > On Fri, Sep 29, 2006 at 03:55:55PM +0200, Klaus Darilion wrote: >> Hi David! >> >> Some comments to the terminology draft: >> >>> 2. SPEERMINT Context >>> >>> Figure 1 depicts the general session interconnect context. Note that >>> vertical axis in this figure describes the layering of identifiers, >>> while the horizontal lines indicate working group scope. While the >>> SPEERMINT working group is not limited (or coupled in any way) to the >>> use of E.164 numbers, in the case shown here an E.164 number >>> [ITU.E164.2005] is used as a key in an E.164 to Uniform Resource >>> Identifier (URI) mapping (ENUM [RFC3761]). That URI is in turn used >>> to retrieve a NAPTR record [RFC3404], which is in turn resolved into >> I think here something got mixed up: The URI can't be used to retrieve a >> NAPTR, as the URI is the result of the ENUM lookup. Maybe you ment "The >> ENUM domain is used to retrieve a NAPTR record ..." ? >> >> Further wouldn't be RFC3403 a better reference? >> >>> E.164 number <--- Peer Discovery >>> | >>> | <--- ENUM lookup of NAPTR in DNS >>> | >>> | >>> | ENUM Working Group Scope >>> =====+==================================================== >>> | SPEERMINT Working Group Scope >>> | >>> SIP URI <--- Call Addressing Data (CAD) >>> | >>> | >>> | <--- Federation Detection, Policy >>> | Lookup, and Service Location >>> | >> This is somehow in conflict with section 3.3 which defines that resource >> parameters and security parameters are part of CAD. As these parameters >> are usually obtained in the step "Federation Detection, Policy Lookup, >> and Service Location", it should be one layer below, e.g.: >> >> >> =====+==================================================== >> | SPEERMINT Working Group Scope >> | >> SIP URI >> | >> | >> | <--- Federation Detection, Policy >> | Lookup, and Service Location >> | >> CAD <--- Call Addressing Data (SIP URI, >> | security parameters, ...) >> | >> Hostname <--- Addressing and session establishment >> | >> | SPEERMINT Working Group Scope >> =====+==================================================== >> >>> | >>> Hostname <--- Addressing and session establishment >>> | >>> | SPEERMINT Working Group Scope >>> =====+==================================================== >>> | Out of scope for the SPEERMINT Working Group >>> | >>> | <--- Lookup of A and AAAA in DNS >> Where is the NAPTR/SRV lookup? In scope of speermint or out of scope. >> Although there is draft-creighton-khandpur-speermint-srv-naptr-use which >> looks like it is in scope, it is also defined in RFC3263 which would IMO >> be out of scope. >> >> Nevertheless, NAPTR and SRV should be mentioned in the figure as A/AAAA >> is mentioned too. Maybee it would also help to clarify the meaning of >> "hostname". Is this the domain in the SIP URI or is it a hostname >> resolved from NAPTR+SRV lookups? >> >> >>> 3.1. Signaling Path Border Element >>> >>> A signaling path border element (SBE) provides signaling functions >>> such as protocol inter-working (for example, H.323 to SIP), identity >>> and topology hiding, and Call Admission Control (CAC) for a domain. >> As it is called Border Element I would rather define it based on it's >> location, not on its possible function. E.g. like (of course with a >> better wording :-)) >> >> SIP messages entering a domain will first be process by the domain's >> SBE. For SIP messages leaving a domain, the domain's SBE will be the >> last signaling node of the domain. >> >> SBEs often provide functions >> such as protocol inter-working (for example, H.323 to SIP), identity >> and topology hiding, and Call Admission Control (CAC) for a domain. >> >> > Such an SBE is frequently (but need not be) deployed on a domain's >> > border. >> ^^^^^^^^ >> Maybe domain in this context should be defined as well. >> >> >>> 3.5. PSTN >>> >>> The term "PSTN" refers to the Public Switched Telephone Network. In >>> particular, the PSTN refers to the collection of interconnected >>> circuit-switched voice-oriented public telephone networks, both >> ^^^^^^^ this would exclude an IMSr5 (if they ever will come) >> based mobile network >> PS: I'm fine with this definition :-) >> >> >> >>> 3.7. Peer Network >>> >>> This document defines a peer network as the set of SIP UASs and SIP >>> UACs (customers) that are controlled by a single administrative >>> domain and can be reached via some IP path. Note that such a peer >>> network may also contain end-users who are located on the PSTN (and >>> hence may also be interconnected with the PSTN), as long as they are >>> also reachable via some IP path. >> So this network is a "L5 network" including all the SIP nodes, SIP >> clients, gateways ..., but not the L3 access network - right? Then it >> should be mentioned. >> >> >>> 3.8. Service Provider >>> >>> A Service Provider (or SP) is defined to be an entity that provides >>> layer 3 (IP) transport of SIP signaling and media packets. >> Thus this would be every ISP which do not block SIP traffic? >> >>> 3.9. Voice Service Provider >>> >>> A Voice Service Provider (or VSP) is an entity that provides >>> transport of SIP signaling to its customers. In the event that the >> ^^^^^^^^^^ >> Does a Voice server Provider needs transport? Thus every ISP which >> do not block SIP would be a voice service provider? I think this is >> not the intended definition. What about: >> >> A Voice Service Provider (or VSP) is an entity that provides >> SIP signaling to its customers. >> >>> VSP is also an SP, it may also provide media streams to its >>> customers. Such a service provider may additionally be >>> interconnected with other service providers; that is, it may "peer" >>> with other service providers. A VSP may also interconnect with the >>> PSTN. >> What do you mean with "peering" here. L3 oder L5? >> >> >>> 4.2. Layer 5 Peering >>> >>> Layer 5 (Session) peering refers to interconnection of two service >>> providers for the purposes of routing real-time (or quasi-real time) >>> secure call signaling between their respective customers using SIP >> ^^^^^^ >> Is "secure" a requirement? >> >> What does secure mean - does it mean encryption? >> >>> 4.2.2. Indirect Peering >>> >>> Indirect, or transit, peering refers to the establishment of a secure >> ^^^^ >> Again - is secure a requirement? >> >>> signaling path via one (or more) referral or transit network(s). In >>> this case it is generally required that a trust relationship is >>> established between the originating service provider and the transit >>> network on one side, and the transit network and the termination >>> network on the other side. >> Maybe a figure would be helpful: >> >> A: VSP A >> B: VSP B >> T: Transit VSP >> >> A <---direct peering ---> T <--- direct peering ---> B >> >> ^ ^ >> | | >> \--------- indirect peering between A and B ---------/ >> >>> 4.2.3. Assisted Peering >>> >>> In this case, some entity (usually a federation, see Section 5) >>> employs a central SIP proxy (which is not itself a VSP) to bridge >>> calls between participating networks. >> ^^^^^ >> IMO "participating peering networks" would add clarity. >> >>> 5. Federations >>> >> ... >>> Finally, note that a SP can be a member of >>> >>> * No federation (e.g., the SP has only bilateral peering >>> agreements) >>> >>> * A single federation >>> >>> * Multiple federations >>> >>> and an SP can have any combination of bi-lateral and multi-lateral >>> (i.e., federated) interconnections. >> SP should be replaced with VSP (3 times) >> >> regards >> Klaus >> >> -- >> Klaus Darilion >> nic.at >> >> _______________________________________________ >> 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 From speermint-bounces@ietf.org Mon Oct 02 10:35:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOsV-00022z-L2; Mon, 02 Oct 2006 10:34:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOsU-00022p-7u for speermint@ietf.org; Mon, 02 Oct 2006 10:34:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOsR-0001dI-Jr for speermint@ietf.org; Mon, 02 Oct 2006 10:34:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 07:34:29 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44495732:sNHT65570986" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EYORq024796; Mon, 2 Oct 2006 10:34:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92EYOdM022684; Mon, 2 Oct 2006 10:34:24 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:34:20 -0400 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] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 Date: Mon, 2 Oct 2006 10:34:14 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301FEF577@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 Thread-Index: AcbjsdRwZ1hfJW9yQIO10GcPeMR6BwCfdw8w From: "Michael Hammer \(mhammer\)" To: "Klaus Darilion" , X-OriginalArrivalTime: 02 Oct 2006 14:34:20.0273 (UTC) FILETIME=[D8DB2610:01C6E62F] DKIM-Signature: a=rsa-sha1; q=dns; l=7809; t=1159799665; x=1160663665; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20comments=20on=20draftdraft-creighton-khandpur-spee rmint-srv-naptr-use-01 |To:=22Klaus=20Darilion=22=20, =20; X=v=3Dcisco.com=3B=20h=3DeEcvKFrE3CjUJFS/TxoWN20Cnbo=3D; b=ANyDzNxB3SSxsHNBXZ5djP+BlJ1VhmDpZzDNLYtlhrmrFRXGaWx6nEH/MfbjGRf09A9gVeBz PndpU9FolTl1PO4PCUVDqKjr21H/vcs96Rbc+N8kspeyYUWrGG76oc4g; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I did not understand your RFC3261 comment. It says you should try an alternate server and not retry the server sending the 503 until after the retry time. Mike =20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Friday, September 29, 2006 6:24 AM > To: speermint@ietf.org > Subject: [Speermint] comments on=20 > draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 >=20 > Hi Tom, Gaurav! >=20 > Following some comments. >=20 >=20 > > 3. Session Peering Setup > > =20 > > SIP systems are represented by user agents (UA). In the diagram=20 > > below, a user agent (UA1), hosted by a service provider SP1,=20 > > initiates a call to a User Agent (UA2), hosted by=20 > service provider=20 > > SP2. The egress SIP server of SP1 is a SIP stateful Session=20 > > Peering >=20 > ^^^^^^^^^=20 > IMO we should not require the PeeringProxy to be stateful (btw:=20 > transaction stateful or dialog stateful). >=20 >=20 > > The figure below shows a high level SIP call flow=20 > setting up a SIP=20 > > peering session between SP1 and SP2. All SIP signaling MUST go=20 > > through the SPP1 and SPP2 as these are the ingress and=20 > egress points=20 > > in SP1 and SP2 network.=20 > > =20 > > UA 1 SPP 1 DNS 1 DNS 2 SPP 2 UA 2=20 > > | | | | | |=20 > > |INVITE| | | | |=20 > > |----->| | | | |=20 > > | NAPTR Query | | |=20 > > | |----->| | | |=20 > > | NAPTR Response | | |=20 > > | |<-----| | | |=20 > > | SRV Query | | |=20 > > | |----->| | | |=20 > > | SRV+A Response | | |=20 > > | |<-----| | | |=20 >=20 > I wonder why you combine SRV+A in one response. This depends=20 > on the DNS server. If you have a "simple" resolver, you have=20 > to ask for each record separate. If you have an "intelligent"=20 > resolver, you will get=20 > NAPTR+SRV+A in the same response (if SRV+A are cached or responded by > the authoritative server). >=20 > Further it depends if SPP1 does cache DNS too. The SIP proxies I know=20 > will do 3 lookups (regardless if the additional section=20 > contains SRV and=20 > A or not) as they do not have a DNS cache. >=20 > Thus, I suggest to either draw 3 lookups in the figure 1.=20 > NAPTR, 2. SRV,=20 > 3. A/AAAA or to draw only one lookup. >=20 >=20 > > 3.1 TARGET Determination=20 > > =20 > > The target resource is identified with a SIP or SIPS=20 > URI. This is=20 > > the URI in the Route header, if present, or the URI from=20 > the request=20 > > URI of the SIP INVITE received by SPP1. =20 >=20 > I would write "topmost Route header" just for clarification. >=20 > > 3.2 NAPTR Lookup=20 >=20 > I would add somewhere that NAPTR/SRV/A lookups must be=20 > skipped according=20 > to RFC 3263 [3] if transport/port/IP are already specified in=20 > the target=20 > URI. >=20 > > DNS MUST return at least three records - one with "SIP+D2T", one=20 > > with "SIP+D2U" and one with "SIPS+D2T" service type for=20 > the case of=20 > > direct peering (section 4.3 in [6]). "SIPS+D2T" is not a=20 > MUST for=20 > > indirect (transit) peering (section 4.4 in [6]) since=20 > domain validation=20 > > as specified in section 26.3.2.2 of [1] for TLS at layer=20 > 5 will not work=20 > > for indirect peering. >=20 > This sounds like TLS can't be used in transit peering. I=20 > would like to=20 > use TLS also in transit scenarios. IMO it would be better to remove=20 > layer 5 certificate validation (section 26.3.2.2 of [1] )=20 > than removing=20 > TLS completely. >=20 > > 3.3 SRV Lookup=20 > > =20 > ... > > Alternatively, if no NAPTR records are found, then SPP1 uses the=20 > > preferred transport protocol and issues an SRV query for that=20 > > specific transport using sips for SIPS URI and SIP URI=20 > with TLS and=20 > > sip for SIP URI.=20 >=20 > IMO this sentence is not clear. What do you mean with "preferred=20 > protocol"? Is the preferred protocol somewhere defined or is it the=20 > preference of SP1? >=20 > Further I would write "_sips" instead of "sips" and "_sip" instead of=20 > "sip" to make it clear that you mean the domain prefix for=20 > the SRV lookup. >=20 > > 3.4 Using SRV Results=20 > > =20 > > RFC 2782 describes the procedures on how to use and=20 > interpret the=20 > > results obtained from the SRV query. The target entry=20 > of the SRV RRs=20 > > is looked up by querying the DNS for address records.=20 > The SRV response=20 > > from DNS MAY also include A records with it which will=20 > cut down on round >=20 > Again - also the NAPTR lookup may already return the SRV and=20 > A record.=20 > Having a additional section in the DNS response is not limited to the=20 > SRV lookup. >=20 >=20 > > 4.1 SPP1 Fails to Reach SPP2=20 > > =20 > > A 503 error response is reported by the transaction=20 > layer, or failure=20 > > can occur at the transport layer due to TCP disconnect=20 > in connection,=20 > > ICMP error in UDP or time out at transport layer or SIP=20 > layer timeout=20 > > when its not receiving any SIP response. In such=20 > situations, SPP1=20 > > tries a new SIP request transaction to the next available server=20 > > instance of SPP2 as determined by SRV RRs entry. =20 >=20 >=20 > This is against RFC 3261 which says in case of 503 it should=20 > not send to=20 > an alternate server: >=20 > 21.5.4 503 Service Unavailable > ... > A client (proxy or UAC) receiving a 503 (Service=20 > Unavailable) SHOULD > attempt to forward the request to an alternate server. =20 > It SHOULD NOT > forward any other requests to that server for the=20 > duration specified > in the Retry-After header field, if present. >=20 >=20 > I further wonder about best practise for failover to another ingress=20 > point of SP2. UDP timeout can take up to 32 seconds. TCP=20 > timeout depends=20 > on the OS. IMO this is quite long time for failover. >=20 > 1. Should this be described in this draft or maybe in the=20 > callfows draft? >=20 > 2. What would be a good value until trying the next server?=20 > 32 seconds=20 > is too long. RFC 3261 allows redefinition of Timer T1. The=20 > default value=20 > is 500ms and should reflect the RTT to the next hop. Thus, if it is=20 > knows that the RTT to the ingress point is 100ms, setting T1 to 100ms=20 > allows faster failover (of course the Peering Proxy needs to support=20 > setting of T1) >=20 >=20 > > 5. Caching/TTL=20 > > =20 > > SRV RRs have a TTL value based on which the SPP1 caches=20 > the entry for=20 > > that duration and any further requests to the same=20 > TARGET domain are=20 > > delivered to the cached server instance. The TTL=20 > recommended for SRV=20 >=20 > This sounds like the SPP1 must cache DNS results. Usually=20 > applications=20 > does not caches DNS as the caching is done by SP1's resolving name=20 > server. IMO caching in the resolver must be fine too. >=20 > regards > Klaus >=20 > --=20 > Klaus Darilion > nic.at >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 02 10:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOxn-0000WZ-F6; Mon, 02 Oct 2006 10:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOxm-0000Vs-7t for speermint@ietf.org; Mon, 02 Oct 2006 10:40:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOxk-000248-Uc for speermint@ietf.org; Mon, 02 Oct 2006 10:40:10 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 07:40:09 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44496714:sNHT53414180" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92Ee8e6025329; Mon, 2 Oct 2006 10:40:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92Ee7dM025179; Mon, 2 Oct 2006 10:40:08 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:40:07 -0400 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] comments on draft-ietf-speermint-terminology-06.txt Date: Mon, 2 Oct 2006 10:40:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301FEF582@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Thread-Index: Acbj1LIrfpQFjDo/RiqYZUpHgDeu7wCW5yCA From: "Michael Hammer \(mhammer\)" To: "Klaus Darilion" , "Stastny Richard" X-OriginalArrivalTime: 02 Oct 2006 14:40:07.0657 (UTC) FILETIME=[A7E9BD90:01C6E630] DKIM-Signature: a=rsa-sha1; q=dns; l=1621; t=1159800008; x=1160664008; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20comments=20on=20draft-ietf-speermint-terminology-0 6.txt |To:=22Klaus=20Darilion=22=20, =0A=20=20=20=20= 20=20=20=20=22Stastny=20Richard=22=20; X=v=3Dcisco.com=3B=20h=3DQnZxRHjtS010wLetGkHwl2DYmyw=3D; b=OvBk68OcKQGAN6a+4G1i48/nLLxOGQobm/oy0++tm56AV8bclF8qUptKzjz9EshQ2CLjyDmv xnMP2WLMGcF0spnC600jG4KrQFgGn8XZ88MOFVFd1PZb3sHqyzv7kiWj; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Be careful here. Secure could mean two things: Integrity protected !=3D encrypted Confidentiality protected =3D encrypted Do we really mean the latter? I would say yes, possibly because media encryption keys are carried, but that may not always be the case. How strong do we want to make this? Mike > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Friday, September 29, 2006 10:36 AM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Re: [Speermint] comments on=20 > draft-ietf-speermint-terminology-06.txt >=20 > Stastny Richard wrote: > >> > 4.2. Layer 5 Peering > >> > > >> > Layer 5 (Session) peering refers to interconnection of=20 > two service =20 > >> > providers for the purposes of routing real-time (or quasi-real > > time) > >> > secure call signaling between their respective=20 > customers using SIP > >> ^^^^^^ > >> Is "secure" a requirement? > >> > >> What does secure mean - does it mean encryption? > >=20 > > TLS or IPsec >=20 > Then I would say encryption instead of secure. >=20 > regards > klaus >=20 > >=20 > >> > 4.2.2. Indirect Peering > >> > > >> > Indirect, or transit, peering refers to the establishment of a > > secure > >> =20 > >> ^^^^ Again - is secure a requirement? > >> > >=20 > > IMHO yes > >=20 > > Richard >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 02 10:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP6E-00017k-MD; Mon, 02 Oct 2006 10:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP6D-00015F-M3 for speermint@ietf.org; Mon, 02 Oct 2006 10:48:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP6C-0002oN-BJ for speermint@ietf.org; Mon, 02 Oct 2006 10:48:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 07:48:52 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="44498173:sNHT56763820" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92Emphf031293; Mon, 2 Oct 2006 10:48:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k92EmpuK007635; Mon, 2 Oct 2006 10:48:51 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:48:51 -0400 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] comments on draft-ietf-speermint-terminology-06.txt Date: Mon, 2 Oct 2006 10:48:47 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301FEF592@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Thread-Index: AcbjzytNP0g2dAQDQWSMo5+LVlTkkACYbbrA From: "Michael Hammer \(mhammer\)" To: "Klaus Darilion" , X-OriginalArrivalTime: 02 Oct 2006 14:48:51.0686 (UTC) FILETIME=[E0423860:01C6E631] DKIM-Signature: a=rsa-sha1; q=dns; l=3334; t=1159800532; x=1160664532; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20comments=20on=20draft-ietf-speermint-terminology-0 6.txt |To:=22Klaus=20Darilion=22=20, =20; X=v=3Dcisco.com=3B=20h=3DQnZxRHjtS010wLetGkHwl2DYmyw=3D; b=rWsB5cEXQ3YJdXW4T7tAgKbDfwD9ljRM3rWhFwDeA4eCkWjtegDDvdj8BTYnaK4Ma/AbBHg5 TUT7UwFtMd01m2IRk/S27eXVY9WEKuz+H3afU8TYoWSWqrPC0AO3gF8H; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Inline.=20 > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 > Sent: Friday, September 29, 2006 9:56 AM > To: speermint@ietf.org > Subject: [Speermint] comments on=20 > draft-ietf-speermint-terminology-06.txt >=20 > Hi David! >=20 > Some comments to the terminology draft: [snip] > > 3.8. Service Provider > > > > A Service Provider (or SP) is defined to be an entity that=20 > provides > layer 3 (IP) transport of SIP signaling and media packets. >=20 > Thus this would be every ISP which do not block SIP traffic? I thought SP included both ISP and VSP. > > 3.9. Voice Service Provider > > > > A Voice Service Provider (or VSP) is an entity that=20 > provides > transport of SIP signaling to its customers. In=20 > the event that the > ^^^^^^^^^^ > Does a Voice server Provider needs transport? Thus every ISP=20 > which do not block SIP would be a voice service provider? I=20 > think this is not the intended definition. What about: >=20 > A Voice Service Provider (or VSP) is an entity that provides > SIP signaling to its customers. Agree with the problem. It is not about transport, it is about processing L5 traffic. Provides is also vague. How about "processes SIP siganling for its customers." =20 > > VSP is also an SP, it may also provide media streams to=20 > its > customers. Such a service provider may additionally=20 > be > interconnected with other service providers; that is,=20 > it may "peer" > > with other service providers. A VSP may also interconnect=20 > with the > PSTN. >=20 > What do you mean with "peering" here. L3 oder L5? =20 [snip] =20 > Maybe a figure would be helpful: >=20 > A: VSP A > B: VSP B > T: Transit VSP >=20 > A <---direct peering ---> T <--- direct peering ---> B >=20 > ^ ^ > | | > \--------- indirect peering between A and B ---------/ This is backwards. =20 Direct peering is between A and B. Indirect peering is between A and B indirectly through T. =20 > > 4.2.3. Assisted Peering > > > > In this case, some entity (usually a federation, see=20 > Section 5) > employs a central SIP proxy (which is not=20 > itself a VSP) to bridge > calls between participating networks. >=20 > ^^^^^ > IMO "participating peering networks" would add clarity. >=20 > > 5. Federations > > > ... > > > > Finally, note that a SP can be a member of > > > * No federation (e.g., the SP has only bilateral peering > > agreements) > > > > * A single federation > > > > * Multiple federations > > > > and an SP can have any combination of bi-lateral and=20 > multi-lateral > (i.e., federated) interconnections. Another thought is to put for first option above: * Degenerate federation (2 members =3D bilateral peering) Mike >=20 > SP should be replaced with VSP (3 times) >=20 > regards > Klaus >=20 > -- > Klaus Darilion > nic.at >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 02 12:22:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQYU-00048s-QM; Mon, 02 Oct 2006 12:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQYT-00048e-DQ for speermint@ietf.org; Mon, 02 Oct 2006 12:22:09 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQYR-0007OV-Rs for speermint@ietf.org; Mon, 02 Oct 2006 12:22:09 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 60351210023; Mon, 2 Oct 2006 18:22:02 +0200 (CEST) Message-ID: <45213CB0.9050008@pernau.at> Date: Mon, 02 Oct 2006 18:22:08 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 References: <072C5B76F7CEAB488172C6F64B30B5E301FEF577@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301FEF577@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > I did not understand your RFC3261 comment. It says you should try an > alternate server and not retry the server sending the 503 until after > the retry time. Hi Mike! Of course you are right. Looks like I read the RFC section too fast. 503 is fine for causing failover. regards klaus >> -----Original Message----- >> From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] >> Sent: Friday, September 29, 2006 6:24 AM >> To: speermint@ietf.org >> Subject: [Speermint] comments on >> draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 >> >> Hi Tom, Gaurav! >> >> Following some comments. >> >> >>> 3. Session Peering Setup >>> >>> SIP systems are represented by user agents (UA). In the diagram >>> below, a user agent (UA1), hosted by a service provider SP1, >>> initiates a call to a User Agent (UA2), hosted by >> service provider >>> SP2. The egress SIP server of SP1 is a SIP stateful Session >>> Peering >> ^^^^^^^^^ >> IMO we should not require the PeeringProxy to be stateful (btw: >> transaction stateful or dialog stateful). >> >> >>> The figure below shows a high level SIP call flow >> setting up a SIP >>> peering session between SP1 and SP2. All SIP signaling MUST go >>> through the SPP1 and SPP2 as these are the ingress and >> egress points >>> in SP1 and SP2 network. >>> >>> UA 1 SPP 1 DNS 1 DNS 2 SPP 2 UA 2 >>> | | | | | | >>> |INVITE| | | | | >>> |----->| | | | | >>> | NAPTR Query | | | >>> | |----->| | | | >>> | NAPTR Response | | | >>> | |<-----| | | | >>> | SRV Query | | | >>> | |----->| | | | >>> | SRV+A Response | | | >>> | |<-----| | | | >> I wonder why you combine SRV+A in one response. This depends >> on the DNS server. If you have a "simple" resolver, you have >> to ask for each record separate. If you have an "intelligent" >> resolver, you will get >> NAPTR+SRV+A in the same response (if SRV+A are cached or responded by >> the authoritative server). >> >> Further it depends if SPP1 does cache DNS too. The SIP proxies I know >> will do 3 lookups (regardless if the additional section >> contains SRV and >> A or not) as they do not have a DNS cache. >> >> Thus, I suggest to either draw 3 lookups in the figure 1. >> NAPTR, 2. SRV, >> 3. A/AAAA or to draw only one lookup. >> >> >>> 3.1 TARGET Determination >>> >>> The target resource is identified with a SIP or SIPS >> URI. This is >>> the URI in the Route header, if present, or the URI from >> the request >>> URI of the SIP INVITE received by SPP1. >> I would write "topmost Route header" just for clarification. >> >>> 3.2 NAPTR Lookup >> I would add somewhere that NAPTR/SRV/A lookups must be >> skipped according >> to RFC 3263 [3] if transport/port/IP are already specified in >> the target >> URI. >> >>> DNS MUST return at least three records - one with "SIP+D2T", one >>> with "SIP+D2U" and one with "SIPS+D2T" service type for >> the case of >>> direct peering (section 4.3 in [6]). "SIPS+D2T" is not a >> MUST for >>> indirect (transit) peering (section 4.4 in [6]) since >> domain validation >>> as specified in section 26.3.2.2 of [1] for TLS at layer >> 5 will not work >>> for indirect peering. >> This sounds like TLS can't be used in transit peering. I >> would like to >> use TLS also in transit scenarios. IMO it would be better to remove >> layer 5 certificate validation (section 26.3.2.2 of [1] ) >> than removing >> TLS completely. >> >>> 3.3 SRV Lookup >>> >> ... >>> Alternatively, if no NAPTR records are found, then SPP1 uses the >>> preferred transport protocol and issues an SRV query for that >>> specific transport using sips for SIPS URI and SIP URI >> with TLS and >>> sip for SIP URI. >> IMO this sentence is not clear. What do you mean with "preferred >> protocol"? Is the preferred protocol somewhere defined or is it the >> preference of SP1? >> >> Further I would write "_sips" instead of "sips" and "_sip" instead of >> "sip" to make it clear that you mean the domain prefix for >> the SRV lookup. >> >>> 3.4 Using SRV Results >>> >>> RFC 2782 describes the procedures on how to use and >> interpret the >>> results obtained from the SRV query. The target entry >> of the SRV RRs >>> is looked up by querying the DNS for address records. >> The SRV response >>> from DNS MAY also include A records with it which will >> cut down on round >> >> Again - also the NAPTR lookup may already return the SRV and >> A record. >> Having a additional section in the DNS response is not limited to the >> SRV lookup. >> >> >>> 4.1 SPP1 Fails to Reach SPP2 >>> >>> A 503 error response is reported by the transaction >> layer, or failure >>> can occur at the transport layer due to TCP disconnect >> in connection, >>> ICMP error in UDP or time out at transport layer or SIP >> layer timeout >>> when its not receiving any SIP response. In such >> situations, SPP1 >>> tries a new SIP request transaction to the next available server >>> instance of SPP2 as determined by SRV RRs entry. >> >> This is against RFC 3261 which says in case of 503 it should >> not send to >> an alternate server: >> >> 21.5.4 503 Service Unavailable >> ... >> A client (proxy or UAC) receiving a 503 (Service >> Unavailable) SHOULD >> attempt to forward the request to an alternate server. >> It SHOULD NOT >> forward any other requests to that server for the >> duration specified >> in the Retry-After header field, if present. >> >> >> I further wonder about best practise for failover to another ingress >> point of SP2. UDP timeout can take up to 32 seconds. TCP >> timeout depends >> on the OS. IMO this is quite long time for failover. >> >> 1. Should this be described in this draft or maybe in the >> callfows draft? >> >> 2. What would be a good value until trying the next server? >> 32 seconds >> is too long. RFC 3261 allows redefinition of Timer T1. The >> default value >> is 500ms and should reflect the RTT to the next hop. Thus, if it is >> knows that the RTT to the ingress point is 100ms, setting T1 to 100ms >> allows faster failover (of course the Peering Proxy needs to support >> setting of T1) >> >> >>> 5. Caching/TTL >>> >>> SRV RRs have a TTL value based on which the SPP1 caches >> the entry for >>> that duration and any further requests to the same >> TARGET domain are >>> delivered to the cached server instance. The TTL >> recommended for SRV >> >> This sounds like the SPP1 must cache DNS results. Usually >> applications >> does not caches DNS as the caching is done by SP1's resolving name >> server. IMO caching in the resolver must be fine too. >> >> regards >> Klaus >> >> -- >> Klaus Darilion >> nic.at >> >> _______________________________________________ >> 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 From speermint-bounces@ietf.org Tue Oct 03 18:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsQ4-0002TK-Dx; Tue, 03 Oct 2006 18:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsQ3-0002Rd-6B for speermint@ietf.org; Tue, 03 Oct 2006 18:07:19 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUsQ2-0000oo-Gj for speermint@ietf.org; Tue, 03 Oct 2006 18:07:19 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id k93M7Hiu023094; Tue, 3 Oct 2006 15:07:17 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id k93M7Hku023093; Tue, 3 Oct 2006 15:07:17 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 3 Oct 2006 15:07:17 -0700 From: David Meyer To: Klaus Darilion Subject: Re: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Message-ID: <20061003220717.GA23080@1-4-5.net> References: <451D25EB.70801@pernau.at> <20060929150107.GA2408@1-4-5.net> <4520DDA0.4060906@pernau.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4520DDA0.4060906@pernau.at> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Mon, Oct 02, 2006 at 11:36:32AM +0200, Klaus Darilion wrote: > Hi David! Gotcha. Thnx, --dmm >=20 > one more: >=20 > >4.2. Layer 5 Peering > > > > Layer 5 (Session) peering refers to interconnection of=20 > > two service providers for the purposes of ... > ^ > | > voice >=20 >=20 > regards > Klaus >=20 >=20 > David Meyer wrote: > > Thanks Klaus. I'm working on an update (major rewrite, > > really, it seems), and I'll incorporate your comments. > > > > Thanks, > > > > --dmm > > > >On Fri, Sep 29, 2006 at 03:55:55PM +0200, Klaus Darilion wrote: > >>Hi David! > >> > >>Some comments to the terminology draft: > >> > >>>2. SPEERMINT Context > >>> > >>>Figure 1 depicts the general session interconnect context. Note that > >>>vertical axis in this figure describes the layering of identifiers, > >>>while the horizontal lines indicate working group scope. While the > >>>SPEERMINT working group is not limited (or coupled in any way) to the > >>>use of E.164 numbers, in the case shown here an E.164 number > >>>[ITU.E164.2005] is used as a key in an E.164 to Uniform Resource > >>>Identifier (URI) mapping (ENUM [RFC3761]). That URI is in turn used > >>>to retrieve a NAPTR record [RFC3404], which is in turn resolved into > >>I think here something got mixed up: The URI can't be used to retrieve a > >>NAPTR, as the URI is the result of the ENUM lookup. Maybe you ment "The > >>ENUM domain is used to retrieve a NAPTR record ..." ? > >> > >>Further wouldn't be RFC3403 a better reference? > >> > >>> E.164 number <--- Peer Discovery > >>> | > >>> | <--- ENUM lookup of NAPTR in DNS > >>> | > >>> | > >>> | ENUM Working Group Scope > >>> =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> | SPEERMINT Working Group Scope > >>> | > >>> SIP URI <--- Call Addressing Data (CAD) > >>> | > >>> | > >>> | <--- Federation Detection, Policy > >>> | Lookup, and Service Location > >>> | > >>This is somehow in conflict with section 3.3 which defines that resource > >>parameters and security parameters are part of CAD. As these parameters > >>are usually obtained in the step "Federation Detection, Policy Lookup, > >>and Service Location", it should be one layer below, e.g.: > >> > >> > >> =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> | SPEERMINT Working Group Scope > >> | > >> SIP URI > >> | > >> | > >> | <--- Federation Detection, Policy > >> | Lookup, and Service Location > >> | > >> CAD <--- Call Addressing Data (SIP URI, > >> | security parameters, ...) > >> | > >> Hostname <--- Addressing and session establishment > >> | > >> | SPEERMINT Working Group Scope > >> =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >>> | > >>> Hostname <--- Addressing and session establishment > >>> | > >>> | SPEERMINT Working Group Scope > >>> =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> | Out of scope for the SPEERMINT Working Group > >>> | > >>> | <--- Lookup of A and AAAA in DNS > >>Where is the NAPTR/SRV lookup? In scope of speermint or out of scope. > >>Although there is draft-creighton-khandpur-speermint-srv-naptr-use which > >>looks like it is in scope, it is also defined in RFC3263 which would IMO > >>be out of scope. > >> > >>Nevertheless, NAPTR and SRV should be mentioned in the figure as A/AAAA > >>is mentioned too. Maybee it would also help to clarify the meaning of > >>"hostname". Is this the domain in the SIP URI or is it a hostname > >>resolved from NAPTR+SRV lookups? > >> > >> > >>>3.1. Signaling Path Border Element > >>> > >>>A signaling path border element (SBE) provides signaling functions > >>>such as protocol inter-working (for example, H.323 to SIP), identity > >>>and topology hiding, and Call Admission Control (CAC) for a domain. > >>As it is called Border Element I would rather define it based on it's > >>location, not on its possible function. E.g. like (of course with a > >>better wording :-)) > >> > >> SIP messages entering a domain will first be process by the domain's > >> SBE. For SIP messages leaving a domain, the domain's SBE will be the > >> last signaling node of the domain. > >> > >> SBEs often provide functions > >> such as protocol inter-working (for example, H.323 to SIP), identity > >> and topology hiding, and Call Admission Control (CAC) for a domain. > >> > >> > Such an SBE is frequently (but need not be) deployed on a domain's > >> > border. > >> ^^^^^^^^ > >>Maybe domain in this context should be defined as well. > >> > >> > >>>3.5. PSTN > >>> > >>>The term "PSTN" refers to the Public Switched Telephone Network. In > >>>particular, the PSTN refers to the collection of interconnected > >>>circuit-switched voice-oriented public telephone networks, both > >> ^^^^^^^ this would exclude an IMSr5 (if they ever will come) > >> based mobile network > >> PS: I'm fine with this definition :-) > >> > >> > >> > >>>3.7. Peer Network > >>> > >>>This document defines a peer network as the set of SIP UASs and SIP > >>>UACs (customers) that are controlled by a single administrative > >>>domain and can be reached via some IP path. Note that such a peer > >>>network may also contain end-users who are located on the PSTN (and > >>>hence may also be interconnected with the PSTN), as long as they are > >>>also reachable via some IP path. > >>So this network is a "L5 network" including all the SIP nodes, SIP > >>clients, gateways ..., but not the L3 access network - right? Then it > >>should be mentioned. > >> > >> > >>>3.8. Service Provider > >>> > >>>A Service Provider (or SP) is defined to be an entity that provides > >>>layer 3 (IP) transport of SIP signaling and media packets. > >>Thus this would be every ISP which do not block SIP traffic? > >> > >>>3.9. Voice Service Provider > >>> > >>>A Voice Service Provider (or VSP) is an entity that provides > >>>transport of SIP signaling to its customers. In the event that the > >> ^^^^^^^^^^ > >>Does a Voice server Provider needs transport? Thus every ISP which > >>do not block SIP would be a voice service provider? I think this is > >>not the intended definition. What about: > >> > >> A Voice Service Provider (or VSP) is an entity that provides > >> SIP signaling to its customers. > >> > >>>VSP is also an SP, it may also provide media streams to its > >>>customers. Such a service provider may additionally be > >>>interconnected with other service providers; that is, it may "peer" > >>>with other service providers. A VSP may also interconnect with the > >>>PSTN. > >>What do you mean with "peering" here. L3 oder L5? > >> > >> > >>>4.2. Layer 5 Peering > >>> > >>>Layer 5 (Session) peering refers to interconnection of two service > >>>providers for the purposes of routing real-time (or quasi-real time) > >>>secure call signaling between their respective customers using SIP > >> ^^^^^^ > >> Is "secure" a requirement? > >> > >>What does secure mean - does it mean encryption? > >> > >>>4.2.2. Indirect Peering > >>> > >>>Indirect, or transit, peering refers to the establishment of a secure > >> ^^^^ > >>Again - is secure a requirement? > >> > >>>signaling path via one (or more) referral or transit network(s). In > >>>this case it is generally required that a trust relationship is > >>>established between the originating service provider and the transit > >>>network on one side, and the transit network and the termination > >>>network on the other side. > >>Maybe a figure would be helpful: > >> > >>A: VSP A > >>B: VSP B > >>T: Transit VSP > >> > >> A <---direct peering ---> T <--- direct peering ---> B > >> > >> ^ ^ > >> | | > >> \--------- indirect peering between A and B ---------/ > >> > >>>4.2.3. Assisted Peering > >>> > >>>In this case, some entity (usually a federation, see Section 5) > >>>employs a central SIP proxy (which is not itself a VSP) to bridge > >>>calls between participating networks. > >> ^^^^^ > >>IMO "participating peering networks" would add clarity. > >> > >>>5. Federations > >>> > >>... > >>>Finally, note that a SP can be a member of > >>> > >>> * No federation (e.g., the SP has only bilateral peering > >>> agreements) > >>> > >>> * A single federation > >>> > >>> * Multiple federations > >>> > >>>and an SP can have any combination of bi-lateral and multi-lateral > >>>(i.e., federated) interconnections. > >>SP should be replaced with VSP (3 times) > >> > >>regards > >>Klaus > >> > >>--=20 > >>Klaus Darilion > >>nic.at > >> > >>_______________________________________________ > >>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 From speermint-bounces@ietf.org Wed Oct 04 06:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4KA-0002Lf-PM; Wed, 04 Oct 2006 06:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4K8-0002KA-Oa for speermint@ietf.org; Wed, 04 Oct 2006 06:50:00 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV4K7-0004dk-AE for speermint@ietf.org; Wed, 04 Oct 2006 06:50:00 -0400 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] comments on draft-ietf-speermint-terminology-06.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 4 Oct 2006 12:49:08 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C5198@oefeg-s04.oefeg.loc> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301FEF582@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Thread-Index: Acbj1LIrfpQFjDo/RiqYZUpHgDeu7wCW5yCAAFx4S/A= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Inline > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 02, 2006 4:40 PM > To: Klaus Darilion; Stastny Richard > Cc: speermint@ietf.org > Subject: RE: [Speermint] comments on draft-ietf-speermint-terminology- > 06.txt >=20 > Be careful here. Secure could mean two things: >=20 > Integrity protected !=3D encrypted >=20 > Confidentiality protected =3D encrypted >=20 > Do we really mean the latter? I would say yes, possibly because media > encryption keys are carried, but that may not always be the case. =20 I would also say yes > How strong do we want to make this? Good question. I would say mandatory, but OTOH nobody could tell a VSP what kind of calls he is accepting Any comments? Richard >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Friday, September 29, 2006 10:36 AM > > To: Stastny Richard > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] comments on > > draft-ietf-speermint-terminology-06.txt > > > > Stastny Richard wrote: > > >> > 4.2. Layer 5 Peering > > >> > > > >> > Layer 5 (Session) peering refers to interconnection of > > two service > > >> > providers for the purposes of routing real-time (or quasi-real > > > time) > > >> > secure call signaling between their respective > > customers using SIP > > >> ^^^^^^ > > >> Is "secure" a requirement? > > >> > > >> What does secure mean - does it mean encryption? > > > > > > TLS or IPsec > > > > Then I would say encryption instead of secure. > > > > regards > > klaus > > > > > > > >> > 4.2.2. Indirect Peering > > >> > > > >> > Indirect, or transit, peering refers to the establishment of a > > > secure > > >> > > >> ^^^^ Again - is secure a requirement? > > >> > > > > > > IMHO yes > > > > > > Richard > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Thu Oct 05 08:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSWs-0000tP-Ax; Thu, 05 Oct 2006 08:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSWr-0000si-7c for speermint@ietf.org; Thu, 05 Oct 2006 08:40:45 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVSLU-00082t-LG for speermint@ietf.org; Thu, 05 Oct 2006 08:29:01 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k95CSuR26252; Thu, 5 Oct 2006 08:28:56 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Date: Thu, 5 Oct 2006 08:28:54 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301FEF592@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Thread-Index: AcbjzytNP0g2dAQDQWSMo5+LVlTkkACYbbrAAJIM9dA= From: "James McEachern" To: "Michael Hammer \(mhammer\)" , "Klaus Darilion" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Mike, [snip] >=20 > > Maybe a figure would be helpful: > > > > A: VSP A > > B: VSP B > > T: Transit VSP > > > > A <---direct peering ---> T <--- direct peering ---> B > > > > ^ ^ > > | | > > \--------- indirect peering between A and B ---------/ >=20 > This is backwards. > Direct peering is between A and B. > Indirect peering is between A and B indirectly through T. >=20 Changing the labels on this diagram will still be misleading. How about = the following? A <------------------------------------------------> B A-B "direct peering" A <---------------------> T <----------------------> B A-B "indirect peering" Jim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 05 10:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTt8-0003wb-6Y; Thu, 05 Oct 2006 10:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTt7-0003wU-D2 for speermint@ietf.org; Thu, 05 Oct 2006 10:07:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVTt6-0007eQ-2r for speermint@ietf.org; Thu, 05 Oct 2006 10:07:49 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2006 07:07:47 -0700 X-IronPort-AV: i="4.09,265,1157353200"; d="scan'208"; a="328407764:sNHT72064056" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95E7lVd022433; Thu, 5 Oct 2006 07:07:47 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k95E7nbF026434; Thu, 5 Oct 2006 07:07:49 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:07:43 -0400 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] comments on draft-ietf-speermint-terminology-06.txt Date: Thu, 5 Oct 2006 10:07:39 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30205B0A0@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draft-ietf-speermint-terminology-06.txt Thread-Index: AcbjzytNP0g2dAQDQWSMo5+LVlTkkACYbbrAAJIM9dAAA6BDgA== From: "Michael Hammer \(mhammer\)" To: "James McEachern" , "Klaus Darilion" , X-OriginalArrivalTime: 05 Oct 2006 14:07:43.0050 (UTC) FILETIME=[A01382A0:01C6E887] DKIM-Signature: a=rsa-sha1; q=dns; l=1315; t=1160057267; x=1160921267; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20comments=20on=20draft-ietf-speermint-terminology-0 6.txt; X=v=3Dcisco.com=3B=20h=3DQnZxRHjtS010wLetGkHwl2DYmyw=3D; b=T45xUk1ZYfH2lJrUYN7zfZbRQqruYiMiLGzKSmE/x9pyeHE/DvmEyiYQtdCpa9eJFfUah13u HgeWLMQHCsGo9LuJ/KYirIxNGEYRwdJA4poj0zutecKKajCKLwNMbUh6; Authentication-Results: sj-dkim-5.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org That works for me. Mike =20 > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Thursday, October 05, 2006 8:29 AM > To: Michael Hammer (mhammer); Klaus Darilion; speermint@ietf.org > Subject: RE: [Speermint] comments on=20 > draft-ietf-speermint-terminology-06.txt >=20 >=20 > Mike, >=20 > [snip] >=20 > > > > > Maybe a figure would be helpful: > > > > > > A: VSP A > > > B: VSP B > > > T: Transit VSP > > > > > > A <---direct peering ---> T <--- direct peering ---> B > > > > > > ^ ^ > > > | | > > > \--------- indirect peering between A and B ---------/ > > > > This is backwards. > > Direct peering is between A and B. > > Indirect peering is between A and B indirectly through T. > >=20 >=20 > Changing the labels on this diagram will still be misleading.=20 > How about the following? >=20 > A <------------------------------------------------> B > A-B "direct peering" >=20 > A <---------------------> T <----------------------> B > A-B "indirect peering" >=20 > Jim >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 05 10:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUh7-0001ku-H3; Thu, 05 Oct 2006 10:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUh6-0001gL-4x for speermint@ietf.org; Thu, 05 Oct 2006 10:59:28 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUh3-0004wG-Ro for speermint@ietf.org; Thu, 05 Oct 2006 10:59:28 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 22732210028; Thu, 5 Oct 2006 16:59:16 +0200 (CEST) Message-ID: <45251DC6.6090402@pernau.at> Date: Thu, 05 Oct 2006 16:59:18 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: James McEachern Subject: Re: [Speermint] comments on draft-ietf-speermint-terminology-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org James McEachern wrote: > Mike, > > [snip] > > > > > > Maybe a figure would be helpful: > > > > > > A: VSP A > > > B: VSP B > > > T: Transit VSP > > > > > > A <---direct peering ---> T <--- direct peering ---> B > > > > > > ^ ^ > > > | | > > > \--------- indirect peering between A and B ---------/ > > > > This is backwards. > > Direct peering is between A and B. > > Indirect peering is between A and B indirectly through T. > > > > Changing the labels on this diagram will still be misleading. How about the following? > > A <------------------------------------------------> B > A-B "direct peering" > > A <---------------------> T <----------------------> B > A-B "indirect peering" This looks fine. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 05 15:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYvw-0004KW-4C; Thu, 05 Oct 2006 15:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYvu-0004KF-Nw for speermint@ietf.org; Thu, 05 Oct 2006 15:31:02 -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 1GVUxn-0007o0-4J for speermint@ietf.org; Thu, 05 Oct 2006 11:16:43 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GVUkk-0003Kj-Lz for speermint@ietf.org; Thu, 05 Oct 2006 11:03:19 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k95F3BvQ028430; Thu, 5 Oct 2006 15:03:11 GMT Subject: RE: [Speermint] comments on draft-ietf-speermint-terminology-06.txt From: Daryl Malas To: James McEachern In-Reply-To: References: Content-Type: text/plain Date: Thu, 05 Oct 2006 09:04:36 -0600 Message-Id: <1160060677.16895.18.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I like the change. --Daryl On Thu, 2006-10-05 at 08:28 -0400, James McEachern wrote: > Mike, > > [snip] > > > > > > Maybe a figure would be helpful: > > > > > > A: VSP A > > > B: VSP B > > > T: Transit VSP > > > > > > A <---direct peering ---> T <--- direct peering ---> B > > > > > > ^ ^ > > > | | > > > \--------- indirect peering between A and B ---------/ > > > > This is backwards. > > Direct peering is between A and B. > > Indirect peering is between A and B indirectly through T. > > > > Changing the labels on this diagram will still be misleading. How about the following? > > A <------------------------------------------------> B > A-B "direct peering" > > A <---------------------> T <----------------------> B > A-B "indirect peering" > > Jim > > _______________________________________________ > 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 From speermint-bounces@ietf.org Thu Oct 05 18:53:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVc51-0000OV-Hy; Thu, 05 Oct 2006 18:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVc50-0000Ir-8O for speermint@ietf.org; Thu, 05 Oct 2006 18:52:38 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVbpW-0006gQ-33 for speermint@ietf.org; Thu, 05 Oct 2006 18:36:39 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k95MaavQ004685 for ; Thu, 5 Oct 2006 22:36:36 GMT Subject: [Speermint] Basic Peering Requirements From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Thu, 05 Oct 2006 16:38:02 -0600 Message-Id: <1160087883.16895.26.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I was asked at the interim meeting to put together a list of base-level peering requirements by Jean-francois. I put together a list and tried to send it to him, but I'm not sure it ever made it. In either case, I wanted to post it to the list, so the WG will have ample time to pummel it before San Diego. ;-) ---------------------------------------------------------------------- Jean-Francois, Per our conversation in Philadelphia, I have compiled a list of basic peering requirements from one operators perspective. I can post these to the list if you would like. Here is a list of peering requirements (this is certainly not exhaustive, but is a platform): Transport (Layer 1 3): Peering must utilize IP as the primary mechanism for peering. A federation must agree upon a common mechanism for IP transport either private (e.g. IPVPN, IPSEC, etc.) or public. (Net of this...most operators will peer with these methods today.) Billing: If peering services involve billing, the peers or federation must agree on a common monetary policy. The peers or federation must agree on a common currency. (Net of this...some customers may abuse peering, and operators may want to bill for certain traffic pattern types (e.g. Layer 3 IP Peering Leaches).) Policy: Policies may be implemented locally to the peer or via a centralized mechanism within the federation. Local policies should be disclosed when creating direct peering relationships with the applicable direct peer. Local policies may supersede centralized federation policies. (Net of this...some peering relationships will be 1:1, so policies will likely be local only. Some peering relationships will be 1:N, so policies will likely be implemented within DNS or some centralized mechanism.) Membership: A peer may be a member of multiple federations A peer must maintain compliancy for policies as defined by each federation the peer is a member of. If a peer is providing connectivity to multiple federations, it should disclose AoRs providing indirect peering relationships to servicing peers or federations. Peers providing indirect peering must enforce federation policies on behalf of the destination federation. A peer providing indirect peering may enforce undisclosed policies for processing session requests between federations. (Net of this...some peers will only desire to be part of a single federation, where wholesale carriers will likely be members of multiple federations.) Media: Peers must agree on one or more CODECs, which is either negotiated directly or via a transcoding mechanism. A transcoding mechanism may exist locally or centralized within the federation. (Net of this...most operators only support a couple of CODECs across the core of their network, but will transcode at the edge.) Routing: A peer must utilize the centralized federation routing mechanism if it is available. A peer allowing another peer within a federation to provide indirect peering on their behalf must select only one indirect peer to host their AoRs. A peer must not copy routing information from or make assumed routing choices on behalf of the centralized routing mechanism for use locally unless it takes place through standard caching methods. A common API must be utilized and available for subscriber and route provisioning on any centralized federation location function. Subscriber and routing information must be dynamically updated as soon as applicable for accurate routing within the federation. (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple and not too inefficient. In a larger peering scenario (e.g. 1:N), a more efficient method is absolutely necessary, in comes ENUM/DNS/NAPTR. Unfortunately, both methods will likely be necessary until wider spread adoption of DNS methods takes place.) Performance: Performance metrics must be shared between peers as they apply directly to peering signaling and media on a consistent basis within the federation. (Net of this...this is just a reality otherwise; finger pointing takes place anytime something breaks.) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 05 23:57:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVgoX-0002qr-Hd; Thu, 05 Oct 2006 23:55:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVgoW-0002qc-95 for speermint@ietf.org; Thu, 05 Oct 2006 23:55:56 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVgeF-0000Mb-5A for speermint@ietf.org; Thu, 05 Oct 2006 23:45:20 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k963jHlS016988; Thu, 5 Oct 2006 21:45:18 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Basic Peering Requirements Date: Thu, 5 Oct 2006 21:45:17 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acbo0UPA4mcLVz4cRPK3UAcQGeol/gAJlsBw From: "Jean-Francois Mule" To: "Daryl Malas" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks for the follow-up Daryl. Posting to the list is always preferred as far as I am concerned, especially when I'm traveling. We discussed this during our interim meeting. To clarify the intent of such a list, the idea is to capture the list of things that may be discussed between 2 peers in the form of a template in an appendix of the requirement document. This suggestion was made by Tom Creighton. This proposal would help: 1. capture things that are out of scope outside the main requirement document, yet keep on being raised like billing, IP transport independency, federation membership or 'policies' 2. help put some context and possibly requirements for the federation text in draft-terminology-draft 6 and Otmar's I-D.lendl-domain-policy-ddds=20 Jean-Francois. > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thursday, October 05, 2006 4:38 PM > To: speermint@ietf.org > Subject: [Speermint] Basic Peering Requirements >=20 > I was asked at the interim meeting to put together a list of base- > level > peering requirements by Jean-francois. I put together a list and > tried > to send it to him, but I'm not sure it ever made it. In either case, > I > wanted to post it to the list, so the WG will have ample time to > pummel > it before San Diego. ;-) >=20 > ---------------------------------------------------------------------- >=20 > Jean-Francois, >=20 > Per our conversation in Philadelphia, I have compiled a list of basic > peering requirements from one operators perspective. I can post these > to the list if you would like. Here is a list of peering requirements > (this is certainly not exhaustive, but is a platform): >=20 > Transport (Layer 1 3): >=20 > Peering must utilize IP as the primary mechanism for peering. >=20 > A federation must agree upon a common mechanism for IP transport > either > private (e.g. IPVPN, IPSEC, etc.) or public. >=20 > (Net of this...most operators will peer with these methods today.) >=20 > Billing: >=20 > If peering services involve billing, the peers or federation must > agree > on a common monetary policy. >=20 > The peers or federation must agree on a common currency. >=20 > (Net of this...some customers may abuse peering, and operators may > want > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > Leaches).) >=20 > Policy: >=20 > Policies may be implemented locally to the peer or via a centralized > mechanism within the federation. >=20 > Local policies should be disclosed when creating direct peering > relationships with the applicable direct peer. >=20 > Local policies may supersede centralized federation policies. >=20 > (Net of this...some peering relationships will be 1:1, so policies > will > likely be local only. Some peering relationships will be 1:N, so > policies will likely be implemented within DNS or some centralized > mechanism.) >=20 > Membership: >=20 > A peer may be a member of multiple federations >=20 > A peer must maintain compliancy for policies as defined by each > federation the peer is a member of. >=20 > If a peer is providing connectivity to multiple federations, it should > disclose AoRs providing indirect peering relationships to servicing > peers or federations. >=20 > Peers providing indirect peering must enforce federation policies on > behalf of the destination federation. >=20 > A peer providing indirect peering may enforce undisclosed policies for > processing session requests between federations. >=20 > (Net of this...some peers will only desire to be part of a single > federation, where wholesale carriers will likely be members of > multiple > federations.) >=20 > Media: >=20 > Peers must agree on one or more CODECs, which is either negotiated > directly or via a transcoding mechanism. >=20 > A transcoding mechanism may exist locally or centralized within the > federation. >=20 > (Net of this...most operators only support a couple of CODECs across > the > core of their network, but will transcode at the edge.) >=20 > Routing: >=20 > A peer must utilize the centralized federation routing mechanism if it > is available. >=20 > A peer allowing another peer within a federation to provide indirect > peering on their behalf must select only one indirect peer to host > their > AoRs. >=20 > A peer must not copy routing information from or make assumed routing > choices on behalf of the centralized routing mechanism for use locally > unless it takes place through standard caching methods. >=20 > A common API must be utilized and available for subscriber and route > provisioning on any centralized federation location function. >=20 > Subscriber and routing information must be dynamically updated as soon > as applicable for accurate routing within the federation. >=20 > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > more efficient method is absolutely necessary, in comes ENUM/DNS/NAPTR. > Unfortunately, both methods will likely be necessary until wider > spread > adoption of DNS methods takes place.) >=20 > Performance: >=20 > Performance metrics must be shared between peers as they apply > directly > to peering signaling and media on a consistent basis within the > federation. >=20 > (Net of this...this is just a reality otherwise; finger pointing takes > place anytime something breaks.) >=20 >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Fri Oct 06 04:11:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVknF-0000xn-Uw; Fri, 06 Oct 2006 04:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVknD-0000t0-5i for speermint@ietf.org; Fri, 06 Oct 2006 04:10:51 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVkdo-00038p-MS for speermint@ietf.org; Fri, 06 Oct 2006 04:01:10 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 6 Oct 2006 10:00:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> In-Reply-To: <1160087883.16895.26.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acbo0PZn9mF48CttTOWM7T4BESBYgwAS6vKg From: "Stastny Richard" To: "Daryl Malas" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Questions for clarification: > If a peer is providing connectivity to multiple federations, it should > disclose AoRs providing indirect peering relationships to servicing > peers or federations. AoRs? - You mean entry points? > A peer allowing another peer within a federation to provide indirect > peering on their behalf must select only one indirect peer to host their > AoRs I do not understand. An AoR is defining the destination, How can it be hosted be an indirect peer? Could you please explain Richard > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Friday, October 06, 2006 12:38 AM > To: speermint@ietf.org > Subject: [Speermint] Basic Peering Requirements >=20 > I was asked at the interim meeting to put together a list of base-level > peering requirements by Jean-francois. I put together a list and tried > to send it to him, but I'm not sure it ever made it. In either case, I > wanted to post it to the list, so the WG will have ample time to pummel > it before San Diego. ;-) >=20 > ---------------------------------------------------------------------- >=20 > Jean-Francois, >=20 > Per our conversation in Philadelphia, I have compiled a list of basic > peering requirements from one operators perspective. I can post these > to the list if you would like. Here is a list of peering requirements > (this is certainly not exhaustive, but is a platform): >=20 > Transport (Layer 1 3): >=20 > Peering must utilize IP as the primary mechanism for peering. >=20 > A federation must agree upon a common mechanism for IP transport either > private (e.g. IPVPN, IPSEC, etc.) or public. >=20 > (Net of this...most operators will peer with these methods today.) >=20 > Billing: >=20 > If peering services involve billing, the peers or federation must agree > on a common monetary policy. >=20 > The peers or federation must agree on a common currency. >=20 > (Net of this...some customers may abuse peering, and operators may want > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > Leaches).) >=20 > Policy: >=20 > Policies may be implemented locally to the peer or via a centralized > mechanism within the federation. >=20 > Local policies should be disclosed when creating direct peering > relationships with the applicable direct peer. >=20 > Local policies may supersede centralized federation policies. >=20 > (Net of this...some peering relationships will be 1:1, so policies will > likely be local only. Some peering relationships will be 1:N, so > policies will likely be implemented within DNS or some centralized > mechanism.) >=20 > Membership: >=20 > A peer may be a member of multiple federations >=20 > A peer must maintain compliancy for policies as defined by each > federation the peer is a member of. >=20 > If a peer is providing connectivity to multiple federations, it should > disclose AoRs providing indirect peering relationships to servicing > peers or federations. >=20 > Peers providing indirect peering must enforce federation policies on > behalf of the destination federation. >=20 > A peer providing indirect peering may enforce undisclosed policies for > processing session requests between federations. >=20 > (Net of this...some peers will only desire to be part of a single > federation, where wholesale carriers will likely be members of multiple > federations.) >=20 > Media: >=20 > Peers must agree on one or more CODECs, which is either negotiated > directly or via a transcoding mechanism. >=20 > A transcoding mechanism may exist locally or centralized within the > federation. >=20 > (Net of this...most operators only support a couple of CODECs across the > core of their network, but will transcode at the edge.) >=20 > Routing: >=20 > A peer must utilize the centralized federation routing mechanism if it > is available. >=20 > A peer allowing another peer within a federation to provide indirect > peering on their behalf must select only one indirect peer to host their > AoRs. >=20 > A peer must not copy routing information from or make assumed routing > choices on behalf of the centralized routing mechanism for use locally > unless it takes place through standard caching methods. >=20 > A common API must be utilized and available for subscriber and route > provisioning on any centralized federation location function. >=20 > Subscriber and routing information must be dynamically updated as soon > as applicable for accurate routing within the federation. >=20 > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > more efficient method is absolutely necessary, in comes ENUM/DNS/NAPTR. > Unfortunately, both methods will likely be necessary until wider spread > adoption of DNS methods takes place.) >=20 > Performance: >=20 > Performance metrics must be shared between peers as they apply directly > to peering signaling and media on a consistent basis within the > federation. >=20 > (Net of this...this is just a reality otherwise; finger pointing takes > place anytime something breaks.) >=20 >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Fri Oct 06 10:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqqZ-0000hp-TG; Fri, 06 Oct 2006 10:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqqX-0000fV-Ji for speermint@ietf.org; Fri, 06 Oct 2006 10:38:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVqqU-0002R8-Vb for speermint@ietf.org; Fri, 06 Oct 2006 10:38:41 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 06 Oct 2006 07:38:38 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="1856810993:sNHT59694260" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96Eccxx021575; Fri, 6 Oct 2006 07:38:38 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k96EcRbV012222; Fri, 6 Oct 2006 07:38:38 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 10:38:26 -0400 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] Basic Peering Requirements Date: Fri, 6 Oct 2006 10:38:25 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30205B4BE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acbo0UNmu3vVpNggSXCXf6Fc3V2A8wAg8DoA From: "Michael Hammer \(mhammer\)" To: "Daryl Malas" , X-OriginalArrivalTime: 06 Oct 2006 14:38:26.0626 (UTC) FILETIME=[1558A220:01C6E955] DKIM-Signature: a=rsa-sha1; q=dns; l=5193; t=1160145518; x=1161009518; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=BwWMs4eQacfdl3CR15qXZun2kxXoHtNVJLQjnI+XlO5pFjnwrDmuq+7YEbbVWkAu0ozg96gL UkHR0Igu4wmInfEHhC0ovrGbqorezY+Eo/H67XhGdf4yMF8Tiykck6sz; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Excellent list. Glad to see we are capturing this in an ID. Mike =20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Thursday, October 05, 2006 6:38 PM > To: speermint@ietf.org > Subject: [Speermint] Basic Peering Requirements >=20 > I was asked at the interim meeting to put together a list of=20 > base-level peering requirements by Jean-francois. I put=20 > together a list and tried to send it to him, but I'm not sure=20 > it ever made it. In either case, I wanted to post it to the=20 > list, so the WG will have ample time to pummel it before San=20 > Diego. ;-) >=20 > ---------------------------------------------------------------------- >=20 > Jean-Francois, >=20 > Per our conversation in Philadelphia, I have compiled a list=20 > of basic peering requirements from one operators perspective.=20 > I can post these to the list if you would like. Here is a=20 > list of peering requirements (this is certainly not=20 > exhaustive, but is a platform): >=20 > Transport (Layer 1 3): >=20 > Peering must utilize IP as the primary mechanism for peering.=20 >=20 > A federation must agree upon a common mechanism for IP=20 > transport either private (e.g. IPVPN, IPSEC, etc.) or public.=20 >=20 > (Net of this...most operators will peer with these methods today.) >=20 > Billing: >=20 > If peering services involve billing, the peers or federation=20 > must agree on a common monetary policy.=20 >=20 > The peers or federation must agree on a common currency.=20 >=20 > (Net of this...some customers may abuse peering, and=20 > operators may want to bill for certain traffic pattern types=20 > (e.g. Layer 3 IP Peering > Leaches).) >=20 > Policy: >=20 > Policies may be implemented locally to the peer or via a=20 > centralized mechanism within the federation.=20 >=20 > Local policies should be disclosed when creating direct=20 > peering relationships with the applicable direct peer.=20 >=20 > Local policies may supersede centralized federation policies.=20 >=20 > (Net of this...some peering relationships will be 1:1, so=20 > policies will likely be local only. Some peering=20 > relationships will be 1:N, so policies will likely be=20 > implemented within DNS or some centralized > mechanism.) >=20 > Membership: >=20 > A peer may be a member of multiple federations=20 >=20 > A peer must maintain compliancy for policies as defined by=20 > each federation the peer is a member of.=20 >=20 > If a peer is providing connectivity to multiple federations,=20 > it should disclose AoRs providing indirect peering=20 > relationships to servicing peers or federations.=20 >=20 > Peers providing indirect peering must enforce federation=20 > policies on behalf of the destination federation.=20 >=20 > A peer providing indirect peering may enforce undisclosed=20 > policies for processing session requests between federations.=20 >=20 > (Net of this...some peers will only desire to be part of a=20 > single federation, where wholesale carriers will likely be=20 > members of multiple > federations.) >=20 > Media: >=20 > Peers must agree on one or more CODECs, which is either=20 > negotiated directly or via a transcoding mechanism.=20 >=20 > A transcoding mechanism may exist locally or centralized=20 > within the federation.=20 >=20 > (Net of this...most operators only support a couple of CODECs=20 > across the core of their network, but will transcode at the edge.) >=20 > Routing: >=20 > A peer must utilize the centralized federation routing=20 > mechanism if it is available.=20 >=20 > A peer allowing another peer within a federation to provide=20 > indirect peering on their behalf must select only one=20 > indirect peer to host their AoRs.=20 >=20 > A peer must not copy routing information from or make assumed=20 > routing choices on behalf of the centralized routing=20 > mechanism for use locally unless it takes place through=20 > standard caching methods.=20 >=20 > A common API must be utilized and available for subscriber=20 > and route provisioning on any centralized federation location=20 > function.=20 >=20 > Subscriber and routing information must be dynamically=20 > updated as soon as applicable for accurate routing within the=20 > federation.=20 >=20 > (Net of this...In small peering (e.g. 1:1), a REDIRECT model=20 > is simple and not too inefficient. In a larger peering=20 > scenario (e.g. 1:N), a more efficient method is absolutely=20 > necessary, in comes ENUM/DNS/NAPTR. > Unfortunately, both methods will likely be necessary until=20 > wider spread adoption of DNS methods takes place.) >=20 > Performance: >=20 > Performance metrics must be shared between peers as they=20 > apply directly to peering signaling and media on a consistent=20 > basis within the federation.=20 >=20 > (Net of this...this is just a reality otherwise; finger=20 > pointing takes place anytime something breaks.) >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 06 11:18:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSX-0006Mt-Ht; Fri, 06 Oct 2006 11:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrSW-0006MT-FR for speermint@ietf.org; Fri, 06 Oct 2006 11:17:56 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrDh-0007Wn-TQ for speermint@ietf.org; Fri, 06 Oct 2006 11:02:40 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k96F2ZvQ027560; Fri, 6 Oct 2006 15:02:35 GMT Subject: RE: [Speermint] Basic Peering Requirements From: Daryl Malas To: Stastny Richard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> Content-Type: text/plain Date: Fri, 06 Oct 2006 09:04:04 -0600 Message-Id: <1160147044.16895.33.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Fri, 2006-10-06 at 10:00 +0200, Stastny Richard wrote: > Questions for clarification: > > > If a peer is providing connectivity to multiple federations, it should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > AoRs? - You mean entry points? Yes, my intention was to use it as described in RFC 3327. "Each incoming request targeted to the public address-of-record for the user is routed to this proxy..." The AoRs in this case are representing the public address-of-record for the indirect peered domain(s). I apologize if I used this term incorrectly, I felt it applied. I can changed the terminology if there is a problem with it. --Daryl > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host > their > > AoRs > > I do not understand. An AoR is defining the destination, > How can it be hosted be an indirect peer? > > Could you please explain > > Richard > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Friday, October 06, 2006 12:38 AM > > To: speermint@ietf.org > > Subject: [Speermint] Basic Peering Requirements > > > > I was asked at the interim meeting to put together a list of > base-level > > peering requirements by Jean-francois. I put together a list and > tried > > to send it to him, but I'm not sure it ever made it. In either case, > I > > wanted to post it to the list, so the WG will have ample time to > pummel > > it before San Diego. ;-) > > > > ---------------------------------------------------------------------- > > > > Jean-Francois, > > > > Per our conversation in Philadelphia, I have compiled a list of basic > > peering requirements from one operators perspective. I can post these > > to the list if you would like. Here is a list of peering requirements > > (this is certainly not exhaustive, but is a platform): > > > > Transport (Layer 1 3): > > > > Peering must utilize IP as the primary mechanism for peering. > > > > A federation must agree upon a common mechanism for IP transport > either > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > (Net of this...most operators will peer with these methods today.) > > > > Billing: > > > > If peering services involve billing, the peers or federation must > agree > > on a common monetary policy. > > > > The peers or federation must agree on a common currency. > > > > (Net of this...some customers may abuse peering, and operators may > want > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > Leaches).) > > > > Policy: > > > > Policies may be implemented locally to the peer or via a centralized > > mechanism within the federation. > > > > Local policies should be disclosed when creating direct peering > > relationships with the applicable direct peer. > > > > Local policies may supersede centralized federation policies. > > > > (Net of this...some peering relationships will be 1:1, so policies > will > > likely be local only. Some peering relationships will be 1:N, so > > policies will likely be implemented within DNS or some centralized > > mechanism.) > > > > Membership: > > > > A peer may be a member of multiple federations > > > > A peer must maintain compliancy for policies as defined by each > > federation the peer is a member of. > > > > If a peer is providing connectivity to multiple federations, it should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > > > Peers providing indirect peering must enforce federation policies on > > behalf of the destination federation. > > > > A peer providing indirect peering may enforce undisclosed policies for > > processing session requests between federations. > > > > (Net of this...some peers will only desire to be part of a single > > federation, where wholesale carriers will likely be members of > multiple > > federations.) > > > > Media: > > > > Peers must agree on one or more CODECs, which is either negotiated > > directly or via a transcoding mechanism. > > > > A transcoding mechanism may exist locally or centralized within the > > federation. > > > > (Net of this...most operators only support a couple of CODECs across > the > > core of their network, but will transcode at the edge.) > > > > Routing: > > > > A peer must utilize the centralized federation routing mechanism if it > > is available. > > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host > their > > AoRs. > > > > A peer must not copy routing information from or make assumed routing > > choices on behalf of the centralized routing mechanism for use locally > > unless it takes place through standard caching methods. > > > > A common API must be utilized and available for subscriber and route > > provisioning on any centralized federation location function. > > > > Subscriber and routing information must be dynamically updated as soon > > as applicable for accurate routing within the federation. > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > more efficient method is absolutely necessary, in comes > ENUM/DNS/NAPTR. > > Unfortunately, both methods will likely be necessary until wider > spread > > adoption of DNS methods takes place.) > > > > Performance: > > > > Performance metrics must be shared between peers as they apply > directly > > to peering signaling and media on a consistent basis within the > > federation. > > > > (Net of this...this is just a reality otherwise; finger pointing takes > > place anytime something breaks.) > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Fri Oct 06 11:21:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrW9-0000p9-OD; Fri, 06 Oct 2006 11:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrW8-0000p3-Gm for speermint@ietf.org; Fri, 06 Oct 2006 11:21:40 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrW7-0005Kl-Ts for speermint@ietf.org; Fri, 06 Oct 2006 11:21:40 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k96FLavQ005165; Fri, 6 Oct 2006 15:21:37 GMT Subject: RE: [Speermint] Basic Peering Requirements From: Daryl Malas To: Jean-Francois Mule In-Reply-To: References: Content-Type: text/plain Date: Fri, 06 Oct 2006 09:23:05 -0600 Message-Id: <1160148186.16895.49.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay, so everything in this list would be discussed during the negotiation between 2 peers. The answers to these requirements or discussion points might differ based on Operator; however, the same basic requirements will likely need to be met. I apologize if I duplicated any, which are already in the requirements document. I was trying to think through the peering negotiation (business arrangement) process, while detailing each of the sticking points along the way. To be specific, policies in this list are at a very basic level. Here's the only list of policies I see being discussed at this time (feel free to add or subtract as you feel necessary): 1. Only 'X' CODEC(s) will be supported into federation B or Peer A's network. 2. Only 'n' number of peering sessions will be allowed at any given time. 3. Peer A will only support these 'X' SIP headers and methods (extensions) via peering requests (In other words an Operator may not support Redirect in and out of a federation...it's simply an example.) --This one brings up an interesting aspect. It might be noted a UAC could send an OPTIONS message to a federation or peer to understand some of these supported "aspects", but these will also likely be negotiated up front. These can be enforced at the federation level or via local policies. --Daryl On Thu, 2006-10-05 at 21:45 -0600, Jean-Francois Mule wrote: > Thanks for the follow-up Daryl. Posting to the list is always preferred > as far as I am concerned, especially when I'm traveling. > > We discussed this during our interim meeting. To clarify the intent of > such a list, the idea is to capture the list of things that may be > discussed between 2 peers in the form of a template in an appendix of > the requirement document. This suggestion was made by Tom Creighton. > > This proposal would help: > 1. capture things that are out of scope outside the main > requirement document, yet keep on being raised like billing, IP > transport independency, federation membership or 'policies' > 2. help put some context and possibly requirements for the > federation text in draft-terminology-draft 6 and Otmar's > I-D.lendl-domain-policy-ddds > > Jean-Francois. > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Thursday, October 05, 2006 4:38 PM > > To: speermint@ietf.org > > Subject: [Speermint] Basic Peering Requirements > > > > I was asked at the interim meeting to put together a list of base- > > level > > peering requirements by Jean-francois. I put together a list and > > tried > > to send it to him, but I'm not sure it ever made it. In either case, > > I > > wanted to post it to the list, so the WG will have ample time to > > pummel > > it before San Diego. ;-) > > > > ---------------------------------------------------------------------- > > > > Jean-Francois, > > > > Per our conversation in Philadelphia, I have compiled a list of basic > > peering requirements from one operators perspective. I can post these > > to the list if you would like. Here is a list of peering requirements > > (this is certainly not exhaustive, but is a platform): > > > > Transport (Layer 1 3): > > > > Peering must utilize IP as the primary mechanism for peering. > > > > A federation must agree upon a common mechanism for IP transport > > either > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > (Net of this...most operators will peer with these methods today.) > > > > Billing: > > > > If peering services involve billing, the peers or federation must > > agree > > on a common monetary policy. > > > > The peers or federation must agree on a common currency. > > > > (Net of this...some customers may abuse peering, and operators may > > want > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > Leaches).) > > > > Policy: > > > > Policies may be implemented locally to the peer or via a centralized > > mechanism within the federation. > > > > Local policies should be disclosed when creating direct peering > > relationships with the applicable direct peer. > > > > Local policies may supersede centralized federation policies. > > > > (Net of this...some peering relationships will be 1:1, so policies > > will > > likely be local only. Some peering relationships will be 1:N, so > > policies will likely be implemented within DNS or some centralized > > mechanism.) > > > > Membership: > > > > A peer may be a member of multiple federations > > > > A peer must maintain compliancy for policies as defined by each > > federation the peer is a member of. > > > > If a peer is providing connectivity to multiple federations, it should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > > > Peers providing indirect peering must enforce federation policies on > > behalf of the destination federation. > > > > A peer providing indirect peering may enforce undisclosed policies for > > processing session requests between federations. > > > > (Net of this...some peers will only desire to be part of a single > > federation, where wholesale carriers will likely be members of > > multiple > > federations.) > > > > Media: > > > > Peers must agree on one or more CODECs, which is either negotiated > > directly or via a transcoding mechanism. > > > > A transcoding mechanism may exist locally or centralized within the > > federation. > > > > (Net of this...most operators only support a couple of CODECs across > > the > > core of their network, but will transcode at the edge.) > > > > Routing: > > > > A peer must utilize the centralized federation routing mechanism if it > > is available. > > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host > > their > > AoRs. > > > > A peer must not copy routing information from or make assumed routing > > choices on behalf of the centralized routing mechanism for use locally > > unless it takes place through standard caching methods. > > > > A common API must be utilized and available for subscriber and route > > provisioning on any centralized federation location function. > > > > Subscriber and routing information must be dynamically updated as soon > > as applicable for accurate routing within the federation. > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > more efficient method is absolutely necessary, in comes > ENUM/DNS/NAPTR. > > Unfortunately, both methods will likely be necessary until wider > > spread > > adoption of DNS methods takes place.) > > > > Performance: > > > > Performance metrics must be shared between peers as they apply > > directly > > to peering signaling and media on a consistent basis within the > > federation. > > > > (Net of this...this is just a reality otherwise; finger pointing takes > > place anytime something breaks.) > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Fri Oct 06 11:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrey-0005ze-0Q; Fri, 06 Oct 2006 11:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVrew-0005y7-7N for speermint@ietf.org; Fri, 06 Oct 2006 11:30:46 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVrev-00080v-Pf for speermint@ietf.org; Fri, 06 Oct 2006 11:30:46 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 51014368D; Fri, 6 Oct 2006 11:30:15 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 11:30:14 -0400 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] Basic Peering Requirements Date: Fri, 6 Oct 2006 11:30:12 -0400 Message-ID: In-Reply-To: <1160148186.16895.49.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbpWzE0WXJ4cMDsRF6BdDraVjmINQAAEnxg From: "Uzelac, Adam" To: "Daryl Malas" , "Jean-Francois Mule" X-OriginalArrivalTime: 06 Oct 2006 15:30:14.0889 (UTC) FILETIME=[5203ED90:01C6E95C] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org A some thoughts here.... I would add to number 2, or create a new entry for: 'x' number of sessions per second transaction rate. This policy is implemented to protect the peering point from mass call events, malicious or "American Idol" style. With regards to your point about being enforced at the federation level - I could see mandates around codec and SIP headers at a federation level, but I am not so sure about limits on concurrent sessions and transaction rates. That is purely local policy believe. -AU -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Friday, October 06, 2006 11:23 AM To: Jean-Francois Mule Cc: speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements Okay, so everything in this list would be discussed during the negotiation between 2 peers. The answers to these requirements or discussion points might differ based on Operator; however, the same basic requirements will likely need to be met. I apologize if I duplicated any, which are already in the requirements document. I was trying to think through the peering negotiation (business arrangement) process, while detailing each of the sticking points along the way. To be specific, policies in this list are at a very basic level. Here's the only list of policies I see being discussed at this time (feel free to add or subtract as you feel necessary): 1. Only 'X' CODEC(s) will be supported into federation B or Peer A's network. 2. Only 'n' number of peering sessions will be allowed at any given time. 3. Peer A will only support these 'X' SIP headers and methods (extensions) via peering requests (In other words an Operator may not support Redirect in and out of a federation...it's simply an example.) --This one brings up an interesting aspect. It might be noted a UAC could send an OPTIONS message to a federation or peer to understand some of these supported "aspects", but these will also likely be negotiated up front. These can be enforced at the federation level or via local policies. --Daryl On Thu, 2006-10-05 at 21:45 -0600, Jean-Francois Mule wrote: > Thanks for the follow-up Daryl. Posting to the list is always=20 > preferred as far as I am concerned, especially when I'm traveling. >=20 > We discussed this during our interim meeting. To clarify the intent of > such a list, the idea is to capture the list of things that may be=20 > discussed between 2 peers in the form of a template in an appendix of=20 > the requirement document. This suggestion was made by Tom Creighton. >=20 > This proposal would help: > 1. capture things that are out of scope outside the main requirement=20 > document, yet keep on being raised like billing, IP transport=20 > independency, federation membership or 'policies' > 2. help put some context and possibly requirements for the federation=20 > text in draft-terminology-draft 6 and Otmar's=20 > I-D.lendl-domain-policy-ddds >=20 > Jean-Francois. >=20 > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Thursday, October 05, 2006 4:38 PM > > To: speermint@ietf.org > > Subject: [Speermint] Basic Peering Requirements > >=20 > > I was asked at the interim meeting to put together a list of base-=20 > > level peering requirements by Jean-francois. I put together a list=20 > > and tried to send it to him, but I'm not sure it ever made it. In=20 > > either case, I wanted to post it to the list, so the WG will have=20 > > ample time to pummel it before San Diego. ;-) > >=20 > > -------------------------------------------------------------------- > > -- > >=20 > > Jean-Francois, > >=20 > > Per our conversation in Philadelphia, I have compiled a list of=20 > > basic peering requirements from one operators perspective. I can=20 > > post these to the list if you would like. Here is a list of peering > > requirements (this is certainly not exhaustive, but is a platform): > >=20 > > Transport (Layer 1 3): > >=20 > > Peering must utilize IP as the primary mechanism for peering. > >=20 > > A federation must agree upon a common mechanism for IP transport=20 > > either private (e.g. IPVPN, IPSEC, etc.) or public. > >=20 > > (Net of this...most operators will peer with these methods today.) > >=20 > > Billing: > >=20 > > If peering services involve billing, the peers or federation must=20 > > agree on a common monetary policy. > >=20 > > The peers or federation must agree on a common currency. > >=20 > > (Net of this...some customers may abuse peering, and operators may=20 > > want to bill for certain traffic pattern types (e.g. Layer 3 IP=20 > > Peering > > Leaches).) > >=20 > > Policy: > >=20 > > Policies may be implemented locally to the peer or via a centralized > > mechanism within the federation. > >=20 > > Local policies should be disclosed when creating direct peering=20 > > relationships with the applicable direct peer. > >=20 > > Local policies may supersede centralized federation policies. > >=20 > > (Net of this...some peering relationships will be 1:1, so policies=20 > > will likely be local only. Some peering relationships will be 1:N,=20 > > so policies will likely be implemented within DNS or some=20 > > centralized > > mechanism.) > >=20 > > Membership: > >=20 > > A peer may be a member of multiple federations > >=20 > > A peer must maintain compliancy for policies as defined by each=20 > > federation the peer is a member of. > >=20 > > If a peer is providing connectivity to multiple federations, it=20 > > should disclose AoRs providing indirect peering relationships to=20 > > servicing peers or federations. > >=20 > > Peers providing indirect peering must enforce federation policies on > > behalf of the destination federation. > >=20 > > A peer providing indirect peering may enforce undisclosed policies=20 > > for processing session requests between federations. > >=20 > > (Net of this...some peers will only desire to be part of a single=20 > > federation, where wholesale carriers will likely be members of=20 > > multiple > > federations.) > >=20 > > Media: > >=20 > > Peers must agree on one or more CODECs, which is either negotiated=20 > > directly or via a transcoding mechanism. > >=20 > > A transcoding mechanism may exist locally or centralized within the=20 > > federation. > >=20 > > (Net of this...most operators only support a couple of CODECs across > > the core of their network, but will transcode at the edge.) > >=20 > > Routing: > >=20 > > A peer must utilize the centralized federation routing mechanism if=20 > > it is available. > >=20 > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host=20 > > their AoRs. > >=20 > > A peer must not copy routing information from or make assumed=20 > > routing choices on behalf of the centralized routing mechanism for=20 > > use locally unless it takes place through standard caching methods. > >=20 > > A common API must be utilized and available for subscriber and route > > provisioning on any centralized federation location function. > >=20 > > Subscriber and routing information must be dynamically updated as=20 > > soon as applicable for accurate routing within the federation. > >=20 > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is=20 > > simple and not too inefficient. In a larger peering scenario (e.g.=20 > > 1:N), a more efficient method is absolutely necessary, in comes > ENUM/DNS/NAPTR. > > Unfortunately, both methods will likely be necessary until wider=20 > > spread adoption of DNS methods takes place.) > >=20 > > Performance: > >=20 > > Performance metrics must be shared between peers as they apply=20 > > directly to peering signaling and media on a consistent basis within > > the federation. > >=20 > > (Net of this...this is just a reality otherwise; finger pointing=20 > > takes place anytime something breaks.) > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ 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 From speermint-bounces@ietf.org Fri Oct 06 12:14:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsL0-0004Rb-HR; Fri, 06 Oct 2006 12:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsKz-0004RW-7i for speermint@ietf.org; Fri, 06 Oct 2006 12:14:13 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsKy-0002jx-QQ for speermint@ietf.org; Fri, 06 Oct 2006 12:14:13 -0400 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] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 Date: Fri, 6 Oct 2006 12:13:53 -0400 Message-ID: <45AEC6EF95942140888406588E1A660217DBB5@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 Thread-Index: AcbjseKiSWVpZIFtRoqwKIMYoR5sEwFqdHBA From: "Khandpur, Gaurav" To: "Klaus Darilion" , X-OriginalArrivalTime: 06 Oct 2006 16:13:54.0340 (UTC) FILETIME=[6B546E40:01C6E962] X-Spam-Score: 1.1 (+) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thank you for your comments, Klaus. See inline [GKH]. -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Friday, September 29, 2006 6:24 AM To: speermint@ietf.org Subject: [Speermint] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 Hi Tom, Gaurav! Following some comments. > 3. Session Peering Setup=20 > =20 > SIP systems are represented by user agents (UA). In the diagram=20 > below, a user agent (UA1), hosted by a service provider SP1,=20 > initiates a call to a User Agent (UA2), hosted by service provider=20 > SP2. The egress SIP server of SP1 is a SIP stateful Session Peering=20 ^^^^^^^^^ IMO we should not require the PeeringProxy to be stateful (btw:=20 transaction stateful or dialog stateful). [GKH] IMO the PeeringProxy (SBE as per the terminology draft) is stateful. It can be transaction stateful call stateless , or, call stateful aswell (like an SBC). So I was keeping it open to the Service Provider to choose what to deploy. What are your thoughts? > The figure below shows a high level SIP call flow setting up a SIP=20 > peering session between SP1 and SP2. All SIP signaling MUST go=20 > through the SPP1 and SPP2 as these are the ingress and egress points=20 > in SP1 and SP2 network.=20 > =20 > UA 1 SPP 1 DNS 1 DNS 2 SPP 2 UA 2=20 > | | | | | |=20 > |INVITE| | | | |=20 > |----->| | | | |=20 > | NAPTR Query | | |=20 > | |----->| | | |=20 > | NAPTR Response | | |=20 > | |<-----| | | |=20 > | SRV Query | | |=20 > | |----->| | | |=20 > | SRV+A Response | | |=20 > | |<-----| | | |=20 I wonder why you combine SRV+A in one response. This depends on the DNS=20 server. If you have a "simple" resolver, you have to ask for each record separate. If you have an "intelligent" resolver, you will get=20 NAPTR+SRV+A in the same response (if SRV+A are cached or responded by=20 the authoritative server). Further it depends if SPP1 does cache DNS too. The SIP proxies I know=20 will do 3 lookups (regardless if the additional section contains SRV and A or not) as they do not have a DNS cache. Thus, I suggest to either draw 3 lookups in the figure 1. NAPTR, 2. SRV, 3. A/AAAA or to draw only one lookup. [GKH] I agree having 3 lookups makes sense and stating that these lookups can be combined. > 3.1 TARGET Determination=20 > =20 > The target resource is identified with a SIP or SIPS URI. This is=20 > the URI in the Route header, if present, or the URI from the request=20 > URI of the SIP INVITE received by SPP1. =20 I would write "topmost Route header" just for clarification. [GKH] ACK.=20 > 3.2 NAPTR Lookup=20 I would add somewhere that NAPTR/SRV/A lookups must be skipped according to RFC 3263 [3] if transport/port/IP are already specified in the target URI. [GKH] ACK. > DNS MUST return at least three records - one with "SIP+D2T", one=20 > with "SIP+D2U" and one with "SIPS+D2T" service type for the case of > direct peering (section 4.3 in [6]). "SIPS+D2T" is not a MUST for=20 > indirect (transit) peering (section 4.4 in [6]) since domain validation=20 > as specified in section 26.3.2.2 of [1] for TLS at layer 5 will not work=20 > for indirect peering. This sounds like TLS can't be used in transit peering. I would like to=20 use TLS also in transit scenarios. IMO it would be better to remove=20 layer 5 certificate validation (section 26.3.2.2 of [1] ) than removing=20 TLS completely. [GKH] TLS cannot be used for transit peering for SIPS only, SIP over TLS is fine in transit peering case. =20 > 3.3 SRV Lookup=20 > =20 ... > Alternatively, if no NAPTR records are found, then SPP1 uses the=20 > preferred transport protocol and issues an SRV query for that=20 > specific transport using sips for SIPS URI and SIP URI with TLS and > sip for SIP URI.=20 IMO this sentence is not clear. What do you mean with "preferred=20 protocol"? Is the preferred protocol somewhere defined or is it the=20 preference of SP1? [GKH] Good point. I can make recommendation in this BCP to use TLS as preferred. What are your thoughts? Further I would write "_sips" instead of "sips" and "_sip" instead of=20 "sip" to make it clear that you mean the domain prefix for the SRV lookup. [GKH] Yes, that was a typo from our side. It should be the domain prefix for SRV.=20 > 3.4 Using SRV Results=20 > =20 > RFC 2782 describes the procedures on how to use and interpret the=20 > results obtained from the SRV query. The target entry of the SRV RRs=20 > is looked up by querying the DNS for address records. The SRV response=20 > from DNS MAY also include A records with it which will cut down on round Again - also the NAPTR lookup may already return the SRV and A record.=20 Having a additional section in the DNS response is not limited to the=20 SRV lookup. [GKH] Agree. Before I begin this section, I will mention that if A records are not known with SRV responses, then the following procedure would apply. > 4.1 SPP1 Fails to Reach SPP2=20 > =20 > A 503 error response is reported by the transaction layer, or failure=20 > can occur at the transport layer due to TCP disconnect in connection,=20 > ICMP error in UDP or time out at transport layer or SIP layer timeout=20 > when its not receiving any SIP response. In such situations, SPP1=20 > tries a new SIP request transaction to the next available server=20 > instance of SPP2 as determined by SRV RRs entry. =20 This is against RFC 3261 which says in case of 503 it should not send to an alternate server: 21.5.4 503 Service Unavailable ... A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. [GKH] 503 SHOULD work.=20 I further wonder about best practise for failover to another ingress=20 point of SP2. UDP timeout can take up to 32 seconds. TCP timeout depends on the OS. IMO this is quite long time for failover. 1. Should this be described in this draft or maybe in the callfows draft? [GKH] Since this is the BCP for use of DNS SRV we should make recommendations in this draft unless others have different views. 2. What would be a good value until trying the next server? 32 seconds=20 is too long. RFC 3261 allows redefinition of Timer T1. The default value is 500ms and should reflect the RTT to the next hop. Thus, if it is=20 knows that the RTT to the ingress point is 100ms, setting T1 to 100ms=20 allows faster failover (of course the Peering Proxy needs to support=20 setting of T1) [GKH] We can recommend T1 to be configurable on the SPP1 and recommend an upper limit value in this BCP ?=20 > 5. Caching/TTL=20 > =20 > SRV RRs have a TTL value based on which the SPP1 caches the entry for=20 > that duration and any further requests to the same TARGET domain are=20 > delivered to the cached server instance. The TTL recommended for SRV=20 This sounds like the SPP1 must cache DNS results. Usually applications=20 does not caches DNS as the caching is done by SP1's resolving name=20 server. IMO caching in the resolver must be fine too. [GKH] I agree its upto the SPP1 to cache DNS results or not. In the BCP I only wanted to recommend the values for TTL of SRV and NAPTR, when specified. So I will state that caching is not MUST in SPP. regards Klaus --=20 Klaus Darilion nic.at _______________________________________________ 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 From speermint-bounces@ietf.org Fri Oct 06 12:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVss5-0005uC-P8; Fri, 06 Oct 2006 12:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVss4-0005u6-VA for speermint@ietf.org; Fri, 06 Oct 2006 12:48:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVss4-0001y6-7s for speermint@ietf.org; Fri, 06 Oct 2006 12:48:24 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Basic Peering Requirements X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 6 Oct 2006 18:47:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbpWF23RpjfwRbXRrub/BLTotk7WgADa7yt References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> From: "Stastny Richard" To: "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So IMO the following should be replaced =20 > If a peer is providing connectivity to multiple federations, it should > disclose AoRs providing indirect peering relationships to servicing > peers or federations. by =20 "If a peer is providing connectivity to multiple federations, it should = disclose the entry points to be used for this purpose in SRV records at the = destination domains" =20 I still do not understand: =20 > A peer allowing another peer within a federation to provide indirect > peering on their behalf must select only one indirect peer to host = their > AoRs =20 Richard =20 =20 ________________________________ Von: Daryl Malas [mailto:daryl@level3.net] Gesendet: Fr 06.10.2006 17:04 An: Stastny Richard Cc: speermint@ietf.org Betreff: RE: [Speermint] Basic Peering Requirements On Fri, 2006-10-06 at 10:00 +0200, Stastny Richard wrote: > Questions for clarification: > > > If a peer is providing connectivity to multiple federations, it = should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > AoRs? - You mean entry points? Yes, my intention was to use it as described in RFC 3327. "Each incoming request targeted to the public address-of-record for the user is routed to this proxy..." The AoRs in this case are representing the public address-of-record for the indirect peered domain(s). I apologize if I used this term incorrectly, I felt it applied. I can changed the terminology if there is a problem with it. --Daryl > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host > their > > AoRs > > I do not understand. An AoR is defining the destination, > How can it be hosted be an indirect peer? > > Could you please explain > > Richard > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Friday, October 06, 2006 12:38 AM > > To: speermint@ietf.org > > Subject: [Speermint] Basic Peering Requirements > > > > I was asked at the interim meeting to put together a list of > base-level > > peering requirements by Jean-francois. I put together a list and > tried > > to send it to him, but I'm not sure it ever made it. In either = case, > I > > wanted to post it to the list, so the WG will have ample time to > pummel > > it before San Diego. ;-) > > > > = ---------------------------------------------------------------------- > > > > Jean-Francois, > > > > Per our conversation in Philadelphia, I have compiled a list of = basic > > peering requirements from one operators perspective. I can post = these > > to the list if you would like. Here is a list of peering = requirements > > (this is certainly not exhaustive, but is a platform): > > > > Transport (Layer 1 3): > > > > Peering must utilize IP as the primary mechanism for peering. > > > > A federation must agree upon a common mechanism for IP transport > either > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > (Net of this...most operators will peer with these methods today.) > > > > Billing: > > > > If peering services involve billing, the peers or federation must > agree > > on a common monetary policy. > > > > The peers or federation must agree on a common currency. > > > > (Net of this...some customers may abuse peering, and operators may > want > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > Leaches).) > > > > Policy: > > > > Policies may be implemented locally to the peer or via a centralized > > mechanism within the federation. > > > > Local policies should be disclosed when creating direct peering > > relationships with the applicable direct peer. > > > > Local policies may supersede centralized federation policies. > > > > (Net of this...some peering relationships will be 1:1, so policies > will > > likely be local only. Some peering relationships will be 1:N, so > > policies will likely be implemented within DNS or some centralized > > mechanism.) > > > > Membership: > > > > A peer may be a member of multiple federations > > > > A peer must maintain compliancy for policies as defined by each > > federation the peer is a member of. > > > > If a peer is providing connectivity to multiple federations, it = should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > > > Peers providing indirect peering must enforce federation policies on > > behalf of the destination federation. > > > > A peer providing indirect peering may enforce undisclosed policies = for > > processing session requests between federations. > > > > (Net of this...some peers will only desire to be part of a single > > federation, where wholesale carriers will likely be members of > multiple > > federations.) > > > > Media: > > > > Peers must agree on one or more CODECs, which is either negotiated > > directly or via a transcoding mechanism. > > > > A transcoding mechanism may exist locally or centralized within the > > federation. > > > > (Net of this...most operators only support a couple of CODECs across > the > > core of their network, but will transcode at the edge.) > > > > Routing: > > > > A peer must utilize the centralized federation routing mechanism if = it > > is available. > > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host > their > > AoRs. > > > > A peer must not copy routing information from or make assumed = routing > > choices on behalf of the centralized routing mechanism for use = locally > > unless it takes place through standard caching methods. > > > > A common API must be utilized and available for subscriber and route > > provisioning on any centralized federation location function. > > > > Subscriber and routing information must be dynamically updated as = soon > > as applicable for accurate routing within the federation. > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is = simple > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > more efficient method is absolutely necessary, in comes > ENUM/DNS/NAPTR. > > Unfortunately, both methods will likely be necessary until wider > spread > > adoption of DNS methods takes place.) > > > > Performance: > > > > Performance metrics must be shared between peers as they apply > directly > > to peering signaling and media on a consistent basis within the > > federation. > > > > (Net of this...this is just a reality otherwise; finger pointing = takes > > place anytime something breaks.) > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Fri Oct 06 17:56:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVxfc-0006uY-GX; Fri, 06 Oct 2006 17:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVxfb-0006uT-31 for speermint@ietf.org; Fri, 06 Oct 2006 17:55:51 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVxfZ-0000r5-KS for speermint@ietf.org; Fri, 06 Oct 2006 17:55:51 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k96LtcvQ014222; Fri, 6 Oct 2006 21:55:39 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Stastny Richard In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> Content-Type: text/plain Date: Fri, 06 Oct 2006 15:57:09 -0600 Message-Id: <1160171829.16895.59.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Fri, 2006-10-06 at 18:47 +0200, Stastny Richard wrote: > So IMO the following should be replaced > > > If a peer is providing connectivity to multiple federations, it should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > by > > "If a peer is providing connectivity to multiple federations, it should disclose > the entry points to be used for this purpose in SRV records at the destination > domains" > > I still do not understand: > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host their domains. This keeps from having multiple peers advertising within the SRV record IP addresses to the same indirect peering domain. If there is no requirement here, indirect peer X could be reached by peer A, B, C...etc. Every operator on the planet is potentially going to try and get their SF addresses (A records) as the first choice for indirect peer X. It will get out of hand to quickly. The SRV record would return multiple A IP addresses for the SF at A, B, C. This can create a lot of confusion and I am suggesting we create a requirement, which forces indirect peer X to only choose peer A's SF; or at most, 2 indirect peers, peer A and B, for example. This does not eliminate redundancy, as peer A can have multiple IP addresses to their SF. Sorry...I understand your hang up...just trying to use the correct words to communicate my thought here. > > AoRs > > Richard > > > > ________________________________ > > Von: Daryl Malas [mailto:daryl@level3.net] > Gesendet: Fr 06.10.2006 17:04 > An: Stastny Richard > Cc: speermint@ietf.org > Betreff: RE: [Speermint] Basic Peering Requirements > > > > On Fri, 2006-10-06 at 10:00 +0200, Stastny Richard wrote: > > Questions for clarification: > > > > > If a peer is providing connectivity to multiple federations, it should > > > disclose AoRs providing indirect peering relationships to servicing > > > peers or federations. > > > > AoRs? - You mean entry points? > Yes, my intention was to use it as described in RFC 3327. "Each > incoming request targeted to the public address-of-record for the user > is routed to this proxy..." The AoRs in this case are representing the > public address-of-record for the indirect peered domain(s). > > I apologize if I used this term incorrectly, I felt it applied. I can > changed the terminology if there is a problem with it. --Daryl > > > > > > A peer allowing another peer within a federation to provide indirect > > > peering on their behalf must select only one indirect peer to host > > their > > > AoRs > > > > I do not understand. An AoR is defining the destination, > > How can it be hosted be an indirect peer? > > > > Could you please explain > > > > Richard > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: Friday, October 06, 2006 12:38 AM > > > To: speermint@ietf.org > > > Subject: [Speermint] Basic Peering Requirements > > > > > > I was asked at the interim meeting to put together a list of > > base-level > > > peering requirements by Jean-francois. I put together a list and > > tried > > > to send it to him, but I'm not sure it ever made it. In either case, > > I > > > wanted to post it to the list, so the WG will have ample time to > > pummel > > > it before San Diego. ;-) > > > > > > ---------------------------------------------------------------------- > > > > > > Jean-Francois, > > > > > > Per our conversation in Philadelphia, I have compiled a list of basic > > > peering requirements from one operators perspective. I can post these > > > to the list if you would like. Here is a list of peering requirements > > > (this is certainly not exhaustive, but is a platform): > > > > > > Transport (Layer 1 3): > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > A federation must agree upon a common mechanism for IP transport > > either > > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > (Net of this...most operators will peer with these methods today.) > > > > > > Billing: > > > > > > If peering services involve billing, the peers or federation must > > agree > > > on a common monetary policy. > > > > > > The peers or federation must agree on a common currency. > > > > > > (Net of this...some customers may abuse peering, and operators may > > want > > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > > Leaches).) > > > > > > Policy: > > > > > > Policies may be implemented locally to the peer or via a centralized > > > mechanism within the federation. > > > > > > Local policies should be disclosed when creating direct peering > > > relationships with the applicable direct peer. > > > > > > Local policies may supersede centralized federation policies. > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > will > > > likely be local only. Some peering relationships will be 1:N, so > > > policies will likely be implemented within DNS or some centralized > > > mechanism.) > > > > > > Membership: > > > > > > A peer may be a member of multiple federations > > > > > > A peer must maintain compliancy for policies as defined by each > > > federation the peer is a member of. > > > > > > If a peer is providing connectivity to multiple federations, it should > > > disclose AoRs providing indirect peering relationships to servicing > > > peers or federations. > > > > > > Peers providing indirect peering must enforce federation policies on > > > behalf of the destination federation. > > > > > > A peer providing indirect peering may enforce undisclosed policies for > > > processing session requests between federations. > > > > > > (Net of this...some peers will only desire to be part of a single > > > federation, where wholesale carriers will likely be members of > > multiple > > > federations.) > > > > > > Media: > > > > > > Peers must agree on one or more CODECs, which is either negotiated > > > directly or via a transcoding mechanism. > > > > > > A transcoding mechanism may exist locally or centralized within the > > > federation. > > > > > > (Net of this...most operators only support a couple of CODECs across > > the > > > core of their network, but will transcode at the edge.) > > > > > > Routing: > > > > > > A peer must utilize the centralized federation routing mechanism if it > > > is available. > > > > > > A peer allowing another peer within a federation to provide indirect > > > peering on their behalf must select only one indirect peer to host > > their > > > AoRs. > > > > > > A peer must not copy routing information from or make assumed routing > > > choices on behalf of the centralized routing mechanism for use locally > > > unless it takes place through standard caching methods. > > > > > > A common API must be utilized and available for subscriber and route > > > provisioning on any centralized federation location function. > > > > > > Subscriber and routing information must be dynamically updated as soon > > > as applicable for accurate routing within the federation. > > > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > > more efficient method is absolutely necessary, in comes > > ENUM/DNS/NAPTR. > > > Unfortunately, both methods will likely be necessary until wider > > spread > > > adoption of DNS methods takes place.) > > > > > > Performance: > > > > > > Performance metrics must be shared between peers as they apply > > directly > > > to peering signaling and media on a consistent basis within the > > > federation. > > > > > > (Net of this...this is just a reality otherwise; finger pointing takes > > > place anytime something breaks.) > > > > > > > > > _______________________________________________ > > > 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 From speermint-bounces@ietf.org Mon Oct 09 12:27:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxx0-0002Jh-DK; Mon, 09 Oct 2006 12:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxwz-0002F5-75 for speermint@ietf.org; Mon, 09 Oct 2006 12:25:57 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxwx-00044f-PT for speermint@ietf.org; Mon, 09 Oct 2006 12:25:57 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id k99GPtXc017731 for ; Mon, 9 Oct 2006 09:25:55 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id k99GPtHf017729 for speermint@ietf.org; Mon, 9 Oct 2006 09:25:55 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 9 Oct 2006 09:25:55 -0700 From: David Meyer To: speermint@ietf.org Message-ID: <20061009162555.GA17708@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Internet-Drafts Submission Cutoff Dates for the 67th IETF Meeting in San Diego, California, USA] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1717029030==" Errors-To: speermint-bounces@ietf.org --===============1717029030== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from ietf-secretariat@ietf.org ----- > From: ietf-secretariat@ietf.org > To: ietf-announce@ietf.org > Cc:=20 > Subject: Internet-Drafts Submission Cutoff Dates for the 67th IETF=20 > Meeting in San Diego, California, USA=20 > Date: Mon, 09 Oct 2006 12:20:02 -0400 >=20 >=20 > There are two (2) Internet-Draft cutoff dates for the 67th=20 > IETF Meeting in San Diego, California, USA: >=20 > October 16th: Cutoff Date for Initial (i.e., version -00)=20 > Internet-Draft Submissions=20 >=20 > All initial Internet-Drafts (version -00) must be submitted by Monday,=20 > October 16th at 9:00 AM ET. As always, all initial submissions with a=20 > filename beginning with "draft-ietf" must be approved by the=20 > appropriate WG Chair before they can be processed or announced. The=20 > Secretariat would appreciate receiving WG Chair approval by Monday,=20 > October 9th at 9:00 AM ET. >=20 > October 23rd: Cutoff Date for Revised (i.e., version -01 and higher)=20 > Internet-Draft Submissions=20 >=20 > All revised Internet-Drafts (version -01 and higher) must be submitted=20 > by Monday, October 23rd at 9:00 AM ET. >=20 > Initial and revised Internet-Drafts received after their respective=20 > cutoff dates will not be made available in the Internet-Drafts=20 > directory or announced until on or after Monday, November 6th at 9:00=20 > AM ET, when Internet-Draft posting resumes. Please do not wait until=20 > the last minute to submit. >=20 > Thank you for your understanding and cooperation. If you have any=20 > questions or concerns, then please send a message to=20 > internet-drafts@ietf.org. >=20 > The IETF Secretariat >=20 > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 67th IETF Meeting can be found at http://www.ietf.org/meetings/cu= toff_dates_67.html. >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFKngTORgD1qCZ2KcRAt5UAJ9IFtoa9ylmFUMELAq4TkHFpj2zawCdGKPT 45H+vS9D8Klglaua5WZOudk= =xnG5 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- --===============1717029030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1717029030==-- From speermint-bounces@ietf.org Mon Oct 09 16:47:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX219-00046x-HM; Mon, 09 Oct 2006 16:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX217-00046q-Ig for speermint@ietf.org; Mon, 09 Oct 2006 16:46:29 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX217-0002Vj-37 for speermint@ietf.org; Mon, 09 Oct 2006 16:46:29 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k99KkMvQ028842; Mon, 9 Oct 2006 20:46:27 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Stastny Richard In-Reply-To: <1160171829.16895.59.camel@montag.eng.level3.com> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> Content-Type: text/plain Date: Mon, 09 Oct 2006 14:48:03 -0600 Message-Id: <1160426883.16895.64.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Here is a simple requirement I am suggesting here: A peer MUST specify the priority of all destination IP addresses associated with any indirect peering resources within a Federation. This includes A records associated with the peer's domain or IP addresses associated with a 300 Multiple Choices response. Does this make sense? Thanks...--Daryl On Fri, 2006-10-06 at 15:57 -0600, Daryl Malas wrote: > On Fri, 2006-10-06 at 18:47 +0200, Stastny Richard wrote: > > So IMO the following should be replaced > > > > > If a peer is providing connectivity to multiple federations, it should > > > disclose AoRs providing indirect peering relationships to servicing > > > peers or federations. > > by > > > > "If a peer is providing connectivity to multiple federations, it should disclose > > the entry points to be used for this purpose in SRV records at the destination > > domains" > > > > I still do not understand: > > > > > A peer allowing another peer within a federation to provide indirect > > > peering on their behalf must select only one indirect peer to host their > domains. This keeps from having multiple peers advertising within the > SRV record IP addresses to the same indirect peering domain. > > If there is no requirement here, indirect peer X could be reached by > peer A, B, C...etc. Every operator on the planet is potentially going > to try and get their SF addresses (A records) as the first choice for > indirect peer X. It will get out of hand to quickly. The SRV record > would return multiple A IP addresses for the SF at A, B, C. This can > create a lot of confusion and I am suggesting we create a requirement, > which forces indirect peer X to only choose peer A's SF; or at most, 2 > indirect peers, peer A and B, for example. This does not eliminate > redundancy, as peer A can have multiple IP addresses to their SF. > > Sorry...I understand your hang up...just trying to use the correct words > to communicate my thought here. > > > > AoRs > > > > Richard > > > > > > > > ________________________________ > > > > Von: Daryl Malas [mailto:daryl@level3.net] > > Gesendet: Fr 06.10.2006 17:04 > > An: Stastny Richard > > Cc: speermint@ietf.org > > Betreff: RE: [Speermint] Basic Peering Requirements > > > > > > > > On Fri, 2006-10-06 at 10:00 +0200, Stastny Richard wrote: > > > Questions for clarification: > > > > > > > If a peer is providing connectivity to multiple federations, it should > > > > disclose AoRs providing indirect peering relationships to servicing > > > > peers or federations. > > > > > > AoRs? - You mean entry points? > > Yes, my intention was to use it as described in RFC 3327. "Each > > incoming request targeted to the public address-of-record for the user > > is routed to this proxy..." The AoRs in this case are representing the > > public address-of-record for the indirect peered domain(s). > > > > I apologize if I used this term incorrectly, I felt it applied. I can > > changed the terminology if there is a problem with it. --Daryl > > > > > > > > > A peer allowing another peer within a federation to provide indirect > > > > peering on their behalf must select only one indirect peer to host > > > their > > > > AoRs > > > > > > I do not understand. An AoR is defining the destination, > > > How can it be hosted be an indirect peer? > > > > > > Could you please explain > > > > > > Richard > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: Friday, October 06, 2006 12:38 AM > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Basic Peering Requirements > > > > > > > > I was asked at the interim meeting to put together a list of > > > base-level > > > > peering requirements by Jean-francois. I put together a list and > > > tried > > > > to send it to him, but I'm not sure it ever made it. In either case, > > > I > > > > wanted to post it to the list, so the WG will have ample time to > > > pummel > > > > it before San Diego. ;-) > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Jean-Francois, > > > > > > > > Per our conversation in Philadelphia, I have compiled a list of basic > > > > peering requirements from one operators perspective. I can post these > > > > to the list if you would like. Here is a list of peering requirements > > > > (this is certainly not exhaustive, but is a platform): > > > > > > > > Transport (Layer 1 3): > > > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > > > A federation must agree upon a common mechanism for IP transport > > > either > > > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > > > (Net of this...most operators will peer with these methods today.) > > > > > > > > Billing: > > > > > > > > If peering services involve billing, the peers or federation must > > > agree > > > > on a common monetary policy. > > > > > > > > The peers or federation must agree on a common currency. > > > > > > > > (Net of this...some customers may abuse peering, and operators may > > > want > > > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > > > Leaches).) > > > > > > > > Policy: > > > > > > > > Policies may be implemented locally to the peer or via a centralized > > > > mechanism within the federation. > > > > > > > > Local policies should be disclosed when creating direct peering > > > > relationships with the applicable direct peer. > > > > > > > > Local policies may supersede centralized federation policies. > > > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > > will > > > > likely be local only. Some peering relationships will be 1:N, so > > > > policies will likely be implemented within DNS or some centralized > > > > mechanism.) > > > > > > > > Membership: > > > > > > > > A peer may be a member of multiple federations > > > > > > > > A peer must maintain compliancy for policies as defined by each > > > > federation the peer is a member of. > > > > > > > > If a peer is providing connectivity to multiple federations, it should > > > > disclose AoRs providing indirect peering relationships to servicing > > > > peers or federations. > > > > > > > > Peers providing indirect peering must enforce federation policies on > > > > behalf of the destination federation. > > > > > > > > A peer providing indirect peering may enforce undisclosed policies for > > > > processing session requests between federations. > > > > > > > > (Net of this...some peers will only desire to be part of a single > > > > federation, where wholesale carriers will likely be members of > > > multiple > > > > federations.) > > > > > > > > Media: > > > > > > > > Peers must agree on one or more CODECs, which is either negotiated > > > > directly or via a transcoding mechanism. > > > > > > > > A transcoding mechanism may exist locally or centralized within the > > > > federation. > > > > > > > > (Net of this...most operators only support a couple of CODECs across > > > the > > > > core of their network, but will transcode at the edge.) > > > > > > > > Routing: > > > > > > > > A peer must utilize the centralized federation routing mechanism if it > > > > is available. > > > > > > > > A peer allowing another peer within a federation to provide indirect > > > > peering on their behalf must select only one indirect peer to host > > > their > > > > AoRs. > > > > > > > > A peer must not copy routing information from or make assumed routing > > > > choices on behalf of the centralized routing mechanism for use locally > > > > unless it takes place through standard caching methods. > > > > > > > > A common API must be utilized and available for subscriber and route > > > > provisioning on any centralized federation location function. > > > > > > > > Subscriber and routing information must be dynamically updated as soon > > > > as applicable for accurate routing within the federation. > > > > > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > > > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > > > more efficient method is absolutely necessary, in comes > > > ENUM/DNS/NAPTR. > > > > Unfortunately, both methods will likely be necessary until wider > > > spread > > > > adoption of DNS methods takes place.) > > > > > > > > Performance: > > > > > > > > Performance metrics must be shared between peers as they apply > > > directly > > > > to peering signaling and media on a consistent basis within the > > > > federation. > > > > > > > > (Net of this...this is just a reality otherwise; finger pointing takes > > > > place anytime something breaks.) > > > > > > > > > > > > _______________________________________________ > > > > 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 From speermint-bounces@ietf.org Tue Oct 10 05:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDch-0004fC-K3; Tue, 10 Oct 2006 05:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXDcf-0004YH-Si for speermint@ietf.org; Tue, 10 Oct 2006 05:10:01 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXDce-0006SM-CW for speermint@ietf.org; Tue, 10 Oct 2006 05:10:01 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 57C1F21006C; Tue, 10 Oct 2006 11:09:45 +0200 (CEST) Message-ID: <452B6358.1090708@pernau.at> Date: Tue, 10 Oct 2006 11:09:44 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Khandpur, Gaurav" Subject: Re: [Speermint] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01 References: <45AEC6EF95942140888406588E1A660217DBB5@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660217DBB5@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Khandpur, Gaurav wrote: >> 3. Session Peering Setup >> >> SIP systems are represented by user agents (UA). In the diagram >> below, a user agent (UA1), hosted by a service provider SP1, >> initiates a call to a User Agent (UA2), hosted by service provider >> SP2. The egress SIP server of SP1 is a SIP stateful Session > Peering > > ^^^^^^^^^ > IMO we should not require the PeeringProxy to be stateful (btw: > transaction stateful or dialog stateful). > > [GKH] IMO the PeeringProxy (SBE as per the terminology draft) is > stateful. It can be transaction stateful call stateless , or, call > stateful aswell (like an SBC). So I was keeping it open to the Service > Provider to choose what to deploy. What are your thoughts? IMO using a stateless or stateful peering proxy is a design decision of the VSP and this should not be mandated by an RFC. >> DNS MUST return at least three records - one with "SIP+D2T", one >> with "SIP+D2U" and one with "SIPS+D2T" service type for the case of > >> direct peering (section 4.3 in [6]). "SIPS+D2T" is not a MUST for >> indirect (transit) peering (section 4.4 in [6]) since domain > validation >> as specified in section 26.3.2.2 of [1] for TLS at layer 5 will not > work >> for indirect peering. > > This sounds like TLS can't be used in transit peering. I would like to > use TLS also in transit scenarios. IMO it would be better to remove > layer 5 certificate validation (section 26.3.2.2 of [1] ) than removing > TLS completely. > > [GKH] TLS cannot be used for transit peering for SIPS only, SIP over TLS > is fine in transit peering case. Yes, but SIP over TLS also uses NAPTR service type "SIPS+D2T". Thus for NAPTR lookups SIPS and SIP over TLS are identically. > >> 3.3 SRV Lookup >> > ... >> Alternatively, if no NAPTR records are found, then SPP1 uses the >> preferred transport protocol and issues an SRV query for that >> specific transport using sips for SIPS URI and SIP URI with TLS and > >> sip for SIP URI. > > IMO this sentence is not clear. What do you mean with "preferred > protocol"? Is the preferred protocol somewhere defined or is it the > preference of SP1? > > [GKH] Good point. I can make recommendation in this BCP to use TLS as > preferred. What are your thoughts? Yes, TLS preferred is fine with me. > > Further I would write "_sips" instead of "sips" and "_sip" instead of > "sip" to make it clear that you mean the domain prefix for the SRV > lookup. > > [GKH] Yes, that was a typo from our side. It should be the domain prefix > for SRV. > >> 3.4 Using SRV Results >> >> RFC 2782 describes the procedures on how to use and interpret the >> results obtained from the SRV query. The target entry of the SRV > RRs >> is looked up by querying the DNS for address records. The SRV > response >> from DNS MAY also include A records with it which will cut down on > round > > Again - also the NAPTR lookup may already return the SRV and A record. > Having a additional section in the DNS response is not limited to the > SRV lookup. > > [GKH] Agree. Before I begin this section, I will mention that if A > records are not known with SRV responses, then the following procedure > would apply. > >> 4.1 SPP1 Fails to Reach SPP2 >> >> A 503 error response is reported by the transaction layer, or > failure >> can occur at the transport layer due to TCP disconnect in > connection, >> ICMP error in UDP or time out at transport layer or SIP layer > timeout >> when its not receiving any SIP response. In such situations, SPP1 >> tries a new SIP request transaction to the next available server >> instance of SPP2 as determined by SRV RRs entry. > > > This is against RFC 3261 which says in case of 503 it should not send to > > an alternate server: > > 21.5.4 503 Service Unavailable > ... > A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > attempt to forward the request to an alternate server. It SHOULD > NOT > forward any other requests to that server for the duration specified > in the Retry-After header field, if present. > > > [GKH] 503 SHOULD work. > > I further wonder about best practise for failover to another ingress > point of SP2. UDP timeout can take up to 32 seconds. TCP timeout depends > > on the OS. IMO this is quite long time for failover. > > 1. Should this be described in this draft or maybe in the callfows > draft? > > [GKH] Since this is the BCP for use of DNS SRV we should make > recommendations in this draft unless others have different views. > > 2. What would be a good value until trying the next server? 32 seconds > is too long. RFC 3261 allows redefinition of Timer T1. The default value > > is 500ms and should reflect the RTT to the next hop. Thus, if it is > knows that the RTT to the ingress point is 100ms, setting T1 to 100ms > allows faster failover (of course the Peering Proxy needs to support > setting of T1) > > [GKH] We can recommend T1 to be configurable on the SPP1 and recommend > an upper limit value in this BCP ? yes, thats fine. > >> 5. Caching/TTL >> >> SRV RRs have a TTL value based on which the SPP1 caches the entry > for >> that duration and any further requests to the same TARGET domain > are >> delivered to the cached server instance. The TTL recommended for > SRV > > This sounds like the SPP1 must cache DNS results. Usually applications > does not caches DNS as the caching is done by SP1's resolving name > server. IMO caching in the resolver must be fine too. > > [GKH] I agree its upto the SPP1 to cache DNS results or not. In the BCP > I only wanted to recommend the values for TTL of SRV and NAPTR, when > specified. So I will state that caching is not MUST in SPP. ACK. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 10 11:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJ88-00044v-DY; Tue, 10 Oct 2006 11:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJ87-00044a-CB for speermint@ietf.org; Tue, 10 Oct 2006 11:02:51 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJ86-0006l4-3b for speermint@ietf.org; Tue, 10 Oct 2006 11:02:51 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 31283210015; Tue, 10 Oct 2006 17:02:45 +0200 (CEST) Message-ID: <452BB615.2090707@pernau.at> Date: Tue, 10 Oct 2006 17:02:45 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Daryl Malas Subject: Re: [Speermint] Basic Peering Requirements References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <1160426883.16895.64.camel@montag.eng.level3.com> In-Reply-To: <1160426883.16895.64.camel@montag.eng.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Stastny Richard , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl Malas wrote: > Here is a simple requirement I am suggesting here: > > A peer MUST specify the priority of all destination IP addresses > associated with any indirect peering resources within a Federation. > This includes A records associated with the peer's domain or IP > addresses associated with a 300 Multiple Choices response. > > Does this make sense? Multiple A records can't have priorities. To me this does not sound like requirements, but already a design. What would be the requirement? I guess something like: "If a peer is not reachable directly, there should be means to identify a transit provider." regards klaus > > Thanks...--Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 10 12:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKlT-0007mD-S2; Tue, 10 Oct 2006 12:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXKlS-0007m3-RE for speermint@ietf.org; Tue, 10 Oct 2006 12:47:34 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXKlP-0005xf-G0 for speermint@ietf.org; Tue, 10 Oct 2006 12:47:34 -0400 Received: from [195.54.244.2] (account jim HELO [172.16.2.13]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTPSA id 80232; Tue, 10 Oct 2006 17:47:29 +0100 In-Reply-To: <452BB615.2090707@pernau.at> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <1160426883.16895.64.camel@montag.eng.level3.com> <452BB615.2090707@pernau.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <365419DC-9502-42B1-85D8-B47588684C96@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Speermint] Basic Peering Requirements Date: Tue, 10 Oct 2006 17:47:29 +0100 To: Klaus Darilion X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Stastny Richard , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 10, 2006, at 16:02, Klaus Darilion wrote: > Multiple A records can't have priorities. That's why DNS has the SRV record. :-) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 10 13:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLLQ-0000MM-1w; Tue, 10 Oct 2006 13:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLLO-0000MG-Ot for speermint@ietf.org; Tue, 10 Oct 2006 13:24:42 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXLLM-0004bh-Gz for speermint@ietf.org; Tue, 10 Oct 2006 13:24:42 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id EC29041F3; Tue, 10 Oct 2006 13:23:51 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 13:23:51 -0400 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] Basic Peering Requirements Date: Tue, 10 Oct 2006 13:23:50 -0400 Message-ID: In-Reply-To: <365419DC-9502-42B1-85D8-B47588684C96@rfc1035.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbsjBcpYpge1HiiRDmKCkifGbli4AAAY2yQ From: "Uzelac, Adam" To: "Jim Reid" , "Klaus Darilion" X-OriginalArrivalTime: 10 Oct 2006 17:23:51.0721 (UTC) FILETIME=[DAD0F190:01C6EC90] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Stastny Richard , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The requirement involves some insurance that a VSP, with multiple transit VSPs, maintain control of sessions being routing to it through the multiple paths. Something to that affect. I would like to think that this is a bit like stating the obvious, but one never knows. Ass-u-Me, etc, etc. Adam -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Tuesday, October 10, 2006 12:47 PM To: Klaus Darilion Cc: Stastny Richard; speermint@ietf.org Subject: Re: [Speermint] Basic Peering Requirements On Oct 10, 2006, at 16:02, Klaus Darilion wrote: > Multiple A records can't have priorities. That's why DNS has the SRV record. :-) _______________________________________________ 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 From speermint-bounces@ietf.org Thu Oct 12 12:49:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3is-0000nj-R1; Thu, 12 Oct 2006 12:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3ir-0000ic-JM for speermint@ietf.org; Thu, 12 Oct 2006 12:47:53 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY3iq-0004XW-9j for speermint@ietf.org; Thu, 12 Oct 2006 12:47:53 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9CGlovQ013750 for ; Thu, 12 Oct 2006 16:47:50 GMT Subject: [Speermint] Requirements "VoIP" From: Daryl Malas To: speermint@ietf.org Content-Type: text/plain Date: Thu, 12 Oct 2006 10:49:41 -0600 Message-Id: <1160671782.16895.72.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is just a nit, but I don't think we should include VoIP exclusively in the document. I am referring to the title and also within the abstract as examples. SIP can be used for more than VoIP, and I foresee SPEERMINT being used to peer for IM, Presence, Video, etc...utilizing SIP for these purposes. I suggest we generalize throughout the document by simply removing "VoIP" where it applies to the type of interconnection and peering. --Daryl _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 12 12:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3uA-0000iA-PW; Thu, 12 Oct 2006 12:59:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY3u9-0000hp-OH for speermint@ietf.org; Thu, 12 Oct 2006 12:59:33 -0400 Received: from mx1.veraznet.com ([198.87.49.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY3u6-0005Yy-CV for speermint@ietf.org; Thu, 12 Oct 2006 12:59:33 -0400 Received: from VRZUS-EX01.us.veraznetworks.com ([198.87.49.9]) by mx1.veraznet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 09:59:14 -0700 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] Requirements "VoIP" Date: Thu, 12 Oct 2006 09:59:14 -0700 Message-ID: <024B7EE5698ED946B650CCFFF7035A4F023534FA@VRZUS-EX01.us.veraznetworks.com> In-Reply-To: <1160671782.16895.72.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirements "VoIP" Thread-Index: AcbuHrrF+4P9OjCnTUOW915xNUzHKAAACqsA From: "Henry Peter" To: X-OriginalArrivalTime: 12 Oct 2006 16:59:14.0931 (UTC) FILETIME=[BF682C30:01C6EE1F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello Folks: I am a new member in the list. When I had read some of the drafts I was wondering on the same lines if the interconnection/peering could also include subscriptions and notifications between service providers that which can be federated as well. If not VoIP then would it be just federated/peered interaction? Thanks, Henry -----Original Message----- From: Daryl Malas [mailto:daryl@level3.net]=20 Sent: Thursday, October 12, 2006 9:50 AM To: speermint@ietf.org Subject: [Speermint] Requirements "VoIP" This is just a nit, but I don't think we should include VoIP exclusively in the document. I am referring to the title and also within the abstract as examples. SIP can be used for more than VoIP, and I foresee SPEERMINT being used to peer for IM, Presence, Video, etc...utilizing SIP for these purposes. I suggest we generalize throughout the document by simply removing "VoIP" where it applies to the type of interconnection and peering. --Daryl _______________________________________________ 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 From speermint-bounces@ietf.org Thu Oct 12 13:16:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY49h-00021j-9m; Thu, 12 Oct 2006 13:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY49g-00020k-8D for speermint@ietf.org; Thu, 12 Oct 2006 13:15:36 -0400 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY49e-0007Lb-Qg for speermint@ietf.org; Thu, 12 Oct 2006 13:15:36 -0400 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 122BF5684E for ; Thu, 12 Oct 2006 10:15:19 -0700 (PDT) (envelope-from spouliotte@nominum.com) Received: from [128.177.194.173] ([128.177.194.173]) (authenticated user spouliotte@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits)) for speermint@ietf.org; Thu, 12 Oct 2006 10:15:18 -0700 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 12 Oct 2006 10:15:49 -0700 Subject: Re: [Speermint] Requirements "VoIP" From: Shawn Pouliotte To: Message-ID: Thread-Topic: [Speermint] Requirements "VoIP" Thread-Index: AcbuIg/rTqp+RloVEdukGgAX8iZ51g== In-Reply-To: <1160671782.16895.72.camel@montag.eng.level3.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I agree with Daryl on that one. VoIP is just an early application. Shawn On 10/12/06 9:49 AM, "Daryl Malas" wrote: > This is just a nit, but I don't think we should include VoIP exclusively > in the document. I am referring to the title and also within the > abstract as examples. SIP can be used for more than VoIP, and I foresee > SPEERMINT being used to peer for IM, Presence, Video, etc...utilizing > SIP for these purposes. > > I suggest we generalize throughout the document by simply removing > "VoIP" where it applies to the type of interconnection and peering. > > --Daryl > > > _______________________________________________ > 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 From speermint-bounces@ietf.org Thu Oct 12 14:20:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY59a-0007wi-LD; Thu, 12 Oct 2006 14:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY59Z-0007wO-Jc for speermint@ietf.org; Thu, 12 Oct 2006 14:19:33 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY59Z-00063S-1V for speermint@ietf.org; Thu, 12 Oct 2006 14:19:33 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GY59S-0000Gy-2W; Thu, 12 Oct 2006 13:19:26 -0500 From: "Brian Rosen" To: "'Daryl Malas'" , "'Jean-Francois Mule'" Subject: RE: [Speermint] Basic Peering Requirements Date: Thu, 12 Oct 2006 14:19:27 -0400 Message-ID: <009901c6ee2a$f5b05910$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcbpWyPiNglEJvf1TFaLi5QSG+EXZwEzcx/Q In-Reply-To: <1160148186.16895.49.camel@montag.eng.level3.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I've been thinking about this thread and while there are some conversation starters here, I wonder how really relevant a lot of this is. Maybe "relevant" is the wrong word, but I mean how much time and effort (and words in a document) do we give it. Generally speaking, the IETF designs protocols. In this work, we are probably not going to do that, we're going to do "Best Current Practice" documents. In the IETF, those are mostly "how best do you use the protocols the IETF defined, for a specific task". Generally speaking, IETF documents don't describe what would be in a contract between peers or between a peer and a federation. It is all well and good, and in fact I enthusiastically agree that the resolution of the codec discussion is that "The federation defines a codec policy to which all peers must adhere which would include designation of one or more mandatory to deploy codec and/or local transcode capability for each supported media type (audio, video, text) so that all calls can successfully complete offer/answer exchange. Consideration should be given in specifying mandatory-to-deploy codecs to include at least one that has minimal degradation of signal fidelity when two transcodes are required to achieve actual end to end compatibility." But, is that all? I think so. So, yeah, we have to say that, but that is all we do, because the actual work is in a contract. In your list, I think most of the items have that characteristic. I'm expecting our BCP documents will cover all of the items you listed, but I think they are really tiny pieces of text, and amount to a description of what's in the contract. We need to spend more IETF time, and words, on the protocol mechanisms, and how they are used. That should be the bulk of our work. Brian > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Friday, October 06, 2006 11:23 AM > To: Jean-Francois Mule > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Okay, so everything in this list would be discussed during the > negotiation between 2 peers. The answers to these requirements or > discussion points might differ based on Operator; however, the same > basic requirements will likely need to be met. I apologize if I > duplicated any, which are already in the requirements document. I was > trying to think through the peering negotiation (business arrangement) > process, while detailing each of the sticking points along the way. > > To be specific, policies in this list are at a very basic level. Here's > the only list of policies I see being discussed at this time (feel free > to add or subtract as you feel necessary): > > 1. Only 'X' CODEC(s) will be supported into federation B or Peer A's > network. > 2. Only 'n' number of peering sessions will be allowed at any given > time. > 3. Peer A will only support these 'X' SIP headers and methods > (extensions) via peering requests (In other words an Operator may not > support Redirect in and out of a federation...it's simply an example.) > --This one brings up an interesting aspect. It might be noted a UAC > could send an OPTIONS message to a federation or peer to understand some > of these supported "aspects", but these will also likely be negotiated > up front. > > These can be enforced at the federation level or via local policies. > > --Daryl > > On Thu, 2006-10-05 at 21:45 -0600, Jean-Francois Mule wrote: > > Thanks for the follow-up Daryl. Posting to the list is always preferred > > as far as I am concerned, especially when I'm traveling. > > > > We discussed this during our interim meeting. To clarify the intent of > > such a list, the idea is to capture the list of things that may be > > discussed between 2 peers in the form of a template in an appendix of > > the requirement document. This suggestion was made by Tom Creighton. > > > > This proposal would help: > > 1. capture things that are out of scope outside the main > > requirement document, yet keep on being raised like billing, IP > > transport independency, federation membership or 'policies' > > 2. help put some context and possibly requirements for the > > federation text in draft-terminology-draft 6 and Otmar's > > I-D.lendl-domain-policy-ddds > > > > Jean-Francois. > > > > > -----Original Message----- > > > From: Daryl Malas [mailto:daryl@level3.net] > > > Sent: Thursday, October 05, 2006 4:38 PM > > > To: speermint@ietf.org > > > Subject: [Speermint] Basic Peering Requirements > > > > > > I was asked at the interim meeting to put together a list of base- > > > level > > > peering requirements by Jean-francois. I put together a list and > > > tried > > > to send it to him, but I'm not sure it ever made it. In either case, > > > I > > > wanted to post it to the list, so the WG will have ample time to > > > pummel > > > it before San Diego. ;-) > > > > > > ---------------------------------------------------------------------- > > > > > > Jean-Francois, > > > > > > Per our conversation in Philadelphia, I have compiled a list of basic > > > peering requirements from one operators perspective. I can post these > > > to the list if you would like. Here is a list of peering requirements > > > (this is certainly not exhaustive, but is a platform): > > > > > > Transport (Layer 1 3): > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > A federation must agree upon a common mechanism for IP transport > > > either > > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > (Net of this...most operators will peer with these methods today.) > > > > > > Billing: > > > > > > If peering services involve billing, the peers or federation must > > > agree > > > on a common monetary policy. > > > > > > The peers or federation must agree on a common currency. > > > > > > (Net of this...some customers may abuse peering, and operators may > > > want > > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > > Leaches).) > > > > > > Policy: > > > > > > Policies may be implemented locally to the peer or via a centralized > > > mechanism within the federation. > > > > > > Local policies should be disclosed when creating direct peering > > > relationships with the applicable direct peer. > > > > > > Local policies may supersede centralized federation policies. > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > > will > > > likely be local only. Some peering relationships will be 1:N, so > > > policies will likely be implemented within DNS or some centralized > > > mechanism.) > > > > > > Membership: > > > > > > A peer may be a member of multiple federations > > > > > > A peer must maintain compliancy for policies as defined by each > > > federation the peer is a member of. > > > > > > If a peer is providing connectivity to multiple federations, it should > > > disclose AoRs providing indirect peering relationships to servicing > > > peers or federations. > > > > > > Peers providing indirect peering must enforce federation policies on > > > behalf of the destination federation. > > > > > > A peer providing indirect peering may enforce undisclosed policies for > > > processing session requests between federations. > > > > > > (Net of this...some peers will only desire to be part of a single > > > federation, where wholesale carriers will likely be members of > > > multiple > > > federations.) > > > > > > Media: > > > > > > Peers must agree on one or more CODECs, which is either negotiated > > > directly or via a transcoding mechanism. > > > > > > A transcoding mechanism may exist locally or centralized within the > > > federation. > > > > > > (Net of this...most operators only support a couple of CODECs across > > > the > > > core of their network, but will transcode at the edge.) > > > > > > Routing: > > > > > > A peer must utilize the centralized federation routing mechanism if it > > > is available. > > > > > > A peer allowing another peer within a federation to provide indirect > > > peering on their behalf must select only one indirect peer to host > > > their > > > AoRs. > > > > > > A peer must not copy routing information from or make assumed routing > > > choices on behalf of the centralized routing mechanism for use locally > > > unless it takes place through standard caching methods. > > > > > > A common API must be utilized and available for subscriber and route > > > provisioning on any centralized federation location function. > > > > > > Subscriber and routing information must be dynamically updated as soon > > > as applicable for accurate routing within the federation. > > > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > > more efficient method is absolutely necessary, in comes > > ENUM/DNS/NAPTR. > > > Unfortunately, both methods will likely be necessary until wider > > > spread > > > adoption of DNS methods takes place.) > > > > > > Performance: > > > > > > Performance metrics must be shared between peers as they apply > > > directly > > > to peering signaling and media on a consistent basis within the > > > federation. > > > > > > (Net of this...this is just a reality otherwise; finger pointing takes > > > place anytime something breaks.) > > > > > > > > > _______________________________________________ > > > 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 From speermint-bounces@ietf.org Thu Oct 12 17:06:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7kJ-0003g9-II; Thu, 12 Oct 2006 17:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7kH-0003g1-Nc for speermint@ietf.org; Thu, 12 Oct 2006 17:05:37 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY7kH-0001eT-6N for speermint@ietf.org; Thu, 12 Oct 2006 17:05:37 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9CL5VvQ000042; Thu, 12 Oct 2006 21:05:31 GMT Subject: RE: [Speermint] Basic Peering Requirements From: Daryl Malas To: Brian Rosen In-Reply-To: <009901c6ee2a$f5b05910$640fa8c0@cis.neustar.com> References: <009901c6ee2a$f5b05910$640fa8c0@cis.neustar.com> Content-Type: text/plain Date: Thu, 12 Oct 2006 15:07:23 -0600 Message-Id: <1160687243.16895.80.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think the best use of this information is to help us keep our feet on the ground as we develop the protocol aspects of peering. As you remember in Philly (and, I'm just as guilty) we kept going off onto tangents of "nice-to-haves". We decided it was critical to stay focused on the core (basic) aspects of peering. This list was intended to be a start at identifying the basic framework of peering, which we must start by defining protocol aspects within. After this is completed, over time, extensions can be written identifying new innovative aspects of peering. This was my perception of the request... --Daryl On Thu, 2006-10-12 at 14:19 -0400, Brian Rosen wrote: > I've been thinking about this thread and while there are some conversation > starters here, I wonder how really relevant a lot of this is. Maybe > "relevant" is the wrong word, but I mean how much time and effort (and words > in a document) do we give it. > > Generally speaking, the IETF designs protocols. In this work, we are > probably not going to do that, we're going to do "Best Current Practice" > documents. In the IETF, those are mostly "how best do you use the protocols > the IETF defined, for a specific task". > > Generally speaking, IETF documents don't describe what would be in a > contract between peers or between a peer and a federation. It is all well > and good, and in fact I enthusiastically agree that the resolution of the > codec discussion is that "The federation defines a codec policy to which all > peers must adhere which would include designation of one or more mandatory > to deploy codec and/or local transcode capability for each supported media > type (audio, video, text) so that all calls can successfully complete > offer/answer exchange. Consideration should be given in specifying > mandatory-to-deploy codecs to include at least one that has minimal > degradation of signal fidelity when two transcodes are required to achieve > actual end to end compatibility." > > But, is that all? I think so. So, yeah, we have to say that, but that is > all we do, because the actual work is in a contract. > > In your list, I think most of the items have that characteristic. > > I'm expecting our BCP documents will cover all of the items you listed, but > I think they are really tiny pieces of text, and amount to a description of > what's in the contract. > > We need to spend more IETF time, and words, on the protocol mechanisms, and > how they are used. That should be the bulk of our work. > > Brian > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Friday, October 06, 2006 11:23 AM > > To: Jean-Francois Mule > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > Okay, so everything in this list would be discussed during the > > negotiation between 2 peers. The answers to these requirements or > > discussion points might differ based on Operator; however, the same > > basic requirements will likely need to be met. I apologize if I > > duplicated any, which are already in the requirements document. I was > > trying to think through the peering negotiation (business arrangement) > > process, while detailing each of the sticking points along the way. > > > > To be specific, policies in this list are at a very basic level. Here's > > the only list of policies I see being discussed at this time (feel free > > to add or subtract as you feel necessary): > > > > 1. Only 'X' CODEC(s) will be supported into federation B or Peer A's > > network. > > 2. Only 'n' number of peering sessions will be allowed at any given > > time. > > 3. Peer A will only support these 'X' SIP headers and methods > > (extensions) via peering requests (In other words an Operator may not > > support Redirect in and out of a federation...it's simply an example.) > > --This one brings up an interesting aspect. It might be noted a UAC > > could send an OPTIONS message to a federation or peer to understand some > > of these supported "aspects", but these will also likely be negotiated > > up front. > > > > These can be enforced at the federation level or via local policies. > > > > --Daryl > > > > On Thu, 2006-10-05 at 21:45 -0600, Jean-Francois Mule wrote: > > > Thanks for the follow-up Daryl. Posting to the list is always preferred > > > as far as I am concerned, especially when I'm traveling. > > > > > > We discussed this during our interim meeting. To clarify the intent of > > > such a list, the idea is to capture the list of things that may be > > > discussed between 2 peers in the form of a template in an appendix of > > > the requirement document. This suggestion was made by Tom Creighton. > > > > > > This proposal would help: > > > 1. capture things that are out of scope outside the main > > > requirement document, yet keep on being raised like billing, IP > > > transport independency, federation membership or 'policies' > > > 2. help put some context and possibly requirements for the > > > federation text in draft-terminology-draft 6 and Otmar's > > > I-D.lendl-domain-policy-ddds > > > > > > Jean-Francois. > > > > > > > -----Original Message----- > > > > From: Daryl Malas [mailto:daryl@level3.net] > > > > Sent: Thursday, October 05, 2006 4:38 PM > > > > To: speermint@ietf.org > > > > Subject: [Speermint] Basic Peering Requirements > > > > > > > > I was asked at the interim meeting to put together a list of base- > > > > level > > > > peering requirements by Jean-francois. I put together a list and > > > > tried > > > > to send it to him, but I'm not sure it ever made it. In either case, > > > > I > > > > wanted to post it to the list, so the WG will have ample time to > > > > pummel > > > > it before San Diego. ;-) > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Jean-Francois, > > > > > > > > Per our conversation in Philadelphia, I have compiled a list of basic > > > > peering requirements from one operators perspective. I can post these > > > > to the list if you would like. Here is a list of peering requirements > > > > (this is certainly not exhaustive, but is a platform): > > > > > > > > Transport (Layer 1 3): > > > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > > > A federation must agree upon a common mechanism for IP transport > > > > either > > > > private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > > > (Net of this...most operators will peer with these methods today.) > > > > > > > > Billing: > > > > > > > > If peering services involve billing, the peers or federation must > > > > agree > > > > on a common monetary policy. > > > > > > > > The peers or federation must agree on a common currency. > > > > > > > > (Net of this...some customers may abuse peering, and operators may > > > > want > > > > to bill for certain traffic pattern types (e.g. Layer 3 IP Peering > > > > Leaches).) > > > > > > > > Policy: > > > > > > > > Policies may be implemented locally to the peer or via a centralized > > > > mechanism within the federation. > > > > > > > > Local policies should be disclosed when creating direct peering > > > > relationships with the applicable direct peer. > > > > > > > > Local policies may supersede centralized federation policies. > > > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > > > will > > > > likely be local only. Some peering relationships will be 1:N, so > > > > policies will likely be implemented within DNS or some centralized > > > > mechanism.) > > > > > > > > Membership: > > > > > > > > A peer may be a member of multiple federations > > > > > > > > A peer must maintain compliancy for policies as defined by each > > > > federation the peer is a member of. > > > > > > > > If a peer is providing connectivity to multiple federations, it should > > > > disclose AoRs providing indirect peering relationships to servicing > > > > peers or federations. > > > > > > > > Peers providing indirect peering must enforce federation policies on > > > > behalf of the destination federation. > > > > > > > > A peer providing indirect peering may enforce undisclosed policies for > > > > processing session requests between federations. > > > > > > > > (Net of this...some peers will only desire to be part of a single > > > > federation, where wholesale carriers will likely be members of > > > > multiple > > > > federations.) > > > > > > > > Media: > > > > > > > > Peers must agree on one or more CODECs, which is either negotiated > > > > directly or via a transcoding mechanism. > > > > > > > > A transcoding mechanism may exist locally or centralized within the > > > > federation. > > > > > > > > (Net of this...most operators only support a couple of CODECs across > > > > the > > > > core of their network, but will transcode at the edge.) > > > > > > > > Routing: > > > > > > > > A peer must utilize the centralized federation routing mechanism if it > > > > is available. > > > > > > > > A peer allowing another peer within a federation to provide indirect > > > > peering on their behalf must select only one indirect peer to host > > > > their > > > > AoRs. > > > > > > > > A peer must not copy routing information from or make assumed routing > > > > choices on behalf of the centralized routing mechanism for use locally > > > > unless it takes place through standard caching methods. > > > > > > > > A common API must be utilized and available for subscriber and route > > > > provisioning on any centralized federation location function. > > > > > > > > Subscriber and routing information must be dynamically updated as soon > > > > as applicable for accurate routing within the federation. > > > > > > > > (Net of this...In small peering (e.g. 1:1), a REDIRECT model is simple > > > > and not too inefficient. In a larger peering scenario (e.g. 1:N), a > > > > more efficient method is absolutely necessary, in comes > > > ENUM/DNS/NAPTR. > > > > Unfortunately, both methods will likely be necessary until wider > > > > spread > > > > adoption of DNS methods takes place.) > > > > > > > > Performance: > > > > > > > > Performance metrics must be shared between peers as they apply > > > > directly > > > > to peering signaling and media on a consistent basis within the > > > > federation. > > > > > > > > (Net of this...this is just a reality otherwise; finger pointing takes > > > > place anytime something breaks.) > > > > > > > > > > > > _______________________________________________ > > > > 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 From speermint-bounces@ietf.org Thu Oct 12 18:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9Kv-0008PY-2v; Thu, 12 Oct 2006 18:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9Kt-0008Ny-VI for speermint@ietf.org; Thu, 12 Oct 2006 18:47:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY9Ks-0004DI-MQ for speermint@ietf.org; Thu, 12 Oct 2006 18:47:31 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Oct 2006 15:47:31 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CMlU4O025916; Thu, 12 Oct 2006 18:47:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9CMlUYJ010299; Thu, 12 Oct 2006 18:47:30 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 18:47:30 -0400 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] Requirements "VoIP" Date: Thu, 12 Oct 2006 18:47:28 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3020C155B@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirements "VoIP" Thread-Index: AcbuHsn9YN/EQxvIT16/G2E2k2FTsQAMYvYA From: "Michael Hammer \(mhammer\)" To: "Daryl Malas" , X-OriginalArrivalTime: 12 Oct 2006 22:47:30.0102 (UTC) FILETIME=[65E63D60:01C6EE50] DKIM-Signature: a=rsa-sha1; q=dns; l=950; t=1160693250; x=1161557250; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Requirements=20=22VoIP=22 |To:=22Daryl=20Malas=22=20,=20; X=v=3Dcisco.com=3B=20h=3DWvKHBqJQoRqBNxCGEh+H9aOUnSA=3D; b=rW6C+oPp/N1D22K/oY+akmnZMa2LSGy0CZMzSMkZiA7vLwcb9ZH7R+n44OOYeZU56v0NgOAO EF/67x9OwWC4vixsUfpbut1SUNjCkP9qEfzMwbw6KYOkbdt5HQBYZwle; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In general agree. But we may then need a term like MMSP. Mike =20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Thursday, October 12, 2006 12:50 PM > To: speermint@ietf.org > Subject: [Speermint] Requirements "VoIP" >=20 > This is just a nit, but I don't think we should include VoIP=20 > exclusively in the document. I am referring to the title and=20 > also within the abstract as examples. SIP can be used for=20 > more than VoIP, and I foresee SPEERMINT being used to peer=20 > for IM, Presence, Video, etc...utilizing SIP for these purposes. >=20 > I suggest we generalize throughout the document by simply=20 > removing "VoIP" where it applies to the type of=20 > interconnection and peering. >=20 > --Daryl >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 12 18:48:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9Lj-000093-8x; Thu, 12 Oct 2006 18:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9Li-00008x-18 for speermint@ietf.org; Thu, 12 Oct 2006 18:48:22 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY9Lg-0004JC-Mw for speermint@ietf.org; Thu, 12 Oct 2006 18:48:22 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9CMmJxM024286; Thu, 12 Oct 2006 16:48:19 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Requirements "VoIP" Date: Thu, 12 Oct 2006 16:48:19 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirements "VoIP" Thread-Index: AcbuHrgO4UJeoAhaQQOSeZWJ3v2KYQAMJiyA From: "Jean-Francois Mule" To: "Daryl Malas" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Daryl and all, We discussed this at least twice before, at IETF66 and at the interim. In short, it can be summarized as: "focus first, then zoom out to get the full landscape in the picture". My recollection of the overall recommendations from the wg were:=20 a) keep both generic and VoIP-specific requirements in one doc (refer to the scope questions raised in IETF66) b) keep it focused on VoIP for the minimum set of requirements initially as it provides a concrete app for which we have use cases and because that is what the charter says c) expand and update terminology used in the requirements draft based on use cases (Avshalom volunteered to do one) Per Jon's comments at the interim meeting, we should get into more detailed requirements before looking at other apps. That's my personal preference too. Jean-Francois. > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thursday, October 12, 2006 10:50 AM > To: speermint@ietf.org > Subject: [Speermint] Requirements "VoIP" >=20 > This is just a nit, but I don't think we should include VoIP > exclusively > in the document. I am referring to the title and also within the > abstract as examples. SIP can be used for more than VoIP, and I > foresee > SPEERMINT being used to peer for IM, Presence, Video, etc...utilizing > SIP for these purposes. >=20 > I suggest we generalize throughout the document by simply removing > "VoIP" where it applies to the type of interconnection and peering. >=20 > --Daryl >=20 >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Thu Oct 12 19:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9eK-0005Mv-8u; Thu, 12 Oct 2006 19:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9dM-0004d0-Fd for speermint@ietf.org; Thu, 12 Oct 2006 19:06:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY9P2-0004t4-Qp for speermint@ietf.org; Thu, 12 Oct 2006 18:51:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Oct 2006 18:51:49 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9CMpmwP016616; Thu, 12 Oct 2006 18:51:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9CMpmYJ011344; Thu, 12 Oct 2006 18:51:48 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 18:51:48 -0400 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] Requirements "VoIP" Date: Thu, 12 Oct 2006 18:51:47 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3020C155E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirements "VoIP" Thread-Index: AcbuHrrF+4P9OjCnTUOW915xNUzHKAAACqsAAAyDABA= From: "Michael Hammer \(mhammer\)" To: "Henry Peter" , X-OriginalArrivalTime: 12 Oct 2006 22:51:48.0109 (UTC) FILETIME=[FFAEFBD0:01C6EE50] DKIM-Signature: a=rsa-sha1; q=dns; l=1731; t=1160693508; x=1161557508; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Requirements=20=22VoIP=22 |To:=22Henry=20Peter=22=20,=20; X=v=3Dcisco.com=3B=20h=3DWvKHBqJQoRqBNxCGEh+H9aOUnSA=3D; b=KW7DY6xRIgW02zCPr3TWcHoPyk2yky4jispKu8V8DeP8BmTr8AI3vNP45QaYYw/ZO5Gn5qQD Lno/DE2Oe2XeaaDutho21Im++esrKxIKtidpjLTURX7FVZ+mhUwOLl1c; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org We were thinking about that for the Policy exchange function. Mike =20 > -----Original Message----- > From: Henry Peter [mailto:HPeter@veraznet.com]=20 > Sent: Thursday, October 12, 2006 12:59 PM > To: speermint@ietf.org > Subject: RE: [Speermint] Requirements "VoIP" >=20 > Hello Folks: >=20 > I am a new member in the list. When I had read some of the=20 > drafts I was wondering on the same lines if the=20 > interconnection/peering could also include subscriptions and=20 > notifications between service providers that which can be=20 > federated as well. If not VoIP then would it be just=20 > federated/peered interaction? >=20 > Thanks, >=20 > Henry >=20 >=20 >=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thursday, October 12, 2006 9:50 AM > To: speermint@ietf.org > Subject: [Speermint] Requirements "VoIP" >=20 > This is just a nit, but I don't think we should include VoIP=20 > exclusively in the document. I am referring to the title and=20 > also within the abstract as examples. SIP can be used for=20 > more than VoIP, and I foresee SPEERMINT being used to peer=20 > for IM, Presence, Video, etc...utilizing SIP for these purposes. >=20 > I suggest we generalize throughout the document by simply=20 > removing "VoIP" where it applies to the type of=20 > interconnection and peering. >=20 > --Daryl >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 13 04:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYIAv-0001UU-8Q; Fri, 13 Oct 2006 04:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYIAo-0001NH-9l for speermint@ietf.org; Fri, 13 Oct 2006 04:13:42 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYI1Q-0007MP-Rq for speermint@ietf.org; Fri, 13 Oct 2006 04:04:02 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 804961A362; Fri, 13 Oct 2006 10:03:59 +0200 (CEST) Date: Fri, 13 Oct 2006 10:03:59 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061013080359.GG19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org, Daryl Malas References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160171829.16895.59.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/06 23:10, Daryl Malas wrote: > > If there is no requirement here, indirect peer X could be reached by > peer A, B, C...etc. Every operator on the planet is potentially going > to try and get their SF addresses (A records) as the first choice for > indirect peer X. It will get out of hand to quickly. The SRV record > would return multiple A IP addresses for the SF at A, B, C. This can > create a lot of confusion and I am suggesting we create a requirement, > which forces indirect peer X to only choose peer A's SF; or at most, 2 > indirect peers, peer A and B, for example. This does not eliminate > redundancy, as peer A can have multiple IP addresses to their SF. I have strong doubts that the existing SRV/A record scheme can be used in a situation where there are multiple routes over competing service providers. SRV/A already has serious problems as DNS answers are (unless you play dangerous tricks) independent on who's asking. In other words, even for simple direct peerings, the SRV/A records cannot be used to direct different peers to different ingress points into your network. (Yes, you could play around with DNS views or private DNS trees, but that's just applying band-aid to a design choice.) Overloading that already strained facility with routing information for indirect peering is IMHO a recipe for desaster. You don't get clear semantics (Is this indirect peering or just a different border element of the destination?), no clear routing preferences (How to you specify "for guys in europe, please route via X. For SPs in Asia, please route calls to me via Y"?), and no way of extending the transit case to more than one intermediary. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 13 05:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYJKw-0006X0-Ci; Fri, 13 Oct 2006 05:28:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYJKv-0006Wv-U0 for speermint@ietf.org; Fri, 13 Oct 2006 05:28:13 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYJKu-0006aX-JH for speermint@ietf.org; Fri, 13 Oct 2006 05:28:13 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 80538; Fri, 13 Oct 2006 09:57:40 +0100 In-Reply-To: <20061013080359.GG19113@nic.at> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <20061013080359.GG19113@nic.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5551409D-BA5C-464C-B95C-1A9898A6441C@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Speermint] Basic Peering Requirements Date: Fri, 13 Oct 2006 09:57:38 +0100 To: Otmar Lendl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 13, 2006, at 09:03, Otmar Lendl wrote: > SRV/A already has serious problems as DNS answers are (unless you play > dangerous tricks) independent on who's asking. In other words, even > for > simple direct peerings, the SRV/A records cannot be used to direct > different peers to different ingress points into your network. Indeed. Even if someone plays these tricks with the DNS, they won't work. That's because the thing making the query isn't usually the end client. There's usually a cacheing name server between the edge device and the authoritative name server. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 13 13:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQRh-0006Lh-Up; Fri, 13 Oct 2006 13:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQRf-0006LX-Vz for speermint@ietf.org; Fri, 13 Oct 2006 13:03:39 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYQRb-0005b2-Kq for speermint@ietf.org; Fri, 13 Oct 2006 13:03:39 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9DH3WvQ016617; Fri, 13 Oct 2006 17:03:33 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Otmar Lendl In-Reply-To: <20061013080359.GG19113@nic.at> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <20061013080359.GG19113@nic.at> Content-Type: text/plain Date: Fri, 13 Oct 2006 11:05:27 -0600 Message-Id: <1160759128.16895.87.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks guys...you know far more about DNS than I do. From experiences way....back, I thought there was a way to respond to a DNS query with a prioritized list of IP addresses associated with a domain. So, I was asking if a requirement should be necessary to restrict WHO can change that prioritization (if it exists). On Fri, 2006-10-13 at 10:03 +0200, Otmar Lendl wrote: > On 2006/10/06 23:10, Daryl Malas wrote: > > > > If there is no requirement here, indirect peer X could be reached by > > peer A, B, C...etc. Every operator on the planet is potentially going > > to try and get their SF addresses (A records) as the first choice for > > indirect peer X. It will get out of hand to quickly. The SRV record > > would return multiple A IP addresses for the SF at A, B, C. This can > > create a lot of confusion and I am suggesting we create a requirement, > > which forces indirect peer X to only choose peer A's SF; or at most, 2 > > indirect peers, peer A and B, for example. This does not eliminate > > redundancy, as peer A can have multiple IP addresses to their SF. > > I have strong doubts that the existing SRV/A record scheme can be > used in a situation where there are multiple routes over competing > service providers. > > SRV/A already has serious problems as DNS answers are (unless you play > dangerous tricks) independent on who's asking. In other words, even for > simple direct peerings, the SRV/A records cannot be used to direct > different peers to different ingress points into your network. > > (Yes, you could play around with DNS views or private DNS trees, but > that's just applying band-aid to a design choice.) > > Overloading that already strained facility with routing information for > indirect peering is IMHO a recipe for desaster. You don't get clear > semantics (Is this indirect peering or just a different border element > of the destination?), no clear routing preferences (How to you specify > "for guys in europe, please route via X. For SPs in Asia, please route > calls to me via Y"?), and no way of extending the transit case to > more than one intermediary. > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Oct 15 19:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZFA0-0001p2-O5; Sun, 15 Oct 2006 19:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZF9y-0001ov-Si for speermint@ietf.org; Sun, 15 Oct 2006 19:12:46 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZF9t-0003Xm-Kq for speermint@ietf.org; Sun, 15 Oct 2006 19:12:46 -0400 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.25493071; Sun, 15 Oct 2006 19:12:21 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 19:12:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Oct 2006 19:12:21 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602277A19@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lee-speermint-use-case-cable-01.txt Thread-Index: AcbwrdbuIwXseGwPQlCef7cG6D+mYw== From: "Lee, Yiu" To: X-OriginalArrivalTime: 15 Oct 2006 23:12:21.0826 (UTC) FILETIME=[5E468220:01C6F0AF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Speermint] draft-lee-speermint-use-case-cable-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1791735835==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1791735835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F0AF.5E221B69" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F0AF.5E221B69 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I got some useful comments for the draft and incorporated them in the version 01. The high-lights are: 1. Updated the terminology according to the terminology's draft. 2. Added a paragraph to include the need to sync-up the ENUM and DNS data between peers. 3. Added TLS is a must to implement but optionally to use. 4. Added some words to describe fall-back mechanism if ENUM lookup fails. 5. Added a section to discuss NP for peering. http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg12031.html ------_=_NextPart_001_01C6F0AF.5E221B69 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-lee-speermint-use-case-cable-01.txt

I got some useful comments for the = draft and incorporated them in the version 01. The high-lights = are:

1. Updated the terminology according to = the terminology's draft.
2. Added a paragraph to include the = need to sync-up the ENUM and DNS data between peers.
3. Added TLS is a must to implement = but optionally to use.
4. Added some words to describe = fall-back mechanism if ENUM lookup fails.
5. Added a section to discuss NP for = peering.

http://www1.ietf.org/mail-archive/web/i-d-announce/current= /msg12031.html


------_=_NextPart_001_01C6F0AF.5E221B69-- --===============1791735835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1791735835==-- From speermint-bounces@ietf.org Mon Oct 16 06:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPUt-0001KM-K0; Mon, 16 Oct 2006 06:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPUt-0001Jn-3T for speermint@ietf.org; Mon, 16 Oct 2006 06:15:03 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPUq-0004W9-Pp for speermint@ietf.org; Mon, 16 Oct 2006 06:15:03 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9GAEwYA007423; Mon, 16 Oct 2006 04:14:58 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Mon, 16 Oct 2006 04:14:58 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbA= From: "Jean-Francois Mule" To: "Brian Rosen" , "Daryl Malas" , "David Schwartz" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Here is my read of the thread on the 'policy' definition: "In the context of session peering, a policy is defined as the set of parameters and other information needed by one VSP to connect to another. A policy may be agreed to by Peers, or specified by some explicit protocol mechanism, or defined by a contract in a Federation. A policy is typically applicable to multiple sessions: it is not a per-call specific." Notes: - VSP or VSP/ASP to re-use the ecrit terminology in order to integrate other types of session peering per the comments that this should not be voice-specific; - it incorporates the comments received on the fact that how a policy is agreed to, or specify by is open to various models (Daryl's "agreed to by Peers" and Richard's comment on the fact that the reference to federation in this definition is not needed) - it does not prevent a VSP from including endpoint-related parameters as long as those are representing what the VSP think is required to 'connect' (per David's question) Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 08:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRZj-0007He-Dy; Mon, 16 Oct 2006 08:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRZi-0007DY-43 for speermint@ietf.org; Mon, 16 Oct 2006 08:28:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZRZe-0005WP-Px for speermint@ietf.org; Mon, 16 Oct 2006 08:28:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GZRZW-0001Ba-3R; Mon, 16 Oct 2006 07:27:58 -0500 From: "Brian Rosen" To: "'Jean-Francois Mule'" , "'Daryl Malas'" , "'David Schwartz'" Subject: RE: [Speermint] Policy Definition Date: Mon, 16 Oct 2006 08:27:58 -0400 Message-ID: <007f01c6f11e$859168d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYA== In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org While I think this definition is good, I think it is not sufficient. I think we need to break policy up into several buckets and give each a name. There is policy expressed statically (possibly by a contract, a web page, or some other thing that is human understandable). There is policy that has to do with addressing and routing, such as which federations it belongs to or which transit networks it connects to, or what ingress gateways it uses. There is dynamically discoverable policy that governs things beyond addressing. At any point in time, or maybe variable with federations, the this and static policy may have the same items in them, that is, we may start with, say, a static policy on how many calls per second we accept, and later come up with an automated way to discover it. I propose: "static policy" "addressing (or routing) policy" and "dynamic policy" Brian > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Monday, October 16, 2006 6:15 AM > To: Brian Rosen; Daryl Malas; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition > > > Here is my read of the thread on the 'policy' definition: > "In the context of session peering, a policy is defined as the set of > parameters and other information needed by one VSP to connect to > another. A policy may be agreed to by Peers, or specified by some > explicit protocol mechanism, or defined by a contract in a Federation. A > policy is typically applicable to multiple sessions: it is not a > per-call specific." > > Notes: > - VSP or VSP/ASP to re-use the ecrit terminology in order to > integrate other types of session peering per the comments that this > should not be voice-specific; > - it incorporates the comments received on the fact that how a > policy is agreed to, or specify by is open to various models (Daryl's > "agreed to by Peers" and Richard's comment on the fact that the > reference to federation in this definition is not needed) > - it does not prevent a VSP from including endpoint-related > parameters as long as those are representing what the VSP think is > required to 'connect' (per David's question) > > Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 11:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUWb-0000Jo-VJ; Mon, 16 Oct 2006 11:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUWa-0000Jj-MY for speermint@ietf.org; Mon, 16 Oct 2006 11:37:08 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUWW-0003H3-8n for speermint@ietf.org; Mon, 16 Oct 2006 11:37:08 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9GFav1K009847; Mon, 16 Oct 2006 09:36:58 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Basic Peering Requirements Date: Mon, 16 Oct 2006 09:36:57 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbpWyPiNglEJvf1TFaLi5QSG+EXZwEzcx/QAMOmC3A= From: "Jean-Francois Mule" To: "Brian Rosen" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian wrote: > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, October 12, 2006 12:19 PM > To: 'Daryl Malas'; Jean-Francois Mule > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > I've been thinking about this thread and while there are some > conversation > starters here, I wonder how really relevant a lot of this is. Maybe > "relevant" is the wrong word, but I mean how much time and effort (and > words in a document) do we give it. >=20 > Generally speaking, the IETF designs protocols. In this work, we are > probably not going to do that, we're going to do "Best Current > Practice" > documents. In the IETF, those are mostly "how best do you use the > protocols > the IETF defined, for a specific task". Agreed.=20 Here is a the proposed accounting section (edited from Daryl's text) with *specific* IETF protocol references: ----------------------- Accounting and Billing: Call accounting may be required for tracking session usage on a peer's network. It is critical for peers to determine whether the support of any SIP extensions for accounting is a pre-requisite for SIP interoperability. In some cases, call accounting may feed data for billing purposes but not always: some operators may decide to use accounting as a 'bill and keep' model to track session usage and monitor usage against service level agreements. =09 defines the terminology and basic = requirements for accounting of SIP sessions. A few private SIP extensions have also been defined and used over the years to enable call accounting between VSP domains such as the P-Charging* headers in , the P-DCS-Billing-Info header in , etc. ------------------------ Note this is out of scope but it helps on three fronts: - bring folks on the same page re: terminology (count how many times billing has been mentioned on this list when we meant accounting) - capture what's out there in some RFCs - start providing answers to folks who are not tracking the list. I note that some recent and esteemed reviewers asked about billing and accounting. Worse case, this is in an annex, we just delete it when the document matures. At least, that was my thought. =20 > Generally speaking, IETF documents don't describe what would be in a > contract between peers or between a peer and a federation. =20 I agree and I have refrained from using the terms federation in the edited text. To re-use your proposed definition of 'policy', I view these as things that peers should talk about as part of policy agreements. > It is all > well > and good, and in fact I enthusiastically agree that the resolution of > the > codec discussion is that "The federation defines a codec policy to > which all > peers must adhere which would include designation of one or more > mandatory > to deploy codec and/or local transcode capability for each supported > media > type (audio, video, text) so that all calls can successfully complete > offer/answer exchange. Consideration should be given in specifying > mandatory-to-deploy codecs to include at least one that has minimal > degradation of signal fidelity when two transcodes are required to > achieve > actual end to end compatibility." The proposed text for draft-01 based on the interim meeting reads: -------------------- Media-related parameters SHOULD be included as part of a Voice Service Provider's policy. VSPs engaged in session peering SHOULD support of compatible codecs. Transcoding SHOULD be avoided by proposing commonly agreed codecs.=20 Motivations: The media capabilities of a VSP's network are either a property of the SIP end-devices, or, a combination of the property of end-devices and Data Path Border Elements that may provide media transcoding. The choice of one or more common codecs for Voice over IP communications between VSPs is outside the scope of speermint. As stated in introduction, requirements applicable to end-devices of a VSP are out of scope. --------------------- Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 11:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUbf-0004Mw-9z; Mon, 16 Oct 2006 11:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUbe-0004Mq-3C for speermint@ietf.org; Mon, 16 Oct 2006 11:42:22 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUbc-0003ma-PI for speermint@ietf.org; Mon, 16 Oct 2006 11:42:22 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9GFgJjj011812; Mon, 16 Oct 2006 09:42:20 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Requirements "VoIP" Date: Mon, 16 Oct 2006 09:42:19 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirements "VoIP" Thread-Index: AcbuHrgO4UJeoAhaQQOSeZWJ3v2KYQDGm8iQ From: "Jean-Francois Mule" To: "Daryl Malas" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org re: the terminology question, are the definitions Hannes provided on VSP/ASP from the ECRIT wg work fine for us to use to generalize our IDs? They look good to me and re-using terminology other wgs have used seems better than inventing a new acronym.=20 Jean-Francois. > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Thursday, October 12, 2006 10:50 AM > To: speermint@ietf.org > Subject: [Speermint] Requirements "VoIP" >=20 > This is just a nit, but I don't think we should include VoIP > exclusively > in the document. I am referring to the title and also within the > abstract as examples. SIP can be used for more than VoIP, and I > foresee > SPEERMINT being used to peer for IM, Presence, Video, etc...utilizing > SIP for these purposes. >=20 > I suggest we generalize throughout the document by simply removing > "VoIP" where it applies to the type of interconnection and peering. >=20 > --Daryl >=20 >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Mon Oct 16 11:48:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUhM-00088R-2S; Mon, 16 Oct 2006 11:48:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUhK-000886-7f for speermint@ietf.org; Mon, 16 Oct 2006 11:48:14 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZUhF-0004ZY-TM for speermint@ietf.org; Mon, 16 Oct 2006 11:48:14 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 277FC1A362; Mon, 16 Oct 2006 17:47:59 +0200 (CEST) Date: Mon, 16 Oct 2006 17:47:59 +0200 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061016154759.GI19113@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <20061013080359.GG19113@nic.at> <1160759128.16895.87.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160759128.16895.87.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/13 19:10, Daryl Malas wrote: > Thanks guys...you know far more about DNS than I do. From experiences > way....back, I thought there was a way to respond to a DNS query with a > prioritized list of IP addresses associated with a domain. So, I was > asking if a requirement should be necessary to restrict WHO can change > that prioritization (if it exists). SRV records are prioritized, thus yes: The RFC 3263 mechanism can be used to communicate something like * Try 1.2.3.4 first, * if that fails, try 5.6.7.8, then * 1.3.5.7 The problem I see here is not the fact that you can't prioritize, it is that you can't customize based on who is asking. You can't tell carrier A to go for 1.2.3.4 first while also telling carrier B to try 5.6.7.8 first. >From what I have gleaned from network operator, they do want to tell their peering partners (independently of other peerings) quite explicitely to which ingress point they should connect to. That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01). /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 12:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUwc-0005Ma-6A; Mon, 16 Oct 2006 12:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZUwa-0005MV-Uq for speermint@ietf.org; Mon, 16 Oct 2006 12:04:00 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZUwZ-00070F-H9 for speermint@ietf.org; Mon, 16 Oct 2006 12:04:00 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: [Speermint] Basic Peering Requirements Date: Mon, 16 Oct 2006 18:02:20 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B99@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbxOmakDvBat8DkSSCDkK55HiDAsQAAg8Po References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc><1160147044.16895.33.camel@montag.eng.level3.com><32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc><1160171829.16895.59.camel@montag.eng.level3.com><20061013080359.GG19113@nic.at><1160759128.16895.87.camel@montag.eng.level3.com> <20061016154759.GI19113@nic.at> From: "Stastny Richard" To: "Otmar Lendl" , "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined >in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01). What else?=20 Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Mo 16.10.2006 17:47 An: Daryl Malas Cc: speermint@ietf.org Betreff: Re: [Speermint] Basic Peering Requirements On 2006/10/13 19:10, Daryl Malas wrote: > Thanks guys...you know far more about DNS than I do. From experiences > way....back, I thought there was a way to respond to a DNS query with = a > prioritized list of IP addresses associated with a domain. So, I was > asking if a requirement should be necessary to restrict WHO can change > that prioritization (if it exists). SRV records are prioritized, thus yes: The RFC 3263 mechanism can be used to communicate something like * Try 1.2.3.4 first, * if that fails, try 5.6.7.8, then * 1.3.5.7 The problem I see here is not the fact that you can't prioritize, it is that you can't customize based on who is asking. You can't tell carrier A to go for 1.2.3.4 first while also telling carrier B to try 5.6.7.8 first. >From what I have gleaned from network operator, they do want to tell their peering partners (independently of other peerings) quite explicitely to which ingress point they should connect to. That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01). /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 From speermint-bounces@ietf.org Mon Oct 16 12:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVC3-0008Ko-0D; Mon, 16 Oct 2006 12:19:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVC1-0008J2-6i for speermint@ietf.org; Mon, 16 Oct 2006 12:19:57 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVBv-0000wH-Sc for speermint@ietf.org; Mon, 16 Oct 2006 12:19:57 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 581641A36F; Mon, 16 Oct 2006 18:19:50 +0200 (CEST) Date: Mon, 16 Oct 2006 18:19:50 +0200 From: Otmar Lendl To: Stastny Richard Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061016161949.GB15701@nic.at> Mail-Followup-To: Otmar Lendl , Stastny Richard , Daryl Malas , speermint@ietf.org References: <20061016154759.GI19113@nic.at> <32755D354E6B65498C3BD9FD496C7D462C4B99@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B99@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/16 18:10, Stastny Richard wrote: > >That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined > >in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01). > > What else? > Good question. IMHO we are sloppy with our requirements. To repeat: | From what I have gleaned from network operators, they do want to | tell their peering partners (independently of other peerings) quite | explicitely to which ingress point they should connect to. If that shows up in the final version of the speermint requirements, then the RFC3263 NAPTR/SRV/A algorithm will not suffice. (Unless you want to play with fire. i.e. split dns.) Square peg, meet round hole. Btw, our OpenSer domainpolicy code provides federations with the means to solve this by modifying the domain name which is the input to the RFC3263 algorithm. For the details, see http://www.enum.at/index.php?id=dokumente /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 12:38:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVTG-0003DX-LS; Mon, 16 Oct 2006 12:37:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZVTF-0003DP-NW for speermint@ietf.org; Mon, 16 Oct 2006 12:37:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZVTB-0003oe-Cg for speermint@ietf.org; Mon, 16 Oct 2006 12:37:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GZVT1-0008Tr-NU; Mon, 16 Oct 2006 11:37:32 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , "'Stastny Richard'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 16 Oct 2006 12:37:33 -0400 Message-ID: <00dd01c6f141$63d3c8f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbxPv/jFPnnhyY9RTOpRo2miogg3wAAHEKw In-Reply-To: <20061016161949.GB15701@nic.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think federations, and peers, are fixing these problems by practical means, which doesn't always meet the letter of the protocol "law". Mostly, I see federations allowing per peer-pair variability in their registry, whether it's an ENUM database, a SIP redirect, a SIP Forward or some other mechanism. The result is the same, for a given peer as origination to a specific peer as termination, a specific (list of) proxy server domain name(s) is provided. Usually, there aren't n squared values, but in theory there could be. Brian > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Monday, October 16, 2006 12:20 PM > To: Stastny Richard > Cc: speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements > > On 2006/10/16 18:10, Stastny Richard wrote: > > >That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined > > >in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01). > > > > What else? > > > > Good question. > > IMHO we are sloppy with our requirements. To repeat: > > | From what I have gleaned from network operators, they do want to > | tell their peering partners (independently of other peerings) quite > | explicitely to which ingress point they should connect to. > > If that shows up in the final version of the speermint requirements, > then the RFC3263 NAPTR/SRV/A algorithm will not suffice. > (Unless you want to play with fire. i.e. split dns.) > > Square peg, meet round hole. > > Btw, our OpenSer domainpolicy code provides federations with the means > to solve this by modifying the domain name which is the input to the > RFC3263 algorithm. For the details, see > http://www.enum.at/index.php?id=dokumente > > /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 From speermint-bounces@ietf.org Mon Oct 16 13:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZW9a-0002YK-JU; Mon, 16 Oct 2006 13:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZW9Z-0002YB-RC for speermint@ietf.org; Mon, 16 Oct 2006 13:21:29 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZW9Y-0004VB-G4 for speermint@ietf.org; Mon, 16 Oct 2006 13:21:29 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 16 Oct 2006 10:18:58 -0700 X-IronPort-AV: i="4.09,316,1157353200"; d="scan'208"; a="594982452:sNHT35817904" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Policy Definition Date: Mon, 16 Oct 2006 13:21:25 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805CA9BA5@proton.jnpr.net> In-Reply-To: <007f01c6f11e$859168d0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHw From: "Reinaldo Penno" To: "Brian Rosen" , "Jean-Francois Mule" , "Daryl Malas" , "David Schwartz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I suggest we just we use the terms already defined by the SIPPING WG. These are session-dependent and session-independent policies. This was what Jon P. mentioned in the interim meeting. You can find it here draft-ietf-sipping-policy-package-01 I leveraged these definitions in thse drafts: draft-ietf-speermint-architecture-02 (to be submiited soon) draft-penno-sipping-peering-package-00 If that does not make everybody happy, we can try to map Brian's suggestions into the SIPPING definitions and make a sub-hierarchy if needed. Let me know your thoughts. Thanks, Reinaldo =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, October 16, 2006 5:28 AM > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > While I think this definition is good, I think it is not sufficient. >=20 > I think we need to break policy up into several buckets and=20 > give each a name. >=20 > There is policy expressed statically (possibly by a contract,=20 > a web page, or some other thing that is human understandable). =20 >=20 > There is policy that has to do with addressing and routing,=20 > such as which federations it belongs to or which transit=20 > networks it connects to, or what ingress gateways it uses. =20 >=20 > There is dynamically discoverable policy that governs things=20 > beyond addressing. At any point in time, or maybe variable=20 > with federations, the this and static policy may have the=20 > same items in them, that is, we may start with, say, a static=20 > policy on how many calls per second we accept, and later come=20 > up with an automated way to discover it. >=20 > I propose: "static policy" "addressing (or routing) policy"=20 > and "dynamic policy" >=20 > Brian >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Monday, October 16, 2006 6:15 AM > > To: Brian Rosen; Daryl Malas; David Schwartz > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > >=20 > >=20 > > Here is my read of the thread on the 'policy' definition: > > "In the context of session peering, a policy is defined as=20 > the set of=20 > > parameters and other information needed by one VSP to connect to=20 > > another. A policy may be agreed to by Peers, or specified by some=20 > > explicit protocol mechanism, or defined by a contract in a=20 > Federation.=20 > > A policy is typically applicable to multiple sessions: it is not a=20 > > per-call specific." > >=20 > > Notes: > > - VSP or VSP/ASP to re-use the ecrit terminology in order to=20 > > integrate other types of session peering per the comments that this=20 > > should not be voice-specific; > > - it incorporates the comments received on the fact=20 > that how a policy=20 > > is agreed to, or specify by is open to various models=20 > (Daryl's "agreed=20 > > to by Peers" and Richard's comment on the fact that the=20 > reference to=20 > > federation in this definition is not needed) > > - it does not prevent a VSP from including endpoint-related=20 > > parameters as long as those are representing what the VSP think is=20 > > required to 'connect' (per David's question) > >=20 > > Jean-Francois. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 13:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWci-0000EN-7M; Mon, 16 Oct 2006 13:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWcg-0000Dw-SF for speermint@ietf.org; Mon, 16 Oct 2006 13:51:34 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWcg-00028P-7i for speermint@ietf.org; Mon, 16 Oct 2006 13:51:34 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GZWcT-0007N0-O1; Mon, 16 Oct 2006 12:51:22 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Jean-Francois Mule'" , "'Daryl Malas'" , "'David Schwartz'" Subject: RE: [Speermint] Policy Definition Date: Mon, 16 Oct 2006 13:51:23 -0400 Message-ID: <00f701c6f14b$b44b41f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLA= In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805CA9BA5@proton.jnpr.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The problem I have with these definitions is that they don't map into what we are talking about, although I can believe that what I called "dynamic policy" could have two sub-policies: session dependent and session independent. Sipping's definitions don't meet "static" policies; the mechanism defined in the draft is for session dependent policy, but there is also a mechanism for session-independent policy that is also automated. I was after the distinction of something that needed a contract vs something that needed a protocol. It's a little harder to decide we need a term for the addressing related "policies". I suggested we do, primarily because they are not really policy decisions in the classical sense, but routing decisions, although we have been tending to call them "policy". Again, you can imagine session independent as well as session dependent versions of these. Consider the effect of congestion on a choice, or "buy 3 get one free" charging. Those would be "session dependent", even though normally, routing of voice traffic is more classically session independent. Brian > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Monday, October 16, 2006 1:21 PM > To: Brian Rosen; Jean-Francois Mule; Daryl Malas; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition > > I suggest we just we use the terms already defined by the SIPPING WG. > These are session-dependent and session-independent policies. This was > what Jon P. mentioned in the interim meeting. > > You can find it here draft-ietf-sipping-policy-package-01 > > I leveraged these definitions in thse drafts: > > draft-ietf-speermint-architecture-02 (to be submiited soon) > draft-penno-sipping-peering-package-00 > > > If that does not make everybody happy, we can try to map Brian's > suggestions into the SIPPING definitions and make a sub-hierarchy if > needed. > > Let me know your thoughts. > > Thanks, > > Reinaldo > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, October 16, 2006 5:28 AM > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > > > > While I think this definition is good, I think it is not sufficient. > > > > I think we need to break policy up into several buckets and > > give each a name. > > > > There is policy expressed statically (possibly by a contract, > > a web page, or some other thing that is human understandable). > > > > There is policy that has to do with addressing and routing, > > such as which federations it belongs to or which transit > > networks it connects to, or what ingress gateways it uses. > > > > There is dynamically discoverable policy that governs things > > beyond addressing. At any point in time, or maybe variable > > with federations, the this and static policy may have the > > same items in them, that is, we may start with, say, a static > > policy on how many calls per second we accept, and later come > > up with an automated way to discover it. > > > > I propose: "static policy" "addressing (or routing) policy" > > and "dynamic policy" > > > > Brian > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Monday, October 16, 2006 6:15 AM > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > "In the context of session peering, a policy is defined as > > the set of > > > parameters and other information needed by one VSP to connect to > > > another. A policy may be agreed to by Peers, or specified by some > > > explicit protocol mechanism, or defined by a contract in a > > Federation. > > > A policy is typically applicable to multiple sessions: it is not a > > > per-call specific." > > > > > > Notes: > > > - VSP or VSP/ASP to re-use the ecrit terminology in order to > > > integrate other types of session peering per the comments that this > > > should not be voice-specific; > > > - it incorporates the comments received on the fact > > that how a policy > > > is agreed to, or specify by is open to various models > > (Daryl's "agreed > > > to by Peers" and Richard's comment on the fact that the > > reference to > > > federation in this definition is not needed) > > > - it does not prevent a VSP from including endpoint-related > > > parameters as long as those are representing what the VSP think is > > > required to 'connect' (per David's question) > > > > > > Jean-Francois. > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Mon Oct 16 15:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYUG-0007ur-8f; Mon, 16 Oct 2006 15:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYTL-0006Rn-KX; Mon, 16 Oct 2006 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYTK-00056Q-Il; Mon, 16 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7AB573289A; Mon, 16 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZYTK-0005sz-BQ; Mon, 16 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 16 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : Use of DNS SRV and NAPTR Records for SPEERMINT Author(s) : T. Creighton, G. Khandpur Filename : draft-ietf-speermint-srv-naptr-use-00.txt Pages : 9 Date : 2006-10-16 The objective of this document is to specify the Best Current Practice (BCP) adopted by a Voice Over IP (VoIP) service provider in order to locate another VoIP service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-srv-naptr-use-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-srv-naptr-use-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-srv-naptr-use-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-16131241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-srv-naptr-use-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-srv-naptr-use-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-16131241.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Oct 16 17:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZZv-0007Ek-Sv; Mon, 16 Oct 2006 17:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZF2-0002VM-2C for speermint@ietf.org; Mon, 16 Oct 2006 16:39:20 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZZF0-0004As-NN for speermint@ietf.org; Mon, 16 Oct 2006 16:39:19 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 479691A362; Mon, 16 Oct 2006 22:39:17 +0200 (CEST) Date: Mon, 16 Oct 2006 22:39:17 +0200 From: Otmar Lendl To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061016203916.GC15701@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , 'Stastny Richard' , speermint@ietf.org References: <20061016161949.GB15701@nic.at> <00dd01c6f141$63d3c8f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00dd01c6f141$63d3c8f0$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Stastny Richard' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/16 18:10, Brian Rosen wrote: > I think federations, and peers, are fixing these problems by practical > means, which doesn't always meet the letter of the protocol "law". Sure. A lack of standardization doesn't make things impossible. There is a lot of SIP peering going on without speermint having published a single RFC. But isn't it the whole point of the speermint WG to migrate such ad-hoc arrangements to a standardized framework? > Mostly, I see federations allowing per peer-pair variability in their > registry, whether it's an ENUM database, a SIP redirect, a SIP Forward or > some other mechanism. The result is the same, for a given peer as > origination to a specific peer as termination, a specific (list of) proxy > server domain name(s) is provided. Usually, there aren't n squared values, > but in theory there could be. Two points here: 1) We can't just punt everything to "federation internal". That leaves us with nothing except federation discovery (which kind of begs the question why my drafts haven't been accepted as WG item as they are the only work I've seen which actually addresses this). In this case, that may well be federation internal, but what's wrong with providing a best practice document which gives guidance to federations on how to implement this? 2) The current real-life examples you list usually integrate several different procedures into one single lookup: * Number -> URI * Is there a peering relationship? * Where is the ingress SIP element of the next hop? That cannot be the Speermint solution as we have to cope with pure URI-based calls. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 17:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZpw-000713-5e; Mon, 16 Oct 2006 17:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZpu-00070N-Kb for speermint@ietf.org; Mon, 16 Oct 2006 17:17:26 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZZps-0004uo-Jb for speermint@ietf.org; Mon, 16 Oct 2006 17:17:26 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id B3F761A362; Mon, 16 Oct 2006 23:17:23 +0200 (CEST) Date: Mon, 16 Oct 2006 23:17:23 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-00.txt Message-ID: <20061016211723.GJ19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/16 21:10, Internet-Drafts@ietf.org wrote: > > Title : Use of DNS SRV and NAPTR Records for SPEERMINT > Author(s) : T. Creighton, G. Khandpur > Filename : draft-ietf-speermint-srv-naptr-use-00.txt I may be missing something, but is there anything in this draft which isn't just a summary of RFCs 3263 and 2782? The abstract says: The objective of this document is to specify the Best Current Practice (BCP) adopted by a Voice Over IP (VoIP) service provider in order to locate another VoIP service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. Given the discussions on-list and at the meetings: This does not describe what the current practice is. It just describes the theory in the current RFCs. The current practice is either manually nailed down peerings or a fabric which resolves numbers to ingress points. Does this describe what we want to establish as the "best future practice"? Can we really do that before we have nailed down the requirements? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 17:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaMG-0005eH-3d; Mon, 16 Oct 2006 17:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaMF-0005eC-Hh for speermint@ietf.org; Mon, 16 Oct 2006 17:50:51 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaMB-0000ff-9g for speermint@ietf.org; Mon, 16 Oct 2006 17:50:51 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id B5611350D for ; Mon, 16 Oct 2006 17:50:16 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 17:50:16 -0400 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 Date: Mon, 16 Oct 2006 17:50:14 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-uzelac-speermint-use-cases-oo.txt Thread-Index: AcbxbQ/hsQggH4DZRh+1VhcPxdCFfA== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 16 Oct 2006 21:50:16.0279 (UTC) FILETIME=[10D56E70:01C6F16D] X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Speermint] draft-uzelac-speermint-use-cases-oo.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org If you want to take a peak at some current practices (not the intentional omission of 'best') - see http://www.voiploser.com/misc/draft-uzelac-speermint-use-cases-oo.txt - I punted to I-D Action today, but after the 9am ET deadline for consideration in San Diego. :( I would still appreciate comments though. It's not pretty, but it's something to noodle on. -AU=20 PS - this is an attempt to capture what's going on out there today - NOT an endorsement. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 16 19:52:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZcEv-0008Gs-7F; Mon, 16 Oct 2006 19:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZcEt-0008D5-Tu for speermint@ietf.org; Mon, 16 Oct 2006 19:51:23 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZcEs-0006QF-Ja for speermint@ietf.org; Mon, 16 Oct 2006 19:51:23 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9GNpHcx010312; Mon, 16 Oct 2006 23:51:18 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Otmar Lendl In-Reply-To: <20061016154759.GI19113@nic.at> References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <20061013080359.GG19113@nic.at> <1160759128.16895.87.camel@montag.eng.level3.com> <20061016154759.GI19113@nic.at> Content-Type: text/plain Date: Mon, 16 Oct 2006 17:53:25 -0600 Message-Id: <1161042805.16895.102.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Mon, 2006-10-16 at 17:47 +0200, Otmar Lendl wrote: > On 2006/10/13 19:10, Daryl Malas wrote: > > Thanks guys...you know far more about DNS than I do. From experiences > > way....back, I thought there was a way to respond to a DNS query with a > > prioritized list of IP addresses associated with a domain. So, I was > > asking if a requirement should be necessary to restrict WHO can change > > that prioritization (if it exists). > > SRV records are prioritized, thus yes: The RFC 3263 mechanism can > be used to communicate something like > > * Try 1.2.3.4 first, > * if that fails, try 5.6.7.8, then > * 1.3.5.7 > > The problem I see here is not the fact that you can't prioritize, > it is that you can't customize based on who is asking. > > You can't tell carrier A to go for 1.2.3.4 first while also > telling carrier B to try 5.6.7.8 first. > No, but lets say that carrier C is hosting and managing the federation LF, and carrier C also has SF 1.2.3.4 and carrier D has 5.6.7.8. Carrier C gets a 2 cent kick-back (for some reason) every time a call comes through their network. If the indirect peer associated with 1.2.3.4 and 5.6.7.8 doesn't have the requirement to specify which is returned in what order...Carrier C will make sure 1.2.3.4 is listed first always in their...uh..er...cough..cough...the federations LF. To expand this example further...let's say carrier D actually has a larger pipe and known (tested via PESQ or similar) higher quality than carrier C. Can the indirect peer tell carrier C, whom is hosting the federation LF to change it, or do they change it themselves and no 3rd party can change it? All I was saying is a simple requirement stating only the indirect peer can specify any priority might be necessary. In a perfect world, this type of malicious behavior would never take place, but in the real world; carrier C will likely try hard to pad their bottom line. Now, the indirect peer would probably be stupid to enter an agreement with carrier C without the ability to fully manage their "transit" choices, but it's something to keep in mind....or maybe not?!? I don't want to beat this horse anymore...if the group thinks this is a non-issue...then consider this topic dropped from conversation. I was just throwing it out there as a possible consideration. --Daryl > >From what I have gleaned from network operator, they do want to > tell their peering partners (independently of other peerings) quite > explicitely to which ingress point they should connect to. > > That's the reason I'm not so hot on the use of NAPTR/SRV/A (as defined > in 3263 and draft-creighton-khandpur-speermint-srv-naptr-use-01). > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 04:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkQR-0004wu-IX; Tue, 17 Oct 2006 04:35:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZkQN-0004tz-Fl for speermint@ietf.org; Tue, 17 Oct 2006 04:35:47 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZkKZ-0007mL-9S for speermint@ietf.org; Tue, 17 Oct 2006 04:29:48 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id E5B741A36C; Tue, 17 Oct 2006 10:29:45 +0200 (CEST) Date: Tue, 17 Oct 2006 10:29:45 +0200 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061017082945.GD15701@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , speermint@ietf.org References: <32755D354E6B65498C3BD9FD496C7D463C51B1@oefeg-s04.oefeg.loc> <1160147044.16895.33.camel@montag.eng.level3.com> <32755D354E6B65498C3BD9FD496C7D462C4B85@oefeg-s04.oefeg.loc> <1160171829.16895.59.camel@montag.eng.level3.com> <20061013080359.GG19113@nic.at> <1160759128.16895.87.camel@montag.eng.level3.com> <20061016154759.GI19113@nic.at> <1161042805.16895.102.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1161042805.16895.102.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/17 01:10, Daryl Malas wrote: > > In a perfect world, this type of malicious behavior would never take > place, but in the real world; carrier C will likely try hard to pad > their bottom line. Now, the indirect peer would probably be stupid to > enter an agreement with carrier C without the ability to fully manage > their "transit" choices, but it's something to keep in mind....or maybe > not?!? > > I don't want to beat this horse anymore...if the group thinks this is a > non-issue...then consider this topic dropped from conversation. I was > just throwing it out there as a possible consideration. IMHO your examples proove that the call routing over intermediaries is a) needed and b) a rather complex issue fraught with competing commercial, technical, and perhaps eben legal requirements. I still think we need to work out and then nail down what the requirements are for the routing decisions which we face in the speermint context. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 08:24:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnyQ-0000a6-5U; Tue, 17 Oct 2006 08:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZnyO-0000a0-HN for speermint@ietf.org; Tue, 17 Oct 2006 08:23:08 -0400 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZnyM-00067n-PN for speermint@ietf.org; Tue, 17 Oct 2006 08:23:08 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id k9HCN6NS186038 for ; Tue, 17 Oct 2006 12:23:06 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9HCPagX3031212 for ; Tue, 17 Oct 2006 14:25:36 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9HCN5Tq008544 for ; Tue, 17 Oct 2006 14:23:05 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9HCN5CZ008541 for ; Tue, 17 Oct 2006 14:23:05 +0200 To: speermint@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Tue, 17 Oct 2006 14:25:32 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 17/10/2006 14:25:35, Serialize complete at 17/10/2006 14:25:35 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Subject: [Speermint] Fw: I-D ACTION:draft-houri-speermint-usecase-presence-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1442563208==" Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. --===============1442563208== Content-Type: multipart/alternative; boundary="=_alternative 00440C21C225720A_=" This is a multipart message in MIME format. --=_alternative 00440C21C225720A_= Content-Type: text/plain; charset="US-ASCII" FYI. Title should have been "Presence and IM use cases" --Avshalom Real Time Collaboration Standards ----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 ----- Internet-Drafts@ietf.org 17/10/2006 00:50 Please respond to internet-drafts@ietf.org To i-d-announce@ietf.org cc Subject I-D ACTION:draft-houri-speermint-usecase-presence-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTC Provisioning Requirements Author(s) : A. Houri, et al. Filename : draft-houri-speermint-usecase-presence-00.txt Pages : 12 Date : 2006-10-16 The document describes several use cases for peering between two or more communities that provide real time communications services and presence and IM in particular. The communities create a peering relationship between themselves thus enabling their users to collaborate with users on other communities. The target of the document is to help understanding the requirements for peering between domains with regard to real time services A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-houri-speermint-usecase-presence-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-houri-speermint-usecase-presence-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=_alternative 00440C21C225720A_= Content-Type: text/html; charset="US-ASCII"
FYI. Title should have been "Presence and IM use cases"

--Avshalom
Real Time Collaboration Standards
----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 -----
Internet-Drafts@ietf.org

17/10/2006 00:50
Please respond to
internet-drafts@ietf.org
To
i-d-announce@ietf.org
cc
Subject
I-D ACTION:draft-houri-speermint-usecase-presence-00.txt





A New Internet-Draft is available from the on-line Internet-Drafts
directories.


                Title                                  : RTC Provisioning Requirements
                Author(s)                 : A. Houri, et al.
                Filename                 : draft-houri-speermint-usecase-presence-00.txt
                Pages                                  : 12
                Date                                  : 2006-10-16
               
  The document describes several use cases for peering between two or
  more communities that provide real time communications services and
  presence and IM in particular.  The communities create a peering
  relationship between themselves thus enabling their users to
  collaborate with users on other communities.  The target of the
  document is to help understanding the requirements for peering
  between domains with regard to real time services


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-houri-speermint-usecase-presence-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                mailserv@ietf.org.
In the body type:
                "FILE /internet-drafts/draft-houri-speermint-usecase-presence-00.txt".
               
NOTE:                 The mail server at ietf.org can return the document in
                MIME-encoded form by using the "mpack" utility.  To use this
                feature, insert the command "ENCODING mime" before the "FILE"
                command.  To decode the response(s), you will need "munpack" or
                a MIME-compliant mail reader.  Different MIME-compliant mail readers
                exhibit different behavior, especially when dealing with
                "multipart" MIME messages (i.e. documents which have been split
                up into multiple messages), so check your local documentation on
                how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
 --=_alternative 00440C21C225720A_=-- --===============1442563208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1442563208==-- From speermint-bounces@ietf.org Tue Oct 17 09:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZp9i-0002ow-Vi; Tue, 17 Oct 2006 09:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZp9h-0002oi-QD for speermint@ietf.org; Tue, 17 Oct 2006 09:38:53 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZp9V-0000zn-22 for speermint@ietf.org; Tue, 17 Oct 2006 09:38:53 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HDccdw014222; Tue, 17 Oct 2006 07:38:38 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Tue, 17 Oct 2006 07:38:37 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAA0X0EA From: "Jean-Francois Mule" To: "Brian Rosen" , "Daryl Malas" , "David Schwartz" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian wrote: > While I think this definition is good, I think it is not sufficient. The main goal is to have a rough definition we feel comfortable with. If we try to get all the properties of a policy in the definition at this point, it may be difficult to. > I think we need to break policy up into several buckets and give each > a name. Could we achieve this by providing examples of policy properties in a couple of sentences? This was the goal of breaking the definition in a first short sentence, then add to it with a few additional sentences.=20 > There is policy expressed statically (possibly by a contract, a web > page, or some other thing that is human understandable). Whether it can be exchanged statically or dynamically, I'm not sure the basic definition of 'policy' differs here. > There is policy that has to do with addressing and routing, such as > which > federations it belongs to or which transit networks it connects to, or > what > ingress gateways it uses. These policy parameters could fit in the SIPPING terminology of session policies. =20 > There is dynamically discoverable policy that governs things beyond > addressing. =20 > At any point in time, or maybe variable with federations, > the > this and static policy may have the same items in them, that is, we > may > start with, say, a static policy on how many calls per second we > accept, and > later come up with an automated way to discover it. Yes, I don't think we are implying that session-independent policy parameters are distinct from session-dependent ones: when instantiated, a policy param could be updated based on both static & dynamic constraints. > I propose: "static policy" "addressing (or routing) policy" and > "dynamic policy" > Brian >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Monday, October 16, 2006 6:15 AM > > To: Brian Rosen; Daryl Malas; David Schwartz > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > > > > > > Here is my read of the thread on the 'policy' definition: > > "In the context of session peering, a policy is defined as the set > of > > parameters and other information needed by one VSP to connect to > > another. A policy may be agreed to by Peers, or specified by some > > explicit protocol mechanism, or defined by a contract in a > Federation. A > > policy is typically applicable to multiple sessions: it is not a > > per-call specific." > > > > Notes: > > - VSP or VSP/ASP to re-use the ecrit terminology in order to > > integrate other types of session peering per the comments that this > > should not be voice-specific; > > - it incorporates the comments received on the fact that how a > > policy is agreed to, or specify by is open to various models > (Daryl's > > "agreed to by Peers" and Richard's comment on the fact that the > > reference to federation in this definition is not needed) > > - it does not prevent a VSP from including endpoint-related > > parameters as long as those are representing what the VSP think is > > required to 'connect' (per David's question) > > > > Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 10:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUO-0008CL-9w; Tue, 17 Oct 2006 10:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUM-0008Bk-V0 for speermint@ietf.org; Tue, 17 Oct 2006 10:00:14 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpU3-0002rU-6A for speermint@ietf.org; Tue, 17 Oct 2006 09:59:56 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HDxqbo025432; Tue, 17 Oct 2006 07:59:52 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Tue, 17 Oct 2006 07:59:50 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKkXEQA== From: "Jean-Francois Mule" To: "Brian Rosen" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian wrote: > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, October 16, 2006 11:51 AM > To: 'Reinaldo Penno'; Jean-Francois Mule; 'Daryl Malas'; 'David > Schwartz' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > The problem I have with these definitions is that they don't map into > what > we are talking about, although I can believe that what I called > "dynamic > policy" could have two sub-policies: session dependent and session > independent. >=20 > Sipping's definitions don't meet "static" policies; the mechanism To me, that kind of static parameters for UAs are handled in the configuration framework and associated protocol toolkit: SIPPING CONFIG-XCAP, etc. I think we are loosing focus here: we seem to be bogged down by how to categorize policy stuff (and the behavioral aspects of discovering and exchanging policies) instead of just mentioning that yeah, some policy parameters may be static or dynamic, and then discuss what those may be. > defined in > the draft is for session dependent policy, but there is also a > mechanism for > session-independent policy that is also automated. I was after the > distinction of something that needed a contract vs something that > needed a protocol. As *you* proposed during the interim meeting, and most everyone seemed to be ok, I thought we going to table the dynamic exchange of policies for later. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 10:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUb-00005z-FE; Tue, 17 Oct 2006 10:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUa-0008W3-4C for speermint@ietf.org; Tue, 17 Oct 2006 10:00:28 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpNJ-0002Lr-B2 for speermint@ietf.org; Tue, 17 Oct 2006 09:52:58 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HDqu75020846; Tue, 17 Oct 2006 07:52:56 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Tue, 17 Oct 2006 07:52:55 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTA= From: "Jean-Francois Mule" To: "Reinaldo Penno" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo wrote: > I suggest we just we use the terms already defined by the SIPPING WG. > These are session-dependent and session-independent policies. This was > what Jon P. mentioned in the interim meeting. Yes for helping distinguish between the things that are session-dependent vs. session independent. But there are 2 points we are trying to clarify here and capture in our common understanding that are not addressed in the SIPPING drafts: a) the policy definitions in draft-ietf-sipping-session-policy-framework-01.txt do not actually define what a policy is other than by using examples of policy parameters in areas which have been declared out of scope such as codec, and QoS. =3D=3D> we should keep the basic sentence Brian originally proposed: "the set of parameters and other information needed by one VSP/ASP to connect to another." b) the SIPPING drafts are geared towards *intra*-domain policies applicable to UAs of a given domain (UA <-> Policy Server) whereas much of what we are discussing here is *inter*-domain, stuff between Policy Servers or PFs. This may be obvious but it needs to be clear in our definition. Jean-Francois.=20 >=20 > You can find it here draft-ietf-sipping-policy-package-01 >=20 > I leveraged these definitions in thse drafts: >=20 > draft-ietf-speermint-architecture-02 (to be submiited soon) > draft-penno-sipping-peering-package-00 >=20 >=20 > If that does not make everybody happy, we can try to map Brian's > suggestions into the SIPPING definitions and make a sub-hierarchy if > needed. >=20 > Let me know your thoughts. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, October 16, 2006 5:28 AM > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > > > > While I think this definition is good, I think it is not sufficient. > > > > I think we need to break policy up into several buckets and > > give each a name. > > > > There is policy expressed statically (possibly by a contract, > > a web page, or some other thing that is human understandable). > > > > There is policy that has to do with addressing and routing, > > such as which federations it belongs to or which transit > > networks it connects to, or what ingress gateways it uses. > > > > There is dynamically discoverable policy that governs things > > beyond addressing. At any point in time, or maybe variable > > with federations, the this and static policy may have the > > same items in them, that is, we may start with, say, a static > > policy on how many calls per second we accept, and later come > > up with an automated way to discover it. > > > > I propose: "static policy" "addressing (or routing) policy" > > and "dynamic policy" > > > > Brian > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Monday, October 16, 2006 6:15 AM > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > "In the context of session peering, a policy is defined as > > the set of > > > parameters and other information needed by one VSP to connect to > > > another. A policy may be agreed to by Peers, or specified by some > > > explicit protocol mechanism, or defined by a contract in a > > Federation. > > > A policy is typically applicable to multiple sessions: it is not a > > > per-call specific." > > > > > > Notes: > > > - VSP or VSP/ASP to re-use the ecrit terminology in order to > > > integrate other types of session peering per the comments that > this > > > should not be voice-specific; > > > - it incorporates the comments received on the fact > > that how a policy > > > is agreed to, or specify by is open to various models > > (Daryl's "agreed > > > to by Peers" and Richard's comment on the fact that the > > reference to > > > federation in this definition is not needed) > > > - it does not prevent a VSP from including endpoint-related > > > parameters as long as those are representing what the VSP think is > > > required to 'connect' (per David's question) > > > > > > Jean-Francois. > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Tue Oct 17 10:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUO-0008CL-9w; Tue, 17 Oct 2006 10:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUM-0008Bk-V0 for speermint@ietf.org; Tue, 17 Oct 2006 10:00:14 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpU3-0002rU-6A for speermint@ietf.org; Tue, 17 Oct 2006 09:59:56 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HDxqbo025432; Tue, 17 Oct 2006 07:59:52 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Tue, 17 Oct 2006 07:59:50 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKkXEQA== From: "Jean-Francois Mule" To: "Brian Rosen" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian wrote: > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, October 16, 2006 11:51 AM > To: 'Reinaldo Penno'; Jean-Francois Mule; 'Daryl Malas'; 'David > Schwartz' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > The problem I have with these definitions is that they don't map into > what > we are talking about, although I can believe that what I called > "dynamic > policy" could have two sub-policies: session dependent and session > independent. >=20 > Sipping's definitions don't meet "static" policies; the mechanism To me, that kind of static parameters for UAs are handled in the configuration framework and associated protocol toolkit: SIPPING CONFIG-XCAP, etc. I think we are loosing focus here: we seem to be bogged down by how to categorize policy stuff (and the behavioral aspects of discovering and exchanging policies) instead of just mentioning that yeah, some policy parameters may be static or dynamic, and then discuss what those may be. > defined in > the draft is for session dependent policy, but there is also a > mechanism for > session-independent policy that is also automated. I was after the > distinction of something that needed a contract vs something that > needed a protocol. As *you* proposed during the interim meeting, and most everyone seemed to be ok, I thought we going to table the dynamic exchange of policies for later. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 10:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUb-00005z-FE; Tue, 17 Oct 2006 10:00:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUa-0008W3-4C for speermint@ietf.org; Tue, 17 Oct 2006 10:00:28 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpNJ-0002Lr-B2 for speermint@ietf.org; Tue, 17 Oct 2006 09:52:58 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HDqu75020846; Tue, 17 Oct 2006 07:52:56 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Tue, 17 Oct 2006 07:52:55 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTA= From: "Jean-Francois Mule" To: "Reinaldo Penno" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo wrote: > I suggest we just we use the terms already defined by the SIPPING WG. > These are session-dependent and session-independent policies. This was > what Jon P. mentioned in the interim meeting. Yes for helping distinguish between the things that are session-dependent vs. session independent. But there are 2 points we are trying to clarify here and capture in our common understanding that are not addressed in the SIPPING drafts: a) the policy definitions in draft-ietf-sipping-session-policy-framework-01.txt do not actually define what a policy is other than by using examples of policy parameters in areas which have been declared out of scope such as codec, and QoS. =3D=3D> we should keep the basic sentence Brian originally proposed: "the set of parameters and other information needed by one VSP/ASP to connect to another." b) the SIPPING drafts are geared towards *intra*-domain policies applicable to UAs of a given domain (UA <-> Policy Server) whereas much of what we are discussing here is *inter*-domain, stuff between Policy Servers or PFs. This may be obvious but it needs to be clear in our definition. Jean-Francois.=20 >=20 > You can find it here draft-ietf-sipping-policy-package-01 >=20 > I leveraged these definitions in thse drafts: >=20 > draft-ietf-speermint-architecture-02 (to be submiited soon) > draft-penno-sipping-peering-package-00 >=20 >=20 > If that does not make everybody happy, we can try to map Brian's > suggestions into the SIPPING definitions and make a sub-hierarchy if > needed. >=20 > Let me know your thoughts. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, October 16, 2006 5:28 AM > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > > > > While I think this definition is good, I think it is not sufficient. > > > > I think we need to break policy up into several buckets and > > give each a name. > > > > There is policy expressed statically (possibly by a contract, > > a web page, or some other thing that is human understandable). > > > > There is policy that has to do with addressing and routing, > > such as which federations it belongs to or which transit > > networks it connects to, or what ingress gateways it uses. > > > > There is dynamically discoverable policy that governs things > > beyond addressing. At any point in time, or maybe variable > > with federations, the this and static policy may have the > > same items in them, that is, we may start with, say, a static > > policy on how many calls per second we accept, and later come > > up with an automated way to discover it. > > > > I propose: "static policy" "addressing (or routing) policy" > > and "dynamic policy" > > > > Brian > > > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Monday, October 16, 2006 6:15 AM > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > "In the context of session peering, a policy is defined as > > the set of > > > parameters and other information needed by one VSP to connect to > > > another. A policy may be agreed to by Peers, or specified by some > > > explicit protocol mechanism, or defined by a contract in a > > Federation. > > > A policy is typically applicable to multiple sessions: it is not a > > > per-call specific." > > > > > > Notes: > > > - VSP or VSP/ASP to re-use the ecrit terminology in order to > > > integrate other types of session peering per the comments that > this > > > should not be voice-specific; > > > - it incorporates the comments received on the fact > > that how a policy > > > is agreed to, or specify by is open to various models > > (Daryl's "agreed > > > to by Peers" and Richard's comment on the fact that the > > reference to > > > federation in this definition is not needed) > > > - it does not prevent a VSP from including endpoint-related > > > parameters as long as those are representing what the VSP think is > > > required to 'connect' (per David's question) > > > > > > Jean-Francois. > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Tue Oct 17 11:14:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqdC-0003N5-Ud; Tue, 17 Oct 2006 11:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZqdB-0003My-EJ for speermint@ietf.org; Tue, 17 Oct 2006 11:13:25 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZqd6-0002sF-Rz for speermint@ietf.org; Tue, 17 Oct 2006 11:13:25 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 817481A36C; Tue, 17 Oct 2006 17:13:19 +0200 (CEST) Date: Tue, 17 Oct 2006 17:13:19 +0200 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20061017151319.GG15701@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [Speermint] Some remarks on peering/interconnection models X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I've been mulling about whether we have got some of the basics of SIP peering correct: What kind of basic interconnection scheme will emerge out of the symbiosis of the Internet and PSTN worlds? What models do we see right now? A) The point-to-point model: Incarnations are the PSTN and the Layer 3 Internet: The overall Network is built upon the physical interconnection of smaller networks. In both cases, commercial factors have resulted in a multi-tier network architecture, with global players, regional networks, and small access networks. Any call (or packet) traversing that network is passed over pre-established interconnection links between provider networks. Routing information is always next-hop based: The switches (or routers) which make up the network need to know which outgoing trunk they need to forward the call/packet too. The routing protocols differ: the PSTN is more database driven and uses manual configuration, whereas the Internet relies on a dynamic routing protocol (BGP). [The commercial aspects vary, too. But that's not important here.] B) The email model: The basic premise here is that we have a functional and worldwide L3 network. On the email layer, we thus don't have hard-coded point-to-point links. Everybody can talk to everybody else if a single email demands it. There is thus no need for pre-configured "email trunks". All that is needed is a global directory system (the DNS) which maps domains to L3 addresses of ingress points. Email ingress points are a simple set of addresses, which are identical for whoever wants to send email to that domain. No prior arrangement of any kind are necessary before emails can be transmitted. Email is accepted from any source on the Internet, and not only from pre-screened email partners. SIP as defined by RFC 3261/3263 follows this model. --------------------- How does SIP peering as envisioned by the speermint fit into these models? In my humble opinion: somewhere in the middle. * It won't be a pure point-to-point model. On the commercial side, a lot depends on the sustainability of the current PSTN-style settlement regime. As long as money flows for each call, bilateral agreements will be the norm. Authentication based on VPN or TLS keys can supplant authentication based on a physical connection. Thus even for logical point-to-point links, there is no need to actually use dedicated physical point-to-point links. From a technical point of view, n:n peerings are simple to establish using a shared L3 network. For small VSPs (especially enterprises), widespread peering may be desirable to avoid transit charges to larger operators. In that cases, the main criteria for entering a peering relationship is the question of how to establish trust between the parties. Some people may even continue to run completely open SIP proxies. The number of domains to route is way to large to establish a routing protocol (similar to BGP, OSPF, ...) based on domains. * It won't be the email model. Settlement, trust and SPIT are an issue. Networks will be selective regarding from whom they will accept calls. Selective ingress points: The will not be a single set of ingress points which are open for all other networks to send calls to. Some might be on private networks, some might involve geographic restrictions, some might depend on codecs. While there is the ubiquitous global L3 network, peerings will make extensive use of private L2/3 infrastructure. * It will be a wild mixture: - some networks will have strict rules making them close to the point-to-point model. Other will be more open and accept calls from almost anyone. I expect the large networks to rely primarily on pre-configured links. Smaller networks and especially enterprises will employ a mixture of both statically configured links as well as dynamically established peerings. - the commercial models will vary a lot. An enterprise will take a different approach than an old school carrier. - even a singe VSP will have different types of peerings at the same time. E.g. one or two "upstream" connections which connects it to the carrier network and the PSTN, some peering relationships at a local exchange with similar players and perhaps dynamically peerings based on TLS. - The peering decision is not a question of establishing connectivity, but one of establishing trust, commercial relations (if needed), and QoS. --------------- Right now, all this is happening in an ad-hoc matter: The PSTN is still the default network for voice calls. SIP peering are configured manually, various services have sprung up to solve bits and pieces of the problem space, but right now there is no basic architecture for such an hybrid interconnection world. Another complication is the fact that call-routing is both based on E.164 numbers and SIP URIs. What approaches do exist? * User-ENUM and open SIP servers. Nice in theory, but the last few years have shown that this isn't the winner. * IMS / NGN The telco approach. Ain't going to be popular in the enterprise sector. * Individual peering fabrics Usually local solutions for a specific market. Competitive business. Usually number-based. World dominination ambitions abound. What's needed: * Get the number vs. URI stuff sorted out once and for all. We can't go on indefinitely using two different addressing schemes for same routing decisions. The extra complexity will kill us. * A call routing algorithm which - works with static peerings - dynamic peer discovery - enables path selection based on a wide range of (real-time) parameters. - can be used by the big international carriers as well as small enterprise SIP installations. * Get the bilateral technical issues sorted out - SIP feature set - caller-id/privacy/... - codecs/transcoding /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 11:39:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr1c-0003Zw-Oe; Tue, 17 Oct 2006 11:38:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZr1b-0003YM-7b for speermint@ietf.org; Tue, 17 Oct 2006 11:38:39 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZr1X-0005Ik-N3 for speermint@ietf.org; Tue, 17 Oct 2006 11:38:39 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HFcLNt003781; Tue, 17 Oct 2006 09:38:22 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Speermint] TLS related requirements for speermint ID Date: Tue, 17 Oct 2006 09:38:20 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS related requirements for speermint ID Thread-Index: AcbyAldCYxDkox8FRLipDq2U4cJoIQ== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org All, =20 --- pre-amble At the interim meeting, we had a consensus that the goal of the requirement document is not to mandate the use of any protocol mechanisms, but when those mechanisms are in use, we should describe what's required to guarantee some levels of interoperability. While the focus of this msg is TLS, it was also noted that other mechanisms intended to secure the lower layers of session peering like IPSec or L2/L3VPNs may exist or co-exist with L5 session security based on the threat models, keying exchange capabilities and trust relationships... FFS based on threat model. (just wanted to note upfront this so that the thread does not deviate) --- TLS: At the wg's interim meeting, folks thought it would be good to add more details on what's required for 2 VSP/ASPs to "turn on" or use TLS (if/when it is enabled). The comment was that the BCP/requirement draft should go a level deeper than just saying "MUST support TLS".=20 Here is some very first text to propose some directions. This is for review based on the SIP and SIPPING work on Identity, use of TLS, and the 2 I-Ds from Rohan and Vijay referenced below. The intent here is to capture what 2 VSPs/ASPs should discuss and agree on in order to establish a TLS connection for sip session peering (pending the threat analysis document). --- 1. Peers SHOULD mutually trust each other's root CAs - Motivations: A VSP/ASP should have control over which root CA it trusts; this may imply creating a certificate trust list to include the peer's CA for each authorized domain. This requirement allows for the initiating side to verify that the server cert is rooted in a well-known CA. - Derivative requirement: SIP servers SHOULD allow the configuration of certificate trust lists in order to allow a VSP/ASP to control which peer's CAs are trusted for TLS connections. --- 2. Peers SHOULD indicate whether their domain policies require proxy servers to inspect and verify the identity provided in SIP requests per RFC 4474. --- 3. When TLS is used between peers, SIP servers involved in the session establishment MUST have valid X.509 certificates and MUST be able to receive a TLS connection. Motivations: If TLS is supported for session peering, SIP servers must have valid X.509 certificates and they should listen on the SIP TLS port for incoming connections. --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed upon as part of session peering policies: + The version of TLS (TLSv1, TLSv1.1) + The SIP TLS port (default 5061) + The server-side session timeout (default 300 seconds) + The list of supported or recommended ciphersuite + list of trusted root CAs --- 5. SIP entities involved in the session establishment exchanges MUST follow the following requirements: + check certs :=20 "the client certificate MUST contain a DNS or URI choice type in the subjectAltName which corresponds to the domain asserted in the host production of the From header URI." (from Rohan's I-D) + check identity in cert per section 4 of http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? + add details and pointers to the use of RFC 4474 inter-domain. =3D=3D> open questions: These are best current practices that should be followed. We can either reference the work-in-progress IDs or paste some of the most relevant text and then refer to the I-Ds. REFERENCEs: - Rohan's direct peering draft http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct-peering-0 0.txt, - Vijay's http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: --- 6. A session peering policy SHOULD include details on SIP session establishment over TLS (see above, to be briefly summarized1111). --- Open questions: - should we re-iterate the requirement of RFC 4474 that self-signed certs should not be trusted unless prior key exchange has occurred? Given the goals of speermint, should there be more guidance on the use of self-signed certs? - should there be a minimum set of ciphersuites to recommend or leave it open? Is this on the right track and what folks had in mind? Comments and input are appreciated. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 11:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrG2-0007fo-NL; Tue, 17 Oct 2006 11:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrG0-0007fi-Ju for speermint@ietf.org; Tue, 17 Oct 2006 11:53:32 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrFy-0007KI-6P for speermint@ietf.org; Tue, 17 Oct 2006 11:53:32 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 122951A3B0; Tue, 17 Oct 2006 17:53:23 +0200 (CEST) Date: Tue, 17 Oct 2006 17:53:23 +0200 From: Otmar Lendl To: "Uzelac, Adam" Subject: Re: [Speermint] draft-uzelac-speermint-use-cases-oo.txt Message-ID: <20061017155323.GL19113@nic.at> Mail-Followup-To: Otmar Lendl , "Uzelac, Adam" , speermint@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/16 23:10, "Uzelac, Adam" wrote: > If you want to take a peak at some current practices (not the > intentional omission of 'best') - see > http://www.voiploser.com/misc/draft-uzelac-speermint-use-cases-oo.txt - > I punted to I-D Action today, but after the 9am ET deadline for > consideration in San Diego. :( I would still appreciate comments > though. It's not pretty, but it's something to noodle on. Thanks Adam, this is a helpful document. Two questions: Within your descriptions, you often use the phrase The performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. I'm wondering if these decisions are number or URI based. In the case of ENUM, that obviously number-based. For the SIP redirect: does the redirect server expect a number in the user-part of the SIP AoR and looks that up in its routing table, or is this a decision based on the domain part of the URI? Consider e.g. the worst case +----VSP(o)-------+-----VSP(T)-------+---VSP(t)------+ +--Orig Domain----+--Transit Domain--+--Term Domain--+ | | +-----+ +-----+-----+ +-----+-----+ +-----+ |Proxy|----| SBC | SBC |------| SBC | SBC |---|Proxy| +-----+ +-----+-----+ +-----+-----+ +-----+ | | | | | | | | | | +-------+ | | | | Proxy | | +--+ +-------+ +--+ |UA| |UA| +--+ +--+ where a lot of boxes need to make routing decisions: Is there a single number->URI translation at the start of the call plus domain based routing decisions on the way, or is the whole process a sequence of number->URI mappings where the URIs vary in each step and just specify the next hop contact information? Thanks, /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 11:55:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrHm-00089l-14; Tue, 17 Oct 2006 11:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrHk-00089f-VP for speermint@ietf.org; Tue, 17 Oct 2006 11:55:20 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrHj-0007cA-KR for speermint@ietf.org; Tue, 17 Oct 2006 11:55:20 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9HFtEik009901; Tue, 17 Oct 2006 09:55:15 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Tue, 17 Oct 2006 09:55:13 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKorPAA== From: "Jean-Francois Mule" To: "Brian Rosen" , "Reinaldo Penno" , "Daryl Malas" , "David Schwartz" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Here is another try based on yesterday's dialogs:=20 --- Session peering 'policy' definition: "In the context of session peering, a policy is globally defined as the set of parameters and other information needed by one VSP/ASP to connect to another. Some of the session policy parameters may be statically exchanged and set throughout the lifetime of the peering relationship. Others parameters may be discovered and updated dynamically using by some explicit protocol mechanisms. These dynamic parameters may also relate to a VSP/ASP's session-dependent or session independent policies as defined in [ID-sipping-policy]. Notes: - this revised text injects the notions of 'static' vs. dynamic policy params Brian proposed; the addressing/routing is part of the session-dependent and session-independent policies of a domain (as you proposed Brian). - it links speermint's policy def (focused on inter-domain) with the sipping's def (focused on intra-domain) per Reinaldo's proposal. Thoughts? Good enough for now or not? Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 12:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrwL-0008Bj-Ng; Tue, 17 Oct 2006 12:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZrwK-0008Be-TM for speermint@ietf.org; Tue, 17 Oct 2006 12:37:16 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrwG-0004lZ-JQ for speermint@ietf.org; Tue, 17 Oct 2006 12:37:16 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 17 Oct 2006 09:34:41 -0700 X-IronPort-AV: i="4.09,321,1157353200"; d="scan'208"; a="595438418:sNHT33493080" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Policy Definition Date: Tue, 17 Oct 2006 12:37:13 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805CA9DD5@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKorPAAAFGKLg From: "Reinaldo Penno" To: "Jean-Francois Mule" , "Brian Rosen" , "Daryl Malas" , "David Schwartz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I believe when the SIPPING folks defined session-dependent and session-independent polcies they knew that static policies existed. When you sign a VoIP contract with a Cable providers there are static policies in place and when two VSPs peer they also sign a contract. It is no different, the question we need to ask is how much text real estate we need to give to static policies. Does a IETF WG need to care if there are policies driven by a contract? I wonder if there are similar considerations in Inter Domain Routing WG. Anyway, I just want to make it consistent with other IETF work. As far as the definition below, I do not believe it is "globally" defined. Not even static policies might be global. Many dynamic policies (whether session dependent or independent) are local to a specific peering point (assuming VSPs peer at more than one location) and/or even a proxy (calls per second, bw, etc). Thanks, Reinaldo > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Tuesday, October 17, 2006 8:55 AM > To: Brian Rosen; Reinaldo Penno; Daryl Malas; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > Here is another try based on yesterday's dialogs:=20 >=20 > --- Session peering 'policy' definition: > "In the context of session peering, a policy is globally=20 > defined as the set of parameters and other information needed=20 > by one VSP/ASP to connect to another. > Some of the session policy parameters may be statically=20 > exchanged and set throughout the lifetime of the peering=20 > relationship. Others parameters may be discovered and updated=20 > dynamically using by some explicit protocol mechanisms. These=20 > dynamic parameters may also relate to a VSP/ASP's=20 > session-dependent or session independent policies as defined=20 > in [ID-sipping-policy]. >=20 > Notes: > - this revised text injects the notions of 'static' vs.=20 > dynamic policy params Brian proposed; the addressing/routing=20 > is part of the session-dependent and session-independent=20 > policies of a domain (as you proposed Brian). > - it links speermint's policy def (focused on inter-domain)=20 > with the sipping's def (focused on intra-domain) per=20 > Reinaldo's proposal. >=20 > Thoughts? Good enough for now or not? >=20 > Jean-Francois. >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 17 14:02:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZtGQ-000549-10; Tue, 17 Oct 2006 14:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZtGN-00052X-Jn for speermint@ietf.org; Tue, 17 Oct 2006 14:02:03 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZtGI-0007Pa-Gc for speermint@ietf.org; Tue, 17 Oct 2006 14:02:03 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 3C82B4CC9; Tue, 17 Oct 2006 14:01:27 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:01:27 -0400 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] draft-uzelac-speermint-use-cases-oo.txt Date: Tue, 17 Oct 2006 14:01:25 -0400 Message-ID: In-Reply-To: <20061017155323.GL19113@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] draft-uzelac-speermint-use-cases-oo.txt Thread-Index: AcbyBGnOzYSDIcULSVex5kic+R+N+wAAsgeA From: "Uzelac, Adam" To: "Otmar Lendl" X-OriginalArrivalTime: 17 Oct 2006 18:01:27.0181 (UTC) FILETIME=[441113D0:01C6F216] X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar - Thanks for the comment. I am glad the draft helped. Answers to your questions...The input to the route determination are nearly always numbers. Numbers in the user-part specifically. The diagram you plucked out of the draft is bad, but it's not the worst. It's just the most common of the worst. SBCs are mostly on the Carrier's edges, not on the Enterprises. Once the B2BUA is prevalent on the Enterprise edge, the "worst case" would look MUCH worse. If nothing else, to me this shows that there should be some urgency around what SPEERMINT is attempting to address. We need to start derailing the momentum around this idiocy of back to back B2BUAs due to the transparency lost.=20 On that front - I recall a "Top 10 List" from Dean Willis on SIP Transparency across a B2BUA - I looked it up and here it is...It's something to think about I believe. 1) Dialog transparency: The call-ID is the same on "both sides" of the B2BUA. Proxies have this characteristic. A B2BUA that actually terminates a dialog on one side and generates a new dialog on the other doesn't. Some 3GPP AS functions fall into this category, as do 3PCC controllers. 2) Identity transparency: The user appears to have the same identity on both sides of the B2BUA. A proxy has this property. An identity anonymizer doesn't. 3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A traditional proxy has this property. A 3GPP P-CSCF does not, as it can generate a BYE message and then have to manage disjoint CSEQ spaces on each side. 4) Header transparency: The B2BUA doesn't change headers that transit it. Proxies have mostly this property, changing only a few headers that are specifically changed by the proxy function. Proxies don't change headers they don't understand. 3GPP "proxies" are likely to go to town changing all SORTS of headers. All with the best of intentions, mind you. 5) Body transparency: The MIME bodies on the SIP message are not altered by the B2BUA. Real SIP proxies have this property. Firewall proxies that modify SDP, and most everything in 3GPP, doesn't. 6) Media transparency: AS with body transparency, but considering only the media aspects. The 3GPP P-CSCF breaks this transparency rule by editing one's SDP to meet operator preferences. 7) Topology transparency. Via, Route, Record-Route, Path, P-Service-Route, and other headers that reveal topology are roughly the same on both sides of the B2BUA, save for any which uniquely identify that B2BUA. Proxies have this characteristic. Topology hiding devices like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP THIG don't. 8) Security transparency: The B2BUA doesn't alter security aspects, such as encryptions, authorization headers, etc. Proxies generally have this property, but 3GPP stuff doesn't. 9) Accounting transparency: Stuff used to generate records or track usage is not altered by a B2BUA with this property. Proxies have this property. 3GPP is trying to define a P-header (P-original-dialog-ID, I believe) to provide for accounting transparency across 3GPP AS elements operating at a low level of transparency. 10) Functional transparency: The task that the user of the UA wants to accomplish actually works across the B2BUA, rather than being blocked/distorted by it. proxies generally have this property, with the caveat the proxy can reject a request if needed. Some 3GPP entities can mutate functionality beyond all recognition. This is probably the single most important transparency concept. The rules of a "proxy" as defined in RFC3162 are there to preserve functional transparency, and anything that "breaks" those rules is likely to compromise functionality in some way. -AU -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at]=20 Sent: Tuesday, October 17, 2006 11:53 AM To: Uzelac, Adam Cc: speermint@ietf.org Subject: Re: [Speermint] draft-uzelac-speermint-use-cases-oo.txt On 2006/10/16 23:10, "Uzelac, Adam" wrote: > If you want to take a peak at some current practices (not the=20 > intentional omission of 'best') - see=20 > http://www.voiploser.com/misc/draft-uzelac-speermint-use-cases-oo.txt=20 > - I punted to I-D Action today, but after the 9am ET deadline for=20 > consideration in San Diego. :( I would still appreciate comments=20 > though. It's not pretty, but it's something to noodle on. Thanks Adam, this is a helpful document. Two questions: Within your descriptions, you often use the phrase The performs some next-hop determination for the called party. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. I'm wondering if these decisions are number or URI based. In the case of ENUM, that obviously number-based. For the SIP redirect: does the redirect server expect a number in the user-part of the SIP AoR and looks that up in its routing table, or is this a decision based on the domain part of the URI? Consider e.g. the worst case +----VSP(o)-------+-----VSP(T)-------+---VSP(t)------+=20 +--Orig Domain----+--Transit Domain--+--Term Domain--+=20 | |=20 +-----+ +-----+-----+ +-----+-----+ +-----+=20 |Proxy|----| SBC | SBC |------| SBC | SBC |---|Proxy|=20 +-----+ +-----+-----+ +-----+-----+ +-----+=20 | | | |=20 | | | |=20 | | +-------+ | |=20 | | Proxy | |=20 +--+ +-------+ +--+=20 |UA| |UA|=20 +--+ +--+=20 where a lot of boxes need to make routing decisions: Is there a single number->URI translation at the start of the call plus domain based routing decisions on the way, or is the whole process a sequence of number->URI mappings where the URIs vary in each step and just specify the next hop contact information?=20 Thanks, /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 03:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6B1-0005gq-Bq; Wed, 18 Oct 2006 03:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Az-0005gl-QE for speermint@ietf.org; Wed, 18 Oct 2006 03:49:21 -0400 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6Ap-0001kF-AA for speermint@ietf.org; Wed, 18 Oct 2006 03:49:21 -0400 Received: from sip.mah.priv.at ([81.223.16.194] helo=[192.168.1.80]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ga6AK-0002gs-J2; Wed, 18 Oct 2006 09:48:42 +0200 Message-ID: <4535DC4C.1090902@inode.at> Date: Wed, 18 Oct 2006 09:48:28 +0200 From: Michael Haberler User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jean-Francois Mule References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 81.223.16.194 X-SA-Exim-Mail-From: mah@inode.at X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.4 Subject: Re: [Speermint] Policy Definition X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jean-Francois - >> defined in >> the draft is for session dependent policy, but there is also a >> mechanism for >> session-independent policy that is also automated. I was after the >> distinction of something that needed a contract vs something that >> needed a protocol. >> > > As *you* proposed during the interim meeting, and most everyone seemed > to be ok, I thought we going to table the dynamic exchange of policies > for later. > yes, Brian proposed this. However, consensus in Philadelphia was to follow dynamic and static in parallel. So let's stick with that - especially since it's an option to go either route, and federation concepts and terminology are used throughout this WG. Frankly, I suggest we do aim a bit higher than just codifying the status quo. The static route is extinct in the backbone since the mid-nineties for good reason and telcos will eventually come around to that fact also in peering space. It would be most helpful if people actually try to weigh the effort needed to implement something along the lines of the dynamic peering drafts, visavis the ongoing operations nightmare of "static peering", OPEX, routing loops and all. And it would be also helpful to keep in mind that the results of this group are for operator use, yes, but not exclusively. I feel we're heading the "increasing success by lowering expectations" route here. -Michael ps: http://www.despair.com/viewall.html :-) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 07:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9bz-0007x4-Mw; Wed, 18 Oct 2006 07:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9by-0007wu-J0 for speermint@ietf.org; Wed, 18 Oct 2006 07:29:26 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga9bt-0004y6-A3 for speermint@ietf.org; Wed, 18 Oct 2006 07:29:26 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 622DB51910 for ; Wed, 18 Oct 2006 07:29:18 -0400 (EDT) Message-ID: <4536107C.1010707@pjsip.org> Date: Wed, 18 Oct 2006 12:31:08 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: speermint@ietf.org Subject: Re: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Internet-Drafts@ietf.org wrote: > Title : Use of DNS SRV and NAPTR Records for SPEERMINT > Author(s) : T. Creighton, G. Khandpur > Filename : draft-ietf-speermint-srv-naptr-use-00.txt Some comments. Talking from the point of view of a person who's just implemented SRV, I think I would welcome this document as additional information about how SRV should work, because frankly I was having difficulties in finding some information on the subject. But in general, I felt that probably we could add some "depths" into the information, or otherwise one might view this document as just stating the obvious (things like "everybody SHOULD implement highly scalable and fault-tolerant servers", without suggesting *how* one can achieve it). So probably the draft can say something, preferably with some SRV setting samples, about configuring SRV for this, considering the throughput desired, load-balancing, fail-over requirements, etc. Something like this probably: http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800a9818.shtml Another thing that we could add is how fail-over should happen in various SRV configurations, especially when both load-balancing and fail-over are used. For example, given the configuration below: ;; Priority Weight Port Target IN SRV 0 10 5060 sip1.example.com IN SRV 0 10 5060 sip2.example.com IN SRV 0 10 5060 sip3.example.com IN SRV 1 10 5060 sip4.example.com if sip1.example.com fails, then where should the client send the next request to? sip2/sip3, or sip4? IMO it's sip4. I think it's quite important to mention this, so that both sides of the network can expect the same behavior to happen in case of failures. And frankly I couldn't find a clear explanation for this anywhere, so I thought this document could be the best place to mention this. Last. In some places, probably it's best to just give pointer on how to get the information instead of duplicating the information. For example, in "3.1 TARGET Determination", probably it's best to just give pointer to relevant section in RFC 3261, because, for one thing, the target determination is a little bit more than that (for example, ";lr" parameter in Route header needs to be considered). Just my $0.02p. -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 09:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBs8-0006Nw-Aj; Wed, 18 Oct 2006 09:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBs7-0006Ks-1m for speermint@ietf.org; Wed, 18 Oct 2006 09:54:15 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBs1-0002lo-MZ for speermint@ietf.org; Wed, 18 Oct 2006 09:54:15 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6C4811A35F; Wed, 18 Oct 2006 15:54:08 +0200 (CEST) Date: Wed, 18 Oct 2006 15:54:08 +0200 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061018135408.GM19113@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , speermint@ietf.org References: <1160087883.16895.26.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1160087883.16895.26.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl, > peering requirements from one operators perspective. I can post these > to the list if you would like. Here is a list of peering requirements > (this is certainly not exhaustive, but is a platform): Here are my comments to that list: General: this seems to be a list providing details on what federations have to do (or agree on). > Transport (Layer 1 3): > > Peering must utilize IP as the primary mechanism for peering. > > A federation must agree upon a common mechanism for IP transport either > private (e.g. IPVPN, IPSEC, etc.) or public. Fine. > Billing: Good. > Policy: > Could you be a bit more specific on what you mean by "policy" in this context? > Policies may be implemented locally to the peer or via a centralized > mechanism within the federation. > > Local policies should be disclosed when creating direct peering > relationships with the applicable direct peer. > > Local policies may supersede centralized federation policies. > > (Net of this...some peering relationships will be 1:1, so policies will > likely be local only. Some peering relationships will be 1:N, so > policies will likely be implemented within DNS or some centralized > mechanism.) Could you provide some examples of such policies? > Membership: > > A peer may be a member of multiple federations > > A peer must maintain compliancy for policies as defined by each > federation the peer is a member of. > > If a peer is providing connectivity to multiple federations, it should > disclose AoRs providing indirect peering relationships to servicing > peers or federations. Sorry, I don't understand that sentence. Do you mean that when a VSP adds an AoR to a federations routing database, then it needs to discluse whether that is a direct customer or just a transit offer? > Peers providing indirect peering must enforce federation policies on > behalf of the destination federation. > > A peer providing indirect peering may enforce undisclosed policies for > processing session requests between federations. > > (Net of this...some peers will only desire to be part of a single > federation, where wholesale carriers will likely be members of multiple > federations.) ok. > Media: ok. > Routing: > > A peer must utilize the centralized federation routing mechanism if it > is available. ok. > A peer allowing another peer within a federation to provide indirect > peering on their behalf must select only one indirect peer to host their > AoRs. Do you mean indirect peering *within* a federation? Let me name the parties here: > A peer (X) allowing another peer (Y) within a federation (F1) to provide indirect > peering on their behalf must select only one indirect peer to host their > AoRs. Is the idea here that all members of F1 who want to place calls to X need to route the calls via Y? In that case, I would not consider X to be a member of F1. Instead, Y is providing transit services for X. Or you want to restrict X to be able to only select one other VSP to host it's AoRs in total? > A peer must not copy routing information from or make assumed routing > choices on behalf of the centralized routing mechanism for use locally > unless it takes place through standard caching methods. > > A common API must be utilized and available for subscriber and route > provisioning on any centralized federation location function. > > Subscriber and routing information must be dynamically updated as soon > as applicable for accurate routing within the federation. ok > Performance: > > Performance metrics must be shared between peers as they apply directly > to peering signaling and media on a consistent basis within the > federation. ok /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 10:10:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC6z-0003Bh-VQ; Wed, 18 Oct 2006 10:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC6y-0003Bc-VY for speermint@ietf.org; Wed, 18 Oct 2006 10:09:36 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaC6u-0005La-Ar for speermint@ietf.org; Wed, 18 Oct 2006 10:09:36 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: [Speermint] Basic Peering Requirements Date: Wed, 18 Oct 2006 16:04:32 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BA3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrj References: <1160087883.16895.26.camel@montag.eng.level3.com> <20061018135408.GM19113@nic.at> From: "Stastny Richard" To: "Otmar Lendl" , "Daryl Malas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >> If a peer is providing connectivity to multiple federations, it = should >> disclose AoRs providing indirect peering relationships to servicing >> peers or federations. >Sorry, I don't understand that sentence. >Do you mean that when a VSP adds an AoR to a federations routing >database, then it needs to discluse whether that is a direct customer >or just a transit offer? Sorry, but I do not understand the whole issue: =20 An AoR is a a special type of SIP URI (a Public User Identity) defining the destination network (administrative domain) =20 How can it be disclosed or not, especially for a transit network? It is always public. =20 Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Mi 18.10.2006 15:54 An: Daryl Malas Cc: speermint@ietf.org Betreff: Re: [Speermint] Basic Peering Requirements Daryl, > peering requirements from one operators perspective. I can post these > to the list if you would like. Here is a list of peering requirements > (this is certainly not exhaustive, but is a platform): Here are my comments to that list: General: this seems to be a list providing details on what federations have to do (or agree on). > Transport (Layer 1 3): > > Peering must utilize IP as the primary mechanism for peering. > > A federation must agree upon a common mechanism for IP transport = either > private (e.g. IPVPN, IPSEC, etc.) or public. Fine. > Billing: Good. > Policy: > Could you be a bit more specific on what you mean by "policy" in this context? > Policies may be implemented locally to the peer or via a centralized > mechanism within the federation. > > Local policies should be disclosed when creating direct peering > relationships with the applicable direct peer. > > Local policies may supersede centralized federation policies. > > (Net of this...some peering relationships will be 1:1, so policies = will > likely be local only. Some peering relationships will be 1:N, so > policies will likely be implemented within DNS or some centralized > mechanism.) Could you provide some examples of such policies? > Membership: > > A peer may be a member of multiple federations > > A peer must maintain compliancy for policies as defined by each > federation the peer is a member of. > > If a peer is providing connectivity to multiple federations, it should > disclose AoRs providing indirect peering relationships to servicing > peers or federations. Sorry, I don't understand that sentence. Do you mean that when a VSP adds an AoR to a federations routing database, then it needs to discluse whether that is a direct customer or just a transit offer? > Peers providing indirect peering must enforce federation policies on > behalf of the destination federation. > > A peer providing indirect peering may enforce undisclosed policies for > processing session requests between federations. > > (Net of this...some peers will only desire to be part of a single > federation, where wholesale carriers will likely be members of = multiple > federations.) ok. > Media: ok. > Routing: > > A peer must utilize the centralized federation routing mechanism if it > is available. ok. > A peer allowing another peer within a federation to provide indirect > peering on their behalf must select only one indirect peer to host = their > AoRs. Do you mean indirect peering *within* a federation? Let me name the parties here: > A peer (X) allowing another peer (Y) within a federation (F1) to = provide indirect > peering on their behalf must select only one indirect peer to host = their > AoRs. Is the idea here that all members of F1 who want to place calls to X need to route the calls via Y? In that case, I would not consider X to be a member of F1. Instead, Y is providing transit services for X. Or you want to restrict X to be able to only select one other VSP to host it's AoRs in total? > A peer must not copy routing information from or make assumed routing > choices on behalf of the centralized routing mechanism for use locally > unless it takes place through standard caching methods. > > A common API must be utilized and available for subscriber and route > provisioning on any centralized federation location function. > > Subscriber and routing information must be dynamically updated as soon > as applicable for accurate routing within the federation. ok > Performance: > > Performance metrics must be shared between peers as they apply = directly > to peering signaling and media on a consistent basis within the > federation. ok /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 From speermint-bounces@ietf.org Wed Oct 18 10:48:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCi1-00062j-5Q; Wed, 18 Oct 2006 10:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaChz-00062V-GP for speermint@ietf.org; Wed, 18 Oct 2006 10:47:51 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaChv-0003fM-4N for speermint@ietf.org; Wed, 18 Oct 2006 10:47:51 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9IEliJQ009295; Wed, 18 Oct 2006 08:47:44 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Wed, 18 Oct 2006 08:47:43 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKorPAAAFGKLgAC555cA= From: "Jean-Francois Mule" To: "Reinaldo Penno" , "Brian Rosen" , "Daryl Malas" , "David Schwartz" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo wrote: > I believe when the SIPPING folks defined session-dependent and > session-independent polcies they knew that static policies existed. > When > you sign a VoIP contract with a Cable providers there are static > policies in place and when two VSPs peer they also sign a contract. It > is no different, the question we need to ask is how much text real > estate we need to give to static policies. Does a IETF WG need to care > if there are policies driven by a contract? I wonder if there are > similar considerations in Inter Domain Routing WG. >=20 > Anyway, I just want to make it consistent with other IETF work. >=20 > As far as the definition below, I do not believe it is "globally" > defined. Not even static policies might be global. Many dynamic Ok, deleted "globally" > policies > (whether session dependent or independent) are local to a specific > peering point (assuming VSPs peer at more than one location) and/or > even > a proxy (calls per second, bw, etc). Any more specific comments on the policy def? Folks seem to be so focused on "static" vs. "dynamic", even when we are trying to define what is that 'thing' that could be statically or dynamically exchanged.=20 Jean-Francois. >=20 > Thanks, >=20 > Reinaldo >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Tuesday, October 17, 2006 8:55 AM > > To: Brian Rosen; Reinaldo Penno; Daryl Malas; David Schwartz > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > > > > Here is another try based on yesterday's dialogs: > > > > --- Session peering 'policy' definition: > > "In the context of session peering, a policy is globally > > defined as the set of parameters and other information needed > > by one VSP/ASP to connect to another. > > Some of the session policy parameters may be statically > > exchanged and set throughout the lifetime of the peering > > relationship. Others parameters may be discovered and updated > > dynamically using by some explicit protocol mechanisms. These > > dynamic parameters may also relate to a VSP/ASP's > > session-dependent or session independent policies as defined > > in [ID-sipping-policy]. > > > > Notes: > > - this revised text injects the notions of 'static' vs. > > dynamic policy params Brian proposed; the addressing/routing > > is part of the session-dependent and session-independent > > policies of a domain (as you proposed Brian). > > - it links speermint's policy def (focused on inter-domain) > > with the sipping's def (focused on intra-domain) per > > Reinaldo's proposal. > > > > Thoughts? Good enough for now or not? > > > > Jean-Francois. > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 10:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCsS-00031w-Iw; Wed, 18 Oct 2006 10:58:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCsQ-00031j-Oa for speermint@ietf.org; Wed, 18 Oct 2006 10:58:38 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCsO-0005ZE-Ci for speermint@ietf.org; Wed, 18 Oct 2006 10:58:38 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9IEwXkm012816; Wed, 18 Oct 2006 08:58:34 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Policy Definition Date: Wed, 18 Oct 2006 08:58:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: Acbyid6DVQ2Y4DCCTcaJ4ULR7cQptgAOri9A From: "Jean-Francois Mule" To: "Michael Haberler" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael, Sure. To be clear, I'm all for having more dynamism - this is not the point. The point is to try to describe what folks believe should be exchanged between 2 domains to do L5 peering: discuss the "what" first, not the "how". This is what Omar and I discussed live this week.=20 Whether you extract some VSP/ASP domain policy params from a web page, a contract agreement, an EULA contained in a soft app, a SIP subscribe/notify exchange, or a DNS DDDS app, it seems that we should grasp what that 'thing' is. This will lead to requirement discussions that could feed protocol mechanisms (right now, it seems reversed). Jean-Francois. > -----Original Message----- > From: Michael Haberler [mailto:mah@inode.at] > Sent: Wednesday, October 18, 2006 1:48 AM > To: Jean-Francois Mule > Cc: Brian Rosen; speermint@ietf.org > Subject: Re: [Speermint] Policy Definition >=20 > Jean-Francois - > >> defined in > >> the draft is for session dependent policy, but there is also a > >> mechanism for > >> session-independent policy that is also automated. I was after the > >> distinction of something that needed a contract vs something that > >> needed a protocol. > >> > > > > As *you* proposed during the interim meeting, and most everyone > seemed > > to be ok, I thought we going to table the dynamic exchange of > policies > > for later. > > > yes, Brian proposed this. >=20 > However, consensus in Philadelphia was to follow dynamic and static in > parallel. So let's stick with that - especially since it's an option > to > go either route, and federation concepts and terminology are used > throughout this WG. >=20 > Frankly, I suggest we do aim a bit higher than just codifying the > status > quo. The static route is extinct in the backbone since the mid- > nineties > for good reason and telcos will eventually come around to that fact > also in peering space. >=20 > It would be most helpful if people actually try to weigh the effort > needed to implement something along the lines of the dynamic peering > drafts, visavis the ongoing operations nightmare of "static peering", > OPEX, routing loops and all. And it would be also helpful to keep in > mind that the results of this group are for operator use, yes, but not > exclusively. >=20 > I feel we're heading the "increasing success by lowering expectations" > route here. >=20 > -Michael >=20 > ps: http://www.despair.com/viewall.html :-) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 11:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDD-0004eq-2u; Wed, 18 Oct 2006 11:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDB-0004dP-7e for speermint@ietf.org; Wed, 18 Oct 2006 11:20:05 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaD7W-0000jw-0a for speermint@ietf.org; Wed, 18 Oct 2006 11:14:18 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9IFEBcx013101; Wed, 18 Oct 2006 15:14:11 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Otmar Lendl In-Reply-To: <20061018135408.GM19113@nic.at> References: <1160087883.16895.26.camel@montag.eng.level3.com> <20061018135408.GM19113@nic.at> Content-Type: text/plain Date: Wed, 18 Oct 2006 09:16:23 -0600 Message-Id: <1161184583.16895.117.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Wed, 2006-10-18 at 15:54 +0200, Otmar Lendl wrote: > Daryl, > > > peering requirements from one operators perspective. I can post these > > to the list if you would like. Here is a list of peering requirements > > (this is certainly not exhaustive, but is a platform): > > Here are my comments to that list: > > General: this seems to be a list providing details on what federations > have to do (or agree on). > > > Transport (Layer 1 3): > > > > Peering must utilize IP as the primary mechanism for peering. > > > > A federation must agree upon a common mechanism for IP transport either > > private (e.g. IPVPN, IPSEC, etc.) or public. > > Fine. > > > Billing: > > Good. > > > Policy: > > > > Could you be a bit more specific on what you mean by "policy" in this > context? IMO, a policy is a restriction of potential possibilities based on a broadly defined SIP, media, and/or business service provided by the destination peer or federation. The mechanism for delivering the notification of these restrictions may be static and/or dynamic. > > > > Policies may be implemented locally to the peer or via a centralized > > mechanism within the federation. > > > > Local policies should be disclosed when creating direct peering > > relationships with the applicable direct peer. > > > > Local policies may supersede centralized federation policies. > > > > (Net of this...some peering relationships will be 1:1, so policies will > > likely be local only. Some peering relationships will be 1:N, so > > policies will likely be implemented within DNS or some centralized > > mechanism.) > > Could you provide some examples of such policies? These were my thoughts from a previous thread discussion on this: 1. Only 'X' CODEC(s) will be supported into federation B or Peer A's network. 2. Only 'n' number of peering sessions will be allowed at any given time. 3. Peer A will only support these 'X' SIP headers and methods (extensions) via peering requests (In other words an Operator may not support Redirect in and out of a federation...it's simply an example.) --This one brings up an interesting aspect. It might be noted a UAC could send an OPTIONS message to a federation or peer to understand some of these supported "aspects", but these will also likely be negotiated up front." 4. (Adam added) 'x' number of sessions per second transaction rate. > > > Membership: > > > > A peer may be a member of multiple federations > > > > A peer must maintain compliancy for policies as defined by each > > federation the peer is a member of. > > > > If a peer is providing connectivity to multiple federations, it should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > Sorry, I don't understand that sentence. > > Do you mean that when a VSP adds an AoR to a federations routing > database, then it needs to discluse whether that is a direct customer > or just a transit offer? Yes > > > Peers providing indirect peering must enforce federation policies on > > behalf of the destination federation. > > > > A peer providing indirect peering may enforce undisclosed policies for > > processing session requests between federations. > > > > (Net of this...some peers will only desire to be part of a single > > federation, where wholesale carriers will likely be members of multiple > > federations.) > > ok. > > > Media: > > ok. > > > Routing: > > > > A peer must utilize the centralized federation routing mechanism if it > > is available. > > ok. > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host their > > AoRs. > > Do you mean indirect peering *within* a federation? Let me name the > parties here: > > > A peer (X) allowing another peer (Y) within a federation (F1) to provide indirect > > peering on their behalf must select only one indirect peer to host their > > AoRs. > > Is the idea here that all members of F1 who want to place calls to X > need to route the calls via Y? In that case, I would not consider > X to be a member of F1. Instead, Y is providing transit services > for X. Your assumption is correct, X is not a member of F1. They can only specify to allow Y (and not A, B, C, and D) to provide indirect peering within F1. > > Or you want to restrict X to be able to only select one other > VSP to host it's AoRs in total? Yes > > > A peer must not copy routing information from or make assumed routing > > choices on behalf of the centralized routing mechanism for use locally > > unless it takes place through standard caching methods. > > > > A common API must be utilized and available for subscriber and route > > provisioning on any centralized federation location function. > > > > Subscriber and routing information must be dynamically updated as soon > > as applicable for accurate routing within the federation. > > ok > > > Performance: > > > > Performance metrics must be shared between peers as they apply directly > > to peering signaling and media on a consistent basis within the > > federation. > > ok > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 11:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDN-0004jR-DA; Wed, 18 Oct 2006 11:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDL-0004ij-Lz for speermint@ietf.org; Wed, 18 Oct 2006 11:20:15 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaD2u-0000Bj-4U for speermint@ietf.org; Wed, 18 Oct 2006 11:09:29 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaD2i-0007Um-6O; Wed, 18 Oct 2006 10:09:17 -0500 From: "Brian Rosen" To: "'Jean-Francois Mule'" , "'Reinaldo Penno'" , "'Daryl Malas'" , "'David Schwartz'" Subject: RE: [Speermint] Policy Definition Date: Wed, 18 Oct 2006 11:09:18 -0400 Message-ID: <005701c6f2c7$6414db60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKorPAAA0Z4zg In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I can live with this. I do think we are probably at the point where more fine grained chopping of language is not going to help. I would like to ask, though, about scope. There is often the problem of scope creep, and I'd like to limit scope whenever possible. Consider the notion of dynamic policies, and the session dependent. Is session dependent in scope? Do we really want to consider, in this charter incarnation, the idea that from call to call, policies change? I DO want to consider policy that changes (i.e. dynamic), albeit I'm pretty sure we want to do a "Version 1" that doesn't do that first. The question is whether we literally want to have policies that change per session. I can see some use of that. For example, use THIS gateway if you need >256K of bandwidth, and THAT gateway if you need less. However, I think we get a whole lot done before those kinds of issues come up. So, I can see a policy changing between two calls, so that one call uses the old policy and the next one uses the new policy. What I don't see in scope is the session dependent policy the sipping work discusses, at least within our current work. That doesn't mean a change in definition. Actually, the definition helps, because I precisely want to say that session-dependent policy is out of scope for now. Brian > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, October 17, 2006 11:55 AM > To: Brian Rosen; Reinaldo Penno; Daryl Malas; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition > > Here is another try based on yesterday's dialogs: > > --- Session peering 'policy' definition: > "In the context of session peering, a policy is globally defined as the > set of parameters and other information needed by one VSP/ASP to connect > to another. > Some of the session policy parameters may be statically exchanged and > set throughout the lifetime of the peering relationship. Others > parameters may be discovered and updated dynamically using by some > explicit protocol mechanisms. These dynamic parameters may also relate > to a VSP/ASP's session-dependent or session independent policies as > defined in [ID-sipping-policy]. > > Notes: > - this revised text injects the notions of 'static' vs. dynamic policy > params Brian proposed; the addressing/routing is part of the > session-dependent and session-independent policies of a domain (as you > proposed Brian). > - it links speermint's policy def (focused on inter-domain) with the > sipping's def (focused on intra-domain) per Reinaldo's proposal. > > Thoughts? Good enough for now or not? > > Jean-Francois. > > > > _______________________________________________ > 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 From speermint-bounces@ietf.org Wed Oct 18 11:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDD-0004eq-2u; Wed, 18 Oct 2006 11:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDB-0004dP-7e for speermint@ietf.org; Wed, 18 Oct 2006 11:20:05 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaD7W-0000jw-0a for speermint@ietf.org; Wed, 18 Oct 2006 11:14:18 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9IFEBcx013101; Wed, 18 Oct 2006 15:14:11 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Otmar Lendl In-Reply-To: <20061018135408.GM19113@nic.at> References: <1160087883.16895.26.camel@montag.eng.level3.com> <20061018135408.GM19113@nic.at> Content-Type: text/plain Date: Wed, 18 Oct 2006 09:16:23 -0600 Message-Id: <1161184583.16895.117.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Wed, 2006-10-18 at 15:54 +0200, Otmar Lendl wrote: > Daryl, > > > peering requirements from one operators perspective. I can post these > > to the list if you would like. Here is a list of peering requirements > > (this is certainly not exhaustive, but is a platform): > > Here are my comments to that list: > > General: this seems to be a list providing details on what federations > have to do (or agree on). > > > Transport (Layer 1 3): > > > > Peering must utilize IP as the primary mechanism for peering. > > > > A federation must agree upon a common mechanism for IP transport either > > private (e.g. IPVPN, IPSEC, etc.) or public. > > Fine. > > > Billing: > > Good. > > > Policy: > > > > Could you be a bit more specific on what you mean by "policy" in this > context? IMO, a policy is a restriction of potential possibilities based on a broadly defined SIP, media, and/or business service provided by the destination peer or federation. The mechanism for delivering the notification of these restrictions may be static and/or dynamic. > > > > Policies may be implemented locally to the peer or via a centralized > > mechanism within the federation. > > > > Local policies should be disclosed when creating direct peering > > relationships with the applicable direct peer. > > > > Local policies may supersede centralized federation policies. > > > > (Net of this...some peering relationships will be 1:1, so policies will > > likely be local only. Some peering relationships will be 1:N, so > > policies will likely be implemented within DNS or some centralized > > mechanism.) > > Could you provide some examples of such policies? These were my thoughts from a previous thread discussion on this: 1. Only 'X' CODEC(s) will be supported into federation B or Peer A's network. 2. Only 'n' number of peering sessions will be allowed at any given time. 3. Peer A will only support these 'X' SIP headers and methods (extensions) via peering requests (In other words an Operator may not support Redirect in and out of a federation...it's simply an example.) --This one brings up an interesting aspect. It might be noted a UAC could send an OPTIONS message to a federation or peer to understand some of these supported "aspects", but these will also likely be negotiated up front." 4. (Adam added) 'x' number of sessions per second transaction rate. > > > Membership: > > > > A peer may be a member of multiple federations > > > > A peer must maintain compliancy for policies as defined by each > > federation the peer is a member of. > > > > If a peer is providing connectivity to multiple federations, it should > > disclose AoRs providing indirect peering relationships to servicing > > peers or federations. > > Sorry, I don't understand that sentence. > > Do you mean that when a VSP adds an AoR to a federations routing > database, then it needs to discluse whether that is a direct customer > or just a transit offer? Yes > > > Peers providing indirect peering must enforce federation policies on > > behalf of the destination federation. > > > > A peer providing indirect peering may enforce undisclosed policies for > > processing session requests between federations. > > > > (Net of this...some peers will only desire to be part of a single > > federation, where wholesale carriers will likely be members of multiple > > federations.) > > ok. > > > Media: > > ok. > > > Routing: > > > > A peer must utilize the centralized federation routing mechanism if it > > is available. > > ok. > > > A peer allowing another peer within a federation to provide indirect > > peering on their behalf must select only one indirect peer to host their > > AoRs. > > Do you mean indirect peering *within* a federation? Let me name the > parties here: > > > A peer (X) allowing another peer (Y) within a federation (F1) to provide indirect > > peering on their behalf must select only one indirect peer to host their > > AoRs. > > Is the idea here that all members of F1 who want to place calls to X > need to route the calls via Y? In that case, I would not consider > X to be a member of F1. Instead, Y is providing transit services > for X. Your assumption is correct, X is not a member of F1. They can only specify to allow Y (and not A, B, C, and D) to provide indirect peering within F1. > > Or you want to restrict X to be able to only select one other > VSP to host it's AoRs in total? Yes > > > A peer must not copy routing information from or make assumed routing > > choices on behalf of the centralized routing mechanism for use locally > > unless it takes place through standard caching methods. > > > > A common API must be utilized and available for subscriber and route > > provisioning on any centralized federation location function. > > > > Subscriber and routing information must be dynamically updated as soon > > as applicable for accurate routing within the federation. > > ok > > > Performance: > > > > Performance metrics must be shared between peers as they apply directly > > to peering signaling and media on a consistent basis within the > > federation. > > ok > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 11:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDN-0004jR-DA; Wed, 18 Oct 2006 11:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDL-0004ij-Lz for speermint@ietf.org; Wed, 18 Oct 2006 11:20:15 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaD2u-0000Bj-4U for speermint@ietf.org; Wed, 18 Oct 2006 11:09:29 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaD2i-0007Um-6O; Wed, 18 Oct 2006 10:09:17 -0500 From: "Brian Rosen" To: "'Jean-Francois Mule'" , "'Reinaldo Penno'" , "'Daryl Malas'" , "'David Schwartz'" Subject: RE: [Speermint] Policy Definition Date: Wed, 18 Oct 2006 11:09:18 -0400 Message-ID: <005701c6f2c7$6414db60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKorPAAA0Z4zg In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I can live with this. I do think we are probably at the point where more fine grained chopping of language is not going to help. I would like to ask, though, about scope. There is often the problem of scope creep, and I'd like to limit scope whenever possible. Consider the notion of dynamic policies, and the session dependent. Is session dependent in scope? Do we really want to consider, in this charter incarnation, the idea that from call to call, policies change? I DO want to consider policy that changes (i.e. dynamic), albeit I'm pretty sure we want to do a "Version 1" that doesn't do that first. The question is whether we literally want to have policies that change per session. I can see some use of that. For example, use THIS gateway if you need >256K of bandwidth, and THAT gateway if you need less. However, I think we get a whole lot done before those kinds of issues come up. So, I can see a policy changing between two calls, so that one call uses the old policy and the next one uses the new policy. What I don't see in scope is the session dependent policy the sipping work discusses, at least within our current work. That doesn't mean a change in definition. Actually, the definition helps, because I precisely want to say that session-dependent policy is out of scope for now. Brian > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, October 17, 2006 11:55 AM > To: Brian Rosen; Reinaldo Penno; Daryl Malas; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition > > Here is another try based on yesterday's dialogs: > > --- Session peering 'policy' definition: > "In the context of session peering, a policy is globally defined as the > set of parameters and other information needed by one VSP/ASP to connect > to another. > Some of the session policy parameters may be statically exchanged and > set throughout the lifetime of the peering relationship. Others > parameters may be discovered and updated dynamically using by some > explicit protocol mechanisms. These dynamic parameters may also relate > to a VSP/ASP's session-dependent or session independent policies as > defined in [ID-sipping-policy]. > > Notes: > - this revised text injects the notions of 'static' vs. dynamic policy > params Brian proposed; the addressing/routing is part of the > session-dependent and session-independent policies of a domain (as you > proposed Brian). > - it links speermint's policy def (focused on inter-domain) with the > sipping's def (focused on intra-domain) per Reinaldo's proposal. > > Thoughts? Good enough for now or not? > > Jean-Francois. > > > > _______________________________________________ > 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 From speermint-bounces@ietf.org Wed Oct 18 11:23:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDGc-0000Qr-9L; Wed, 18 Oct 2006 11:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDGb-0000Mt-8o for speermint@ietf.org; Wed, 18 Oct 2006 11:23:37 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDGW-0003QO-TI for speermint@ietf.org; Wed, 18 Oct 2006 11:23:37 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id BEAF11A35F; Wed, 18 Oct 2006 17:23:31 +0200 (CEST) Date: Wed, 18 Oct 2006 17:23:31 +0200 From: Otmar Lendl To: Daryl Malas Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061018152331.GO15701@nic.at> Mail-Followup-To: Otmar Lendl , Daryl Malas , speermint@ietf.org References: <1160087883.16895.26.camel@montag.eng.level3.com> <20061018135408.GM19113@nic.at> <1161184583.16895.117.camel@montag.eng.level3.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1161184583.16895.117.camel@montag.eng.level3.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/18 17:10, Daryl Malas wrote: > On Wed, 2006-10-18 at 15:54 +0200, Otmar Lendl wrote: > > > A peer allowing another peer within a federation to provide indirect > > > peering on their behalf must select only one indirect peer to host their > > > AoRs. > > > > Do you mean indirect peering *within* a federation? Let me name the > > parties here: > > > > > A peer (X) allowing another peer (Y) within a federation (F1) to provide indirect > > > peering on their behalf must select only one indirect peer to host their > > > AoRs. > > > > Is the idea here that all members of F1 who want to place calls to X > > need to route the calls via Y? In that case, I would not consider > > X to be a member of F1. Instead, Y is providing transit services > > for X. > > Your assumption is correct, X is not a member of F1. They can only > specify to allow Y (and not A, B, C, and D) to provide indirect peering > within F1. > > > Or you want to restrict X to be able to only select one other > > VSP to host it's AoRs in total? > > Yes > How does multihoming (e.g. a small VSP which wants to by upstream services from multiple transit VSPs) fit into that scheme? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 12:00:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDpT-0001Xc-Ij; Wed, 18 Oct 2006 11:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDpS-0000v7-7m for speermint@ietf.org; Wed, 18 Oct 2006 11:59:38 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDk6-0001vx-So for speermint@ietf.org; Wed, 18 Oct 2006 11:54:08 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9IFrfcx017598; Wed, 18 Oct 2006 15:53:42 GMT Subject: Re: [Speermint] Basic Peering Requirements From: Daryl Malas To: Otmar Lendl In-Reply-To: <20061018152331.GO15701@nic.at> References: <1160087883.16895.26.camel@montag.eng.level3.com> <20061018135408.GM19113@nic.at> <1161184583.16895.117.camel@montag.eng.level3.com> <20061018152331.GO15701@nic.at> Content-Type: text/plain Date: Wed, 18 Oct 2006 09:55:55 -0600 Message-Id: <1161186955.16895.124.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Wed, 2006-10-18 at 17:23 +0200, Otmar Lendl wrote: > On 2006/10/18 17:10, Daryl Malas wrote: > > On Wed, 2006-10-18 at 15:54 +0200, Otmar Lendl wrote: > > > > > A peer allowing another peer within a federation to provide indirect > > > > peering on their behalf must select only one indirect peer to host their > > > > AoRs. > > > > > > Do you mean indirect peering *within* a federation? Let me name the > > > parties here: > > > > > > > A peer (X) allowing another peer (Y) within a federation (F1) to provide indirect > > > > peering on their behalf must select only one indirect peer to host their > > > > AoRs. > > > > > > Is the idea here that all members of F1 who want to place calls to X > > > need to route the calls via Y? In that case, I would not consider > > > X to be a member of F1. Instead, Y is providing transit services > > > for X. > > > > Your assumption is correct, X is not a member of F1. They can only > > specify to allow Y (and not A, B, C, and D) to provide indirect peering > > within F1. > > > > > Or you want to restrict X to be able to only select one other > > > VSP to host it's AoRs in total? > > > > Yes > > > > How does multihoming (e.g. a small VSP which wants to by upstream services > from multiple transit VSPs) fit into that scheme? Again, I talked about this in a previous thread. A small VSP can be multi-homed to a single transit VSP (e.g. multiple SF's). They will also likely be connected "indirectly" to multiple federations, which also may be contracted to provide an indirect route back to this federation through one of the peers. I think this simplifies it greatly. If we must, then I suggest a maximum of two peers in a federation may provide indirect peering to an external VSP. > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 12:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaE9A-0004xd-Kc; Wed, 18 Oct 2006 12:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaE5d-0003AB-Bc for speermint@ietf.org; Wed, 18 Oct 2006 12:16:21 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDs2-0004vL-Dh for speermint@ietf.org; Wed, 18 Oct 2006 12:02:28 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9IG2HRp003048 for ; Wed, 18 Oct 2006 10:02:17 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Speermint] Requirement(s) for call routing addressing data variability (was: RE: [Speermint] Basic Peering Requirements) Date: Wed, 18 Oct 2006 10:02:16 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirement(s) for call routing addressing data variability (was: RE: [Speermint] Basic Peering Requirements) Thread-Index: Acbxx36L4KiANQt2TcyiHmhLzkXZnABAAj9w From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar wrote: > I still think we need to work out and then nail down what the > requirements are for the routing decisions which we face in > the speermint context. Daryl wrote: > | From what I have gleaned from network operators, they do want to > | tell their peering partners (independently of other peerings) quite > | explicitely to which ingress point they should connect to. Brian wrote: > Mostly, I see federations allowing per peer-pair variability in their > registry, whether it's an ENUM database, a SIP redirect, a SIP Forward > or > some other mechanism. The result is the same, for a given peer as > origination to a specific peer as termination, a specific (list of) > proxy > server domain name(s) is provided. Usually, there aren't n squared > values, > but in theory there could be. I would like to capture a few requirements here using the updated terminology available in draft-ietf-speermint-terminology-06.txt. This discussion is about the call addressing data and its variability depending on: - how the data is acquired:=20 the originator of the ENUM query, the target e.164 address =3D> this = seems to do with the acquisition of call addressing data (or LF in the proposed architecture): this is out of scope of speermint I think; - how it is resolved: How the call routing data elements are resolved the resolution of that call addressing data into something that leads to the establishment of a sip session (relates to PF, SF). This is where I believe we should develop those requirements. =3D=3D> this dichotomy seems reductive but it is somewhat imposed by the = way we've looked at things so far. Is this a correct interpretation of what's discussed here? If so, are the following requirements capturing what you meant above? Any help in improving these to cover the cases you mentioned is appreciated. - A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP/user Another high-level design guideline could be: - The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability/customization depending on various factors, such as the identity of the originating or terminating peers. Comments appreciated. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 12:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEF4-0005nn-GG; Wed, 18 Oct 2006 12:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEF3-0005nf-T8 for speermint@ietf.org; Wed, 18 Oct 2006 12:26:05 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaEEv-0001k4-78 for speermint@ietf.org; Wed, 18 Oct 2006 12:26:05 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1161188755!14330374!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30638 invoked from network); 18 Oct 2006 16:25:55 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-12.tower-120.messagelabs.com with SMTP; 18 Oct 2006 16:25:55 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9IGPs6j004700 for ; Wed, 18 Oct 2006 12:25:55 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9IGP6OA004244 for ; Wed, 18 Oct 2006 12:25:48 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C330008072F; Wed, 18 Oct 2006 12:25:47 -0400 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] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Date: Wed, 18 Oct 2006 12:25:45 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DE726C3@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Thread-Index: Acbxx36L4KiANQt2TcyiHmhLzkXZnABAAj9wAAKciOA= From: "Pfautz, Penn L, GBLAM" To: "Jean-Francois Mule" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes, I think this captures an important need. Penn Pfautz=20 -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Wednesday, October 18, 2006 12:02 PM To: speermint@ietf.org Subject: [Speermint] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Otmar wrote: > I still think we need to work out and then nail down what the > requirements are for the routing decisions which we face in > the speermint context. Daryl wrote: > | From what I have gleaned from network operators, they do want to > | tell their peering partners (independently of other peerings) quite > | explicitely to which ingress point they should connect to. Brian wrote: > Mostly, I see federations allowing per peer-pair variability in their > registry, whether it's an ENUM database, a SIP redirect, a SIP Forward > or > some other mechanism. The result is the same, for a given peer as > origination to a specific peer as termination, a specific (list of) > proxy > server domain name(s) is provided. Usually, there aren't n squared > values, > but in theory there could be. I would like to capture a few requirements here using the updated terminology available in draft-ietf-speermint-terminology-06.txt. This discussion is about the call addressing data and its variability depending on: - how the data is acquired:=20 the originator of the ENUM query, the target e.164 address =3D> this = seems to do with the acquisition of call addressing data (or LF in the proposed architecture): this is out of scope of speermint I think; - how it is resolved: How the call routing data elements are resolved the resolution of that call addressing data into something that leads to the establishment of a sip session (relates to PF, SF). This is where I believe we should develop those requirements. =3D=3D> this dichotomy seems reductive but it is somewhat imposed by the = way we've looked at things so far. Is this a correct interpretation of what's discussed here? If so, are the following requirements capturing what you meant above? Any help in improving these to cover the cases you mentioned is appreciated. - A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP/user Another high-level design guideline could be: - The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability/customization depending on various factors, such as the identity of the originating or terminating peers. Comments appreciated. Jean-Francois. _______________________________________________ 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 From speermint-bounces@ietf.org Wed Oct 18 12:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEdF-0005UZ-Ko; Wed, 18 Oct 2006 12:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEdE-0005UU-VR for speermint@ietf.org; Wed, 18 Oct 2006 12:51:04 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEd8-0007Fc-EL for speermint@ietf.org; Wed, 18 Oct 2006 12:51:04 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 59C011A35F; Wed, 18 Oct 2006 18:50:48 +0200 (CEST) Date: Wed, 18 Oct 2006 18:50:48 +0200 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20061018165048.GN19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Speermint] Summary: domain policy drafts X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jean-Francois asked me to give a quick summary to the list what kind of parameters can be fetched using the mechanisms proposed in draft-lendl-domain-policy-ddds-02 and the companion drafts. The main draft "draft-lendl-domain-policy-ddds-02" describes a framework with which a VSP can use DNS entries in its domain to announce requirements this VSP places on incoming communications. That draft does not specify what such requirements can be. Such individual requirements ("atomic policy rules") are defined in other drafts. The main draft defines the generic DNS algorithm which just explains the processing order and the boolean operations to be performed on these individual rules. Individual rules are denoted as URIs. Generally speaking, two basic types of atomic policy rules are possible: a) Referrals to external, possible offline documents. No automatic parsing possible. Will be configured as "ok, I can do that" by hand. Example: Federation membership These are called "Notifications" in the draft. b) Technical requirements. Automatic realtime parsing is possible. Could be configured e.g. in the default settings of a SIP proxy. These are called "Publication" in the draft. There are two ways of encoding such rechnical requirements in URIs: b1) By value: E.g. as defined in draft-lendl-speermint-technical-policy-00 where standards are indicated in the URI (as their urn:ietf:rfc:...) identifier. b2) By reference: (No draft describes this yet, draft-lendl-domain-policy-ddds-02 contains an example for SAML documents, though.) In that case, the atomic policy URI is in fact an URL which points to a complex requirements specification. Usage: ------ Initially, I expect only the federation announcements (as defined in draft-lendl-speermint-federations-03) to be used. This is of type a) and thus does not list any of the actual parameters used within that federation. What rules federations will come up with for their internal use is irrelevant to the domain policy DDDS algorithm. The DNS just enables the discovery of the list of federation a VSP is member of. Regarding technical policies: draft-lendl-speermint-technical-policy-00 defines how RFCs, I-Ds and other standards can be referenced. I expect the following initial use-cases: * TLS CA-list The URI contains a list of CAs where one of them needs to have signed the TLS key of the calling SIP proxy. (There is no defined URI format for that yet.) * SIP identity The caller needs to provide a signed identity (draft-ietf-sip-identity-06) in INVITEs. This might be combined with the previous one to define a list of accepted CAs for these identities. * P-* header support VSPs which have pstn-like user terminals might require peering partners to use some of the P- headers to support the transmission of a number-based caller-id, cnam information and perhaps privacy settings. * SRTP requirements Some VSP might want to accept only calls providing a secure media transport as well. The policy rule could be the RFC or ID of the key exchange algorithm used. * IPsec parameters Instead of TLS, IPsec parameters (key exchange) could also be one possible requirement. * Peering Event package Peers need to subscribe to the peering event package before INVITES will be accepted from them. * Other authentication schemes There were some proposals out there that peers need to "REGISTER" with peering partners before calls can be completed. ----------- Federation internal ideas: Daryl's list is a good start on what federation internal rules might contain, here are some from the top of my head: * Which IP network to use (VPNs, walled gardens, open internet, ...) * How to locate the ingress point (Static configuration? Private DNS?, ev. prefixes in public DNS?, Federation's location server?) * What credentials to use to authenticate at the peer's SIP proxy * Conventions on caller-ID (e.g. how to transmit numbers) * Codec support * Settlement * Call-rate and bandwidth limits * Security arrangements (tls, srtp, ...) * regulatory stuff (calea, e911, ...) * Contractual issues (liabilities, cancellation terms, ...) * Abuse and fraud handling * Quality assurance, trouble-shooting procedures * Supported media (video, presence, IM?) * Supported features (ring back on busy, DND, ...) * Rules concerning the use of SBCs (Most of these rules are not suitable for automatic discovery and thus will never show up in "technical restriction" domain policy DDDS records.) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 12:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEjA-0001tJ-WA; Wed, 18 Oct 2006 12:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEj9-0001t9-SF for speermint@ietf.org; Wed, 18 Oct 2006 12:57:11 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEj4-0000EX-3t for speermint@ietf.org; Wed, 18 Oct 2006 12:57:11 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id A6CD33A54; Wed, 18 Oct 2006 12:56:35 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 12:56:35 -0400 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] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Date: Wed, 18 Oct 2006 12:56:34 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Thread-Index: Acbxx36L4KiANQt2TcyiHmhLzkXZnABAAj9wAAL+IeA= From: "Uzelac, Adam" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 18 Oct 2006 16:56:35.0385 (UTC) FILETIME=[5EC9E290:01C6F2D6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jean-Francois - well done shifting through all the noise to get at the key requirements across 3 different voices! =20 Couple comments: - I need to ask why you think the LF function is out of scope? Are you thinking that it's out of scope for speermint, but in scope for ENUM/DNS? =20 - I also think the comment about how call addressing data is acquired is via user input - regardless if it is E.164 or an URI. It's not really an issue as the session has to start somewhere with something. It's the resolving of the data input that needs the attention both in speermint/ENUM/DNS/SIP/etc. Otmar - requirements for the routing decisions Daryl - Operators maintaining control of how sessions ingress to them Brian - specific list of proxy server domain names between peers None of these, from what I can glean, have anything to do with how the data is acquired - only the resolution once data is available. -AU -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Wednesday, October 18, 2006 12:02 PM To: speermint@ietf.org Subject: [Speermint] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Otmar wrote: > I still think we need to work out and then nail down what the=20 > requirements are for the routing decisions which we face in the=20 > speermint context. Daryl wrote: > | From what I have gleaned from network operators, they do want to=20 > | tell their peering partners (independently of other peerings) quite=20 > | explicitely to which ingress point they should connect to. Brian wrote: > Mostly, I see federations allowing per peer-pair variability in their=20 > registry, whether it's an ENUM database, a SIP redirect, a SIP Forward > or some other mechanism. The result is the same, for a given peer as=20 > origination to a specific peer as termination, a specific (list of)=20 > proxy server domain name(s) is provided. Usually, there aren't n=20 > squared values, but in theory there could be. I would like to capture a few requirements here using the updated terminology available in draft-ietf-speermint-terminology-06.txt. This discussion is about the call addressing data and its variability depending on: - how the data is acquired:=20 the originator of the ENUM query, the target e.164 address =3D> this = seems to do with the acquisition of call addressing data (or LF in the proposed architecture): this is out of scope of speermint I think; - how it is resolved: How the call routing data elements are resolved the resolution of that call addressing data into something that leads to the establishment of a sip session (relates to PF, SF). This is where I believe we should develop those requirements. =3D=3D> this dichotomy seems reductive but it is somewhat imposed by the = way we've looked at things so far. Is this a correct interpretation of what's discussed here? If so, are the following requirements capturing what you meant above? Any help in improving these to cover the cases you mentioned is appreciated. - A terminating VSP/ASP or user SHOULD be able to indicate its domain ingress points (Signaling Path Border Element(s)) based on the identity of the originating VSP/ASP/user Another high-level design guideline could be: - The mechanisms recommended for the use and resolution of the call addressing data SHOULD allow for variability/customization depending on various factors, such as the identity of the originating or terminating peers. Comments appreciated. Jean-Francois. _______________________________________________ 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 From speermint-bounces@ietf.org Wed Oct 18 13:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEn6-0001o1-MA; Wed, 18 Oct 2006 13:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEn5-0001hZ-1i for speermint@ietf.org; Wed, 18 Oct 2006 13:01:15 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEmz-0000uv-If for speermint@ietf.org; Wed, 18 Oct 2006 13:01:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2006 13:01:09 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IH19bw015003; Wed, 18 Oct 2006 13:01:09 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9IH18YJ005499; Wed, 18 Oct 2006 13:01:08 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 13:01:08 -0400 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] Basic Peering Requirements Date: Wed, 18 Oct 2006 13:01:07 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F6C1@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 18 Oct 2006 17:01:08.0292 (UTC) FILETIME=[01743040:01C6F2D7] DKIM-Signature: a=rsa-sha1; q=dns; l=6444; t=1161190869; x=1162054869; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Stastny=20Richard=22=20, =20=22Otmar=20Lendl =22=20, =0A=20=20=20=20=20=20=20=20=22Daryl=20Malas=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=XpvlZTFXIR52RhWwluahk+NB05XikphCAYj9f1/zsx2g2lfLGe5rslb/Dac8a3ePkoPzsrQB l3+AJO6FOBtRoemhfhSde+THIlLKhfLSV6M35JM4LkDammCF7FZ2qDFM; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I had taken this to mean that the Transit VSP would be advertising to originating VSPs reachability to various federations of the form: (to get to) (contact) Federation X --> Fed-X@VSP.com (Fed-X etc. could be an arbitrary string) Federation Y --> Fed-Y@VSP.com Federation Z --> Fed-Z@VSP.com =20 or: Federation X --> Fed-Any@VSP.com Federation Y --> Fed-Any@VSP.com Federation Z --> Fed-Any@VSP.com If not, count me as misunderstanding too. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, October 18, 2006 10:05 AM > To: Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > >> If a peer is providing connectivity to multiple federations, it=20 > >> should disclose AoRs providing indirect peering relationships to=20 > >> servicing peers or federations. >=20 > >Sorry, I don't understand that sentence. >=20 > >Do you mean that when a VSP adds an AoR to a federations routing=20 > >database, then it needs to discluse whether that is a direct=20 > customer=20 > >or just a transit offer? >=20 > Sorry, but I do not understand the whole issue: > =20 > An AoR is a a special type of SIP URI (a Public User=20 > Identity) defining the destination network (administrative domain) > =20 > How can it be disclosed or not, especially for a transit network? > It is always public. > =20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Otmar Lendl [mailto:lendl@nic.at] > Gesendet: Mi 18.10.2006 15:54 > An: Daryl Malas > Cc: speermint@ietf.org > Betreff: Re: [Speermint] Basic Peering Requirements >=20 >=20 >=20 >=20 > Daryl, >=20 > > peering requirements from one operators perspective. I can=20 > post these=20 > > to the list if you would like. Here is a list of peering=20 > requirements=20 > > (this is certainly not exhaustive, but is a platform): >=20 > Here are my comments to that list: >=20 > General: this seems to be a list providing details on what=20 > federations have to do (or agree on). >=20 > > Transport (Layer 1 3): > > > > Peering must utilize IP as the primary mechanism for peering. > > > > A federation must agree upon a common mechanism for IP transport=20 > > either private (e.g. IPVPN, IPSEC, etc.) or public. >=20 > Fine. >=20 > > Billing: >=20 > Good. >=20 > > Policy: > > >=20 > Could you be a bit more specific on what you mean by "policy"=20 > in this context? >=20 > > Policies may be implemented locally to the peer or via a=20 > centralized=20 > > mechanism within the federation. > > > > Local policies should be disclosed when creating direct peering=20 > > relationships with the applicable direct peer. > > > > Local policies may supersede centralized federation policies. > > > > (Net of this...some peering relationships will be 1:1, so policies=20 > > will likely be local only. Some peering relationships will=20 > be 1:N, so=20 > > policies will likely be implemented within DNS or some centralized > > mechanism.) >=20 > Could you provide some examples of such policies? >=20 > > Membership: > > > > A peer may be a member of multiple federations > > > > A peer must maintain compliancy for policies as defined by each=20 > > federation the peer is a member of. > > > > If a peer is providing connectivity to multiple=20 > federations, it should=20 > > disclose AoRs providing indirect peering relationships to servicing=20 > > peers or federations. >=20 > Sorry, I don't understand that sentence. >=20 > Do you mean that when a VSP adds an AoR to a federations=20 > routing database, then it needs to discluse whether that is a=20 > direct customer or just a transit offer? >=20 > > Peers providing indirect peering must enforce federation=20 > policies on=20 > > behalf of the destination federation. > > > > A peer providing indirect peering may enforce undisclosed=20 > policies for=20 > > processing session requests between federations. > > > > (Net of this...some peers will only desire to be part of a single=20 > > federation, where wholesale carriers will likely be members of=20 > > multiple > > federations.) >=20 > ok. >=20 > > Media: >=20 > ok. >=20 > > Routing: > > > > A peer must utilize the centralized federation routing=20 > mechanism if it=20 > > is available. >=20 > ok. >=20 > > A peer allowing another peer within a federation to provide=20 > indirect=20 > > peering on their behalf must select only one indirect peer to host=20 > > their AoRs. >=20 > Do you mean indirect peering *within* a federation? Let me=20 > name the parties here: >=20 > > A peer (X) allowing another peer (Y) within a federation (F1) to=20 > > provide indirect peering on their behalf must select only=20 > one indirect=20 > > peer to host their AoRs. >=20 > Is the idea here that all members of F1 who want to place=20 > calls to X need to route the calls via Y? In that case, I=20 > would not consider X to be a member of F1. Instead, Y is=20 > providing transit services for X. >=20 > Or you want to restrict X to be able to only select one other=20 > VSP to host it's AoRs in total? >=20 > > A peer must not copy routing information from or make=20 > assumed routing=20 > > choices on behalf of the centralized routing mechanism for=20 > use locally=20 > > unless it takes place through standard caching methods. > > > > A common API must be utilized and available for subscriber=20 > and route=20 > > provisioning on any centralized federation location function. > > > > Subscriber and routing information must be dynamically=20 > updated as soon=20 > > as applicable for accurate routing within the federation. >=20 > ok >=20 > > Performance: > > > > Performance metrics must be shared between peers as they apply=20 > > directly to peering signaling and media on a consistent=20 > basis within=20 > > the federation. >=20 > ok >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 13:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEvx-0007Ix-9V; Wed, 18 Oct 2006 13:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEvw-0007Dz-6F for speermint@ietf.org; Wed, 18 Oct 2006 13:10:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEvt-0003A3-Rt for speermint@ietf.org; Wed, 18 Oct 2006 13:10:24 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 10:10:21 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IHAL2Y018289; Wed, 18 Oct 2006 13:10:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9IHAJYP007744; Wed, 18 Oct 2006 13:10:21 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 13:10:20 -0400 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] Basic Peering Requirements Date: Wed, 18 Oct 2006 13:10:17 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F6C8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acbyz1Z21fDRQsHvRMm+WJ4Ez6xvwQACEI6A From: "Michael Hammer \(mhammer\)" To: "Daryl Malas" , "Otmar Lendl" X-OriginalArrivalTime: 18 Oct 2006 17:10:20.0775 (UTC) FILETIME=[4AC26770:01C6F2D8] DKIM-Signature: a=rsa-sha1; q=dns; l=2578; t=1161191421; x=1162055421; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Daryl=20Malas=22=20, =20=22Otmar=20Lendl=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=ejhuEMNvy/HBc8LRPa4Ln9Su4jznxPoJu8EALsTMQl+nljt5yOqGKdYgU+e+spkJ8fcOgP1n 1cezmnym21P92gg8pAv6xKBy2JU31sn4ueaU6orVMRFMP9kr2GE4unoP; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Given that they are peers, are the multihoming advertizements symmetric? VSP Transit VSP SF<----->SF \ / / \ SF<----->SF Mike =20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Wednesday, October 18, 2006 11:56 AM > To: Otmar Lendl > Cc: speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On Wed, 2006-10-18 at 17:23 +0200, Otmar Lendl wrote: > > On 2006/10/18 17:10, Daryl Malas wrote: > > > On Wed, 2006-10-18 at 15:54 +0200, Otmar Lendl wrote: > >=20 > > > > > A peer allowing another peer within a federation to provide=20 > > > > > indirect peering on their behalf must select only one=20 > indirect=20 > > > > > peer to host their AoRs. > > > >=20 > > > > Do you mean indirect peering *within* a federation? Let me name=20 > > > > the parties here: > > > >=20 > > > > > A peer (X) allowing another peer (Y) within a=20 > federation (F1) to=20 > > > > > provide indirect peering on their behalf must select only one=20 > > > > > indirect peer to host their AoRs. > > > >=20 > > > > Is the idea here that all members of F1 who want to=20 > place calls to=20 > > > > X need to route the calls via Y? In that case, I would not=20 > > > > consider X to be a member of F1. Instead, Y is=20 > providing transit=20 > > > > services for X. > > >=20 > > > Your assumption is correct, X is not a member of F1. =20 > They can only=20 > > > specify to allow Y (and not A, B, C, and D) to provide indirect=20 > > > peering within F1. > > >=20 > > > > Or you want to restrict X to be able to only select one=20 > other VSP=20 > > > > to host it's AoRs in total? > > >=20 > > > Yes > > >=20 > >=20 > > How does multihoming (e.g. a small VSP which wants to by upstream=20 > > services from multiple transit VSPs) fit into that scheme? > Again, I talked about this in a previous thread. A small VSP=20 > can be multi-homed to a single transit VSP (e.g. multiple=20 > SF's). They will also likely be connected "indirectly" to=20 > multiple federations, which also may be contracted to provide=20 > an indirect route back to this federation through one of the peers. >=20 > I think this simplifies it greatly. If we must, then I=20 > suggest a maximum of two peers in a federation may provide=20 > indirect peering to an external VSP. > >=20 > > /ol >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 13:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaF5E-0002Cm-TB; Wed, 18 Oct 2006 13:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaF5E-0002CP-8X for speermint@ietf.org; Wed, 18 Oct 2006 13:20:00 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaF59-0005XL-SO for speermint@ietf.org; Wed, 18 Oct 2006 13:20:00 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 18 Oct 2006 10:17:24 -0700 X-IronPort-AV: i="4.09,325,1157353200"; d="scan'208"; a="603764141:sNHT38159728" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Policy Definition Date: Wed, 18 Oct 2006 13:19:53 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805CAA05E@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwAADuJLAAKorPAAAFGKLgAC555cAABXh4YA== From: "Reinaldo Penno" To: "Jean-Francois Mule" , "Brian Rosen" , "Daryl Malas" , "David Schwartz" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jean-Francois, If all we want is the definition of policy, we can get that from RFC3198 "Terminology for Policy-Based Management ". "$ policy (P) "Policy" can be defined from two perspectives: - A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit). - Policies as a set of rules to administer, manage, and control access to network resources [RFC3060]. Note that these two views are not contradictory since individual rules may be defined in support of business goals. (See also "policy goal", "policy abstraction" and "policy rule".)" As far as what can be exchanged, I would say any parameters that can affect CRD (Call Routing Data). There is no need to list which parameters at this point but just state the purpose of a policy exchange. Regards, Reinaldo > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Wednesday, October 18, 2006 7:48 AM > To: Reinaldo Penno; Brian Rosen; Daryl Malas; David Schwartz > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > Reinaldo wrote: > > I believe when the SIPPING folks defined session-dependent and=20 > > session-independent polcies they knew that static policies existed. > > When > > you sign a VoIP contract with a Cable providers there are static=20 > > policies in place and when two VSPs peer they also sign a=20 > contract. It=20 > > is no different, the question we need to ask is how much text real=20 > > estate we need to give to static policies. Does a IETF WG=20 > need to care=20 > > if there are policies driven by a contract? I wonder if there are=20 > > similar considerations in Inter Domain Routing WG. > >=20 > > Anyway, I just want to make it consistent with other IETF work. > >=20 > > As far as the definition below, I do not believe it is "globally" > > defined. Not even static policies might be global. Many dynamic > Ok, deleted "globally" >=20 > > policies > > (whether session dependent or independent) are local to a specific=20 > > peering point (assuming VSPs peer at more than one location) and/or=20 > > even a proxy (calls per second, bw, etc). >=20 > Any more specific comments on the policy def? > Folks seem to be so focused on "static" vs. "dynamic", even=20 > when we are trying to define what is that 'thing' that could=20 > be statically or dynamically exchanged.=20 >=20 > Jean-Francois. >=20 > >=20 > > Thanks, > >=20 > > Reinaldo > >=20 > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Tuesday, October 17, 2006 8:55 AM > > > To: Brian Rosen; Reinaldo Penno; Daryl Malas; David Schwartz > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > Here is another try based on yesterday's dialogs: > > > > > > --- Session peering 'policy' definition: > > > "In the context of session peering, a policy is globally=20 > defined as=20 > > > the set of parameters and other information needed by one=20 > VSP/ASP to=20 > > > connect to another. > > > Some of the session policy parameters may be statically exchanged=20 > > > and set throughout the lifetime of the peering=20 > relationship. Others=20 > > > parameters may be discovered and updated dynamically=20 > using by some=20 > > > explicit protocol mechanisms. These dynamic parameters may also=20 > > > relate to a VSP/ASP's session-dependent or session independent=20 > > > policies as defined in [ID-sipping-policy]. > > > > > > Notes: > > > - this revised text injects the notions of 'static' vs. > > > dynamic policy params Brian proposed; the=20 > addressing/routing is part=20 > > > of the session-dependent and session-independent policies of a=20 > > > domain (as you proposed Brian). > > > - it links speermint's policy def (focused on inter-domain) with=20 > > > the sipping's def (focused on intra-domain) per=20 > Reinaldo's proposal. > > > > > > Thoughts? Good enough for now or not? > > > > > > Jean-Francois. > > > > > > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 13:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFVQ-0004CP-F1; Wed, 18 Oct 2006 13:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFVP-0004CK-FC for speermint@ietf.org; Wed, 18 Oct 2006 13:47:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFVN-0002Wl-0s for speermint@ietf.org; Wed, 18 Oct 2006 13:47:03 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2006 13:47:00 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IHl0LC010010; Wed, 18 Oct 2006 13:47:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9IHkqYb018406; Wed, 18 Oct 2006 13:47:00 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 13:46:58 -0400 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] Policy Definition Date: Wed, 18 Oct 2006 13:46:57 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F70D@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTAAOkohgA== From: "Michael Hammer \(mhammer\)" To: "Jean-Francois Mule" , "Reinaldo Penno" X-OriginalArrivalTime: 18 Oct 2006 17:46:58.0603 (UTC) FILETIME=[68C457B0:01C6F2DD] DKIM-Signature: a=rsa-sha1; q=dns; l=6830; t=1161193620; x=1162057620; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Policy=20Definition |To:=22Jean-Francois=20Mule=22=20, =0A=20=20=20=20=20= 20=20=20=22Reinaldo=20Penno=22=20; X=v=3Dcisco.com=3B=20h=3DF60+CVv5TtTB9gi+7Fqgr95xEVY=3D; b=nSyxrPTFn0Dsiz7joVP17N61D/Olu1WWW8OKOEA8LGiPDSD1ea8A/bjIANl3f8SSYL47KLn3 Dsu1/Nb1ope8k7WxHDxCiuMULYjascy7r9Eqd95e1OBlxM9uLtJOt6Up; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Still chasing down this thread, but a couple comments: Agree with the fact that we are defining NNI versus the UNI-oriented stuff SIPPING defined. Agree that static v. dynamic and session v. session-independent are two different dimensions: =20 "Dynamic" "Static" Time- Time- Variant Non-Variant +--------+--------+ Session- | | | Variant | | | +--------+--------+ Session- | | | Non-variant | | | +--------+--------+ BTW, the term "session" is sometimes used to mean media and sometimes used to mean signaling or dialog, which creates lots of confusion. Also, if there are restrictions on what can be put into an SDP body, I assume that is lumped with the media (session) stuff. I would prefer using terms like "signaling" for SIP constraints and "media" for SDP/RTP constraints. Are there signaling-dependent and signaling-independent aspects also? We may be struggling with a branch of the tree but not discovered the root yet: Root +--PeerIndependent +--PeerDependent +--Call/Signaling Independent +--Call/Signaling Dependent +--Session/Media Independent +--Session/Media Dependent Mix and match to get all branches. Thoughts? Mike =20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Tuesday, October 17, 2006 9:53 AM > To: Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > Reinaldo wrote: > > I suggest we just we use the terms already defined by the=20 > SIPPING WG. > > These are session-dependent and session-independent=20 > policies. This was=20 > > what Jon P. mentioned in the interim meeting. >=20 > Yes for helping distinguish between the things that are=20 > session-dependent vs. session independent. But there are 2=20 > points we are trying to clarify here and capture in our=20 > common understanding that are not addressed in the SIPPING drafts: >=20 > a) the policy definitions in > draft-ietf-sipping-session-policy-framework-01.txt do not=20 > actually define what a policy is other than by using examples=20 > of policy parameters in areas which have been declared out of=20 > scope such as codec, and QoS. >=20 > =3D=3D> we should keep the basic sentence Brian originally proposed: > "the set of parameters and other information needed by one=20 > VSP/ASP to connect to another." >=20 > b) the SIPPING drafts are geared towards *intra*-domain=20 > policies applicable to UAs of a given domain (UA <-> Policy=20 > Server) whereas much of what we are discussing here is=20 > *inter*-domain, stuff between Policy Servers or PFs. This=20 > may be obvious but it needs to be clear in our definition. >=20 > Jean-Francois.=20 >=20 > >=20 > > You can find it here draft-ietf-sipping-policy-package-01 > >=20 > > I leveraged these definitions in thse drafts: > >=20 > > draft-ietf-speermint-architecture-02 (to be submiited soon)=20 > > draft-penno-sipping-peering-package-00 > >=20 > >=20 > > If that does not make everybody happy, we can try to map Brian's=20 > > suggestions into the SIPPING definitions and make a=20 > sub-hierarchy if=20 > > needed. > >=20 > > Let me know your thoughts. > >=20 > > Thanks, > >=20 > > Reinaldo > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, October 16, 2006 5:28 AM > > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > While I think this definition is good, I think it is not=20 > sufficient. > > > > > > I think we need to break policy up into several buckets and give=20 > > > each a name. > > > > > > There is policy expressed statically (possibly by a=20 > contract, a web=20 > > > page, or some other thing that is human understandable). > > > > > > There is policy that has to do with addressing and=20 > routing, such as=20 > > > which federations it belongs to or which transit networks it=20 > > > connects to, or what ingress gateways it uses. > > > > > > There is dynamically discoverable policy that governs=20 > things beyond=20 > > > addressing. At any point in time, or maybe variable with=20 > > > federations, the this and static policy may have the same=20 > items in=20 > > > them, that is, we may start with, say, a static policy on=20 > how many=20 > > > calls per second we accept, and later come up with an=20 > automated way=20 > > > to discover it. > > > > > > I propose: "static policy" "addressing (or routing) policy" > > > and "dynamic policy" > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > Sent: Monday, October 16, 2006 6:15 AM > > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > > "In the context of session peering, a policy is defined as > > > the set of > > > > parameters and other information needed by one VSP to=20 > connect to=20 > > > > another. A policy may be agreed to by Peers, or=20 > specified by some=20 > > > > explicit protocol mechanism, or defined by a contract in a > > > Federation. > > > > A policy is typically applicable to multiple sessions:=20 > it is not a=20 > > > > per-call specific." > > > > > > > > Notes: > > > > - VSP or VSP/ASP to re-use the ecrit=20 > terminology in order to=20 > > > > integrate other types of session peering per the comments that > > this > > > > should not be voice-specific; > > > > - it incorporates the comments received on the fact > > > that how a policy > > > > is agreed to, or specify by is open to various models > > > (Daryl's "agreed > > > > to by Peers" and Richard's comment on the fact that the > > > reference to > > > > federation in this definition is not needed) > > > > - it does not prevent a VSP from including=20 > endpoint-related=20 > > > > parameters as long as those are representing what the=20 > VSP think is=20 > > > > required to 'connect' (per David's question) > > > > > > > > Jean-Francois. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 13:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFd8-000365-Hy; Wed, 18 Oct 2006 13:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFd6-00035t-Il for speermint@ietf.org; Wed, 18 Oct 2006 13:55:00 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFd4-0004Pm-2O for speermint@ietf.org; Wed, 18 Oct 2006 13:55:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaFch-0007LM-5C; Wed, 18 Oct 2006 12:54:35 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Otmar Lendl'" , "'Daryl Malas'" Subject: RE: [Speermint] Basic Peering Requirements Date: Wed, 18 Oct 2006 13:54:36 -0400 Message-ID: <00a601c6f2de$7d066370$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30211F6C1@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org To me, this is off the deep end. I think we don't care what federations a destination network belongs to. Sorry Otmar. I think a federation may advertise what peers it can get you access to. That may include transit peers, and those transit peers may get you to other peers through other federations. The federation advertises the aggregate of what networks it can reach, direct or indirect. I don't want a peer to have to keep relationships (how it gets to Fed X) straight, I want it to be able to ask the federations or transit networks it deals with if they have a route to the destination network. If you take this view, then you always get what you want to know, regardless of how convoluted the routes are, by simple queries to each federation/transit network. If you try to trace routes in advance (let's see, I want to get to network A, he is part of Fed 1 and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of fed 2 and he is also part of Fed 3, and I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2 to get to A). Much better if Fed 3 advertises it can reach A. This is how route advertisements work, and I think we should assume that's the best way until proven otherwise. So let's not talk about Federations a network belongs to, and specifically, don't talk about routes TO A FEDERATION, but rather routes to a destination network FROM a federation. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, October 18, 2006 1:01 PM > To: Stastny Richard; Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > I had taken this to mean that the Transit VSP would be advertising to > originating VSPs reachability to various federations of the form: > > (to get to) (contact) > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an arbitrary > string) > Federation Y --> Fed-Y@VSP.com > Federation Z --> Fed-Z@VSP.com > > or: > > Federation X --> Fed-Any@VSP.com > Federation Y --> Fed-Any@VSP.com > Federation Z --> Fed-Any@VSP.com > > If not, count me as misunderstanding too. > > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, October 18, 2006 10:05 AM > > To: Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Basic Peering Requirements > > > > >> If a peer is providing connectivity to multiple federations, it > > >> should disclose AoRs providing indirect peering relationships to > > >> servicing peers or federations. > > > > >Sorry, I don't understand that sentence. > > > > >Do you mean that when a VSP adds an AoR to a federations routing > > >database, then it needs to discluse whether that is a direct > > customer > > >or just a transit offer? > > > > Sorry, but I do not understand the whole issue: > > > > An AoR is a a special type of SIP URI (a Public User > > Identity) defining the destination network (administrative domain) > > > > How can it be disclosed or not, especially for a transit network? > > It is always public. > > > > Richard > > > > > > ________________________________ > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > Gesendet: Mi 18.10.2006 15:54 > > An: Daryl Malas > > Cc: speermint@ietf.org > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > Daryl, > > > > > peering requirements from one operators perspective. I can > > post these > > > to the list if you would like. Here is a list of peering > > requirements > > > (this is certainly not exhaustive, but is a platform): > > > > Here are my comments to that list: > > > > General: this seems to be a list providing details on what > > federations have to do (or agree on). > > > > > Transport (Layer 1 3): > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > A federation must agree upon a common mechanism for IP transport > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > Fine. > > > > > Billing: > > > > Good. > > > > > Policy: > > > > > > > Could you be a bit more specific on what you mean by "policy" > > in this context? > > > > > Policies may be implemented locally to the peer or via a > > centralized > > > mechanism within the federation. > > > > > > Local policies should be disclosed when creating direct peering > > > relationships with the applicable direct peer. > > > > > > Local policies may supersede centralized federation policies. > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > > will likely be local only. Some peering relationships will > > be 1:N, so > > > policies will likely be implemented within DNS or some centralized > > > mechanism.) > > > > Could you provide some examples of such policies? > > > > > Membership: > > > > > > A peer may be a member of multiple federations > > > > > > A peer must maintain compliancy for policies as defined by each > > > federation the peer is a member of. > > > > > > If a peer is providing connectivity to multiple > > federations, it should > > > disclose AoRs providing indirect peering relationships to servicing > > > peers or federations. > > > > Sorry, I don't understand that sentence. > > > > Do you mean that when a VSP adds an AoR to a federations > > routing database, then it needs to discluse whether that is a > > direct customer or just a transit offer? > > > > > Peers providing indirect peering must enforce federation > > policies on > > > behalf of the destination federation. > > > > > > A peer providing indirect peering may enforce undisclosed > > policies for > > > processing session requests between federations. > > > > > > (Net of this...some peers will only desire to be part of a single > > > federation, where wholesale carriers will likely be members of > > > multiple > > > federations.) > > > > ok. > > > > > Media: > > > > ok. > > > > > Routing: > > > > > > A peer must utilize the centralized federation routing > > mechanism if it > > > is available. > > > > ok. > > > > > A peer allowing another peer within a federation to provide > > indirect > > > peering on their behalf must select only one indirect peer to host > > > their AoRs. > > > > Do you mean indirect peering *within* a federation? Let me > > name the parties here: > > > > > A peer (X) allowing another peer (Y) within a federation (F1) to > > > provide indirect peering on their behalf must select only > > one indirect > > > peer to host their AoRs. > > > > Is the idea here that all members of F1 who want to place > > calls to X need to route the calls via Y? In that case, I > > would not consider X to be a member of F1. Instead, Y is > > providing transit services for X. > > > > Or you want to restrict X to be able to only select one other > > VSP to host it's AoRs in total? > > > > > A peer must not copy routing information from or make > > assumed routing > > > choices on behalf of the centralized routing mechanism for > > use locally > > > unless it takes place through standard caching methods. > > > > > > A common API must be utilized and available for subscriber > > and route > > > provisioning on any centralized federation location function. > > > > > > Subscriber and routing information must be dynamically > > updated as soon > > > as applicable for accurate routing within the federation. > > > > ok > > > > > Performance: > > > > > > Performance metrics must be shared between peers as they apply > > > directly to peering signaling and media on a consistent > > basis within > > > the federation. > > > > ok > > > > /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 From speermint-bounces@ietf.org Wed Oct 18 14:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFoM-0003hk-D9; Wed, 18 Oct 2006 14:06:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFoK-0003hP-3O for speermint@ietf.org; Wed, 18 Oct 2006 14:06:36 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaFoG-0006Yo-K4 for speermint@ietf.org; Wed, 18 Oct 2006 14:06:36 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-11.tower-146.messagelabs.com!1161194791!2109256!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15423 invoked from network); 18 Oct 2006 18:06:31 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-11.tower-146.messagelabs.com with SMTP; 18 Oct 2006 18:06:31 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9II6U3q027336 for ; Wed, 18 Oct 2006 14:06:31 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9II5mXL027068 for ; Wed, 18 Oct 2006 14:06:26 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C3300085B6C; Wed, 18 Oct 2006 14:06:22 -0400 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] Basic Peering Requirements Date: Wed, 18 Oct 2006 14:06:21 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DE728E4@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <00a601c6f2de$7d066370$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAAAoN6w From: "Pfautz, Penn L, GBLAM" To: "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 So, how does a Federation "advertise"? I hope we're not talking about building something TRIP-like. Route advertisements may be the best way for IP routing but it's not a slam dunk that they fit here. That was the wrong answer for E.164, for example, because the address space had different properties. Penn -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, October 18, 2006 1:55 PM To: 'Michael Hammer (mhammer)'; 'Stastny Richard'; 'Otmar Lendl'; 'Daryl Malas' Cc: speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements To me, this is off the deep end. I think we don't care what federations a destination network belongs to. Sorry Otmar. I think a federation may advertise what peers it can get you access to. That may include transit peers, and those transit peers may get you to other peers through other federations. The federation advertises the aggregate of what networks it can reach, direct or indirect. I don't want a peer to have to keep relationships (how it gets to Fed X) straight, I want it to be able to ask the federations or transit networks it deals with if they have a route to the destination network. If you take this view, then you always get what you want to know, regardless of how convoluted the routes are, by simple queries to each federation/transit network. If you try to trace routes in advance (let's see, I want to get to network A, he is part of Fed 1 and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of fed 2 and he is also part of Fed 3, and I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2 to get to A). Much better if Fed 3 advertises it can reach A. This is how route advertisements work, and I think we should assume that's the best way until proven otherwise. So let's not talk about Federations a network belongs to, and specifically, don't talk about routes TO A FEDERATION, but rather routes to a destination network FROM a federation. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, October 18, 2006 1:01 PM > To: Stastny Richard; Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > I had taken this to mean that the Transit VSP would be advertising to > originating VSPs reachability to various federations of the form: >=20 > (to get to) (contact) > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an arbitrary > string) > Federation Y --> Fed-Y@VSP.com > Federation Z --> Fed-Z@VSP.com >=20 > or: >=20 > Federation X --> Fed-Any@VSP.com > Federation Y --> Fed-Any@VSP.com > Federation Z --> Fed-Any@VSP.com >=20 > If not, count me as misunderstanding too. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, October 18, 2006 10:05 AM > > To: Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Basic Peering Requirements > > > > >> If a peer is providing connectivity to multiple federations, it > > >> should disclose AoRs providing indirect peering relationships to > > >> servicing peers or federations. > > > > >Sorry, I don't understand that sentence. > > > > >Do you mean that when a VSP adds an AoR to a federations routing > > >database, then it needs to discluse whether that is a direct > > customer > > >or just a transit offer? > > > > Sorry, but I do not understand the whole issue: > > > > An AoR is a a special type of SIP URI (a Public User > > Identity) defining the destination network (administrative domain) > > > > How can it be disclosed or not, especially for a transit network? > > It is always public. > > > > Richard > > > > > > ________________________________ > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > Gesendet: Mi 18.10.2006 15:54 > > An: Daryl Malas > > Cc: speermint@ietf.org > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > Daryl, > > > > > peering requirements from one operators perspective. I can > > post these > > > to the list if you would like. Here is a list of peering > > requirements > > > (this is certainly not exhaustive, but is a platform): > > > > Here are my comments to that list: > > > > General: this seems to be a list providing details on what > > federations have to do (or agree on). > > > > > Transport (Layer 1 3): > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > A federation must agree upon a common mechanism for IP transport > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > Fine. > > > > > Billing: > > > > Good. > > > > > Policy: > > > > > > > Could you be a bit more specific on what you mean by "policy" > > in this context? > > > > > Policies may be implemented locally to the peer or via a > > centralized > > > mechanism within the federation. > > > > > > Local policies should be disclosed when creating direct peering > > > relationships with the applicable direct peer. > > > > > > Local policies may supersede centralized federation policies. > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > > will likely be local only. Some peering relationships will > > be 1:N, so > > > policies will likely be implemented within DNS or some centralized > > > mechanism.) > > > > Could you provide some examples of such policies? > > > > > Membership: > > > > > > A peer may be a member of multiple federations > > > > > > A peer must maintain compliancy for policies as defined by each > > > federation the peer is a member of. > > > > > > If a peer is providing connectivity to multiple > > federations, it should > > > disclose AoRs providing indirect peering relationships to servicing > > > peers or federations. > > > > Sorry, I don't understand that sentence. > > > > Do you mean that when a VSP adds an AoR to a federations > > routing database, then it needs to discluse whether that is a > > direct customer or just a transit offer? > > > > > Peers providing indirect peering must enforce federation > > policies on > > > behalf of the destination federation. > > > > > > A peer providing indirect peering may enforce undisclosed > > policies for > > > processing session requests between federations. > > > > > > (Net of this...some peers will only desire to be part of a single > > > federation, where wholesale carriers will likely be members of > > > multiple > > > federations.) > > > > ok. > > > > > Media: > > > > ok. > > > > > Routing: > > > > > > A peer must utilize the centralized federation routing > > mechanism if it > > > is available. > > > > ok. > > > > > A peer allowing another peer within a federation to provide > > indirect > > > peering on their behalf must select only one indirect peer to host > > > their AoRs. > > > > Do you mean indirect peering *within* a federation? Let me > > name the parties here: > > > > > A peer (X) allowing another peer (Y) within a federation (F1) to > > > provide indirect peering on their behalf must select only > > one indirect > > > peer to host their AoRs. > > > > Is the idea here that all members of F1 who want to place > > calls to X need to route the calls via Y? In that case, I > > would not consider X to be a member of F1. Instead, Y is > > providing transit services for X. > > > > Or you want to restrict X to be able to only select one other > > VSP to host it's AoRs in total? > > > > > A peer must not copy routing information from or make > > assumed routing > > > choices on behalf of the centralized routing mechanism for > > use locally > > > unless it takes place through standard caching methods. > > > > > > A common API must be utilized and available for subscriber > > and route > > > provisioning on any centralized federation location function. > > > > > > Subscriber and routing information must be dynamically > > updated as soon > > > as applicable for accurate routing within the federation. > > > > ok > > > > > Performance: > > > > > > Performance metrics must be shared between peers as they apply > > > directly to peering signaling and media on a consistent > > basis within > > > the federation. > > > > ok > > > > /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 > > >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Wed Oct 18 14:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFuh-0006ym-RE; Wed, 18 Oct 2006 14:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFug-0006yh-GT for speermint@ietf.org; Wed, 18 Oct 2006 14:13:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFuf-0007xN-0f for speermint@ietf.org; Wed, 18 Oct 2006 14:13:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaFuS-0000za-2V; Wed, 18 Oct 2006 13:12:57 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Jean-Francois Mule'" , "'Reinaldo Penno'" Subject: RE: [Speermint] Policy Definition Date: Wed, 18 Oct 2006 14:12:59 -0400 Message-ID: <00aa01c6f2e1$0d4ea8a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTAAOkohgAAA8Lug In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30211F70D@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I don't see the signaling/media variable being useful. Of course you have session dependent/independent Peer Independent policy. The Federation may assert session dependent policy, as opposed to a peer asserting one. So I think the tree is Peer Independent Session dependent Session independent Peer Dependent Session dependent Session independent That's assuming my "addressing related" axis is subsumed. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Wednesday, October 18, 2006 1:47 PM > To: Jean-Francois Mule; Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition > > Still chasing down this thread, but a couple comments: > > Agree with the fact that we are defining NNI versus the UNI-oriented > stuff SIPPING defined. > > Agree that static v. dynamic and session v. session-independent are two > different dimensions: > > "Dynamic" "Static" > Time- Time- > Variant Non-Variant > +--------+--------+ > Session- | | | > Variant | | | > +--------+--------+ > Session- | | | > Non-variant | | | > +--------+--------+ > > BTW, the term "session" is sometimes used to mean media and sometimes > used to mean signaling or dialog, which creates lots of confusion. > Also, if there are restrictions on what can be put into an SDP body, I > assume that is lumped with the media (session) stuff. > > I would prefer using terms like "signaling" for SIP constraints and > "media" for SDP/RTP constraints. > > Are there signaling-dependent and signaling-independent aspects also? > We may be struggling with a branch of the tree but not discovered the > root yet: > > Root > +--PeerIndependent > +--PeerDependent > +--Call/Signaling Independent > +--Call/Signaling Dependent > +--Session/Media Independent > +--Session/Media Dependent > > Mix and match to get all branches. Thoughts? > > Mike > > > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Tuesday, October 17, 2006 9:53 AM > > To: Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > > > > Reinaldo wrote: > > > I suggest we just we use the terms already defined by the > > SIPPING WG. > > > These are session-dependent and session-independent > > policies. This was > > > what Jon P. mentioned in the interim meeting. > > > > Yes for helping distinguish between the things that are > > session-dependent vs. session independent. But there are 2 > > points we are trying to clarify here and capture in our > > common understanding that are not addressed in the SIPPING drafts: > > > > a) the policy definitions in > > draft-ietf-sipping-session-policy-framework-01.txt do not > > actually define what a policy is other than by using examples > > of policy parameters in areas which have been declared out of > > scope such as codec, and QoS. > > > > ==> we should keep the basic sentence Brian originally proposed: > > "the set of parameters and other information needed by one > > VSP/ASP to connect to another." > > > > b) the SIPPING drafts are geared towards *intra*-domain > > policies applicable to UAs of a given domain (UA <-> Policy > > Server) whereas much of what we are discussing here is > > *inter*-domain, stuff between Policy Servers or PFs. This > > may be obvious but it needs to be clear in our definition. > > > > Jean-Francois. > > > > > > > > You can find it here draft-ietf-sipping-policy-package-01 > > > > > > I leveraged these definitions in thse drafts: > > > > > > draft-ietf-speermint-architecture-02 (to be submiited soon) > > > draft-penno-sipping-peering-package-00 > > > > > > > > > If that does not make everybody happy, we can try to map Brian's > > > suggestions into the SIPPING definitions and make a > > sub-hierarchy if > > > needed. > > > > > > Let me know your thoughts. > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Monday, October 16, 2006 5:28 AM > > > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > While I think this definition is good, I think it is not > > sufficient. > > > > > > > > I think we need to break policy up into several buckets and give > > > > each a name. > > > > > > > > There is policy expressed statically (possibly by a > > contract, a web > > > > page, or some other thing that is human understandable). > > > > > > > > There is policy that has to do with addressing and > > routing, such as > > > > which federations it belongs to or which transit networks it > > > > connects to, or what ingress gateways it uses. > > > > > > > > There is dynamically discoverable policy that governs > > things beyond > > > > addressing. At any point in time, or maybe variable with > > > > federations, the this and static policy may have the same > > items in > > > > them, that is, we may start with, say, a static policy on > > how many > > > > calls per second we accept, and later come up with an > > automated way > > > > to discover it. > > > > > > > > I propose: "static policy" "addressing (or routing) policy" > > > > and "dynamic policy" > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > > Sent: Monday, October 16, 2006 6:15 AM > > > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > > > "In the context of session peering, a policy is defined as > > > > the set of > > > > > parameters and other information needed by one VSP to > > connect to > > > > > another. A policy may be agreed to by Peers, or > > specified by some > > > > > explicit protocol mechanism, or defined by a contract in a > > > > Federation. > > > > > A policy is typically applicable to multiple sessions: > > it is not a > > > > > per-call specific." > > > > > > > > > > Notes: > > > > > - VSP or VSP/ASP to re-use the ecrit > > terminology in order to > > > > > integrate other types of session peering per the comments that > > > this > > > > > should not be voice-specific; > > > > > - it incorporates the comments received on the fact > > > > that how a policy > > > > > is agreed to, or specify by is open to various models > > > > (Daryl's "agreed > > > > > to by Peers" and Richard's comment on the fact that the > > > > reference to > > > > > federation in this definition is not needed) > > > > > - it does not prevent a VSP from including > > endpoint-related > > > > > parameters as long as those are representing what the > > VSP think is > > > > > required to 'connect' (per David's question) > > > > > > > > > > Jean-Francois. > > > > > > > > > > > > _______________________________________________ > > > > 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 From speermint-bounces@ietf.org Wed Oct 18 14:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGNr-0006d8-LG; Wed, 18 Oct 2006 14:43:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGNp-0006Wk-TA for speermint@ietf.org; Wed, 18 Oct 2006 14:43:17 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaGL3-00041F-SU for speermint@ietf.org; Wed, 18 Oct 2006 14:40:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaGKo-0003tW-RV; Wed, 18 Oct 2006 13:40:11 -0500 From: "Brian Rosen" To: "'Pfautz, Penn L, GBLAM'" Subject: RE: [Speermint] Basic Peering Requirements Date: Wed, 18 Oct 2006 14:40:15 -0400 Message-ID: <00b701c6f2e4$dbdc48f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAAAoN6wAAER/jA= In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0DE728E4@ACCLUST02EVS1.ugd.att.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In most federations today, "advertisement" is in the registry; all of the reachable numbers are in the registry. That may not work for everyone, and we may need a mechanism that is two step (look up number to get network, and then federations have lists of networks they can reach). You probably combine that step with the "which ingress point" lookup, so it's number@domain query and it yields number@fqdn entry or an error. Federations that maintain full registries would make that a single query (number or number@localdomain in, number@fqdn out). Of course "number" could be "user". I think it's manually maintained, and it's a simple table (list of domains reachable by this federation). When a peer is added or deleted, or that peer, if it's a transit peer, makes new arrangements, then the list changes. Due to actual agreements, I suspect that list is querier dependent (that is, the federation may not have full symmetry of peering, and transit networks may not be able to offer transit from any peer to any indirect peer). That's a local matter for the federation, if it allows such arrangements. Brian > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] > Sent: Wednesday, October 18, 2006 2:06 PM > To: Brian Rosen > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > > So, how does a Federation "advertise"? I hope we're not talking about > building something TRIP-like. > Route advertisements may be the best way for IP routing but it's not a > slam dunk that they fit here. > That was the wrong answer for E.164, for example, because the address > space had different properties. > > Penn > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 18, 2006 1:55 PM > To: 'Michael Hammer (mhammer)'; 'Stastny Richard'; 'Otmar Lendl'; 'Daryl > Malas' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > To me, this is off the deep end. > > I think we don't care what federations a destination network belongs to. > Sorry Otmar. > > I think a federation may advertise what peers it can get you access to. > That may include transit peers, and those transit peers may get you to > other > peers through other federations. The federation advertises the > aggregate of > what networks it can reach, direct or indirect. > > I don't want a peer to have to keep relationships (how it gets to Fed X) > straight, I want it to be able to ask the federations or transit > networks it > deals with if they have a route to the destination network. > > If you take this view, then you always get what you want to know, > regardless > of how convoluted the routes are, by simple queries to each > federation/transit network. If you try to trace routes in advance > (let's > see, I want to get to network A, he is part of Fed 1 and Fed 2, I'm not > in > fed 1 or 2, hmmm, peer Z is part of fed 2 and he is also part of Fed 3, > and > I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2 > to > get to A). > > Much better if Fed 3 advertises it can reach A. > > This is how route advertisements work, and I think we should assume > that's > the best way until proven otherwise. > > So let's not talk about Federations a network belongs to, and > specifically, > don't talk about routes TO A FEDERATION, but rather routes to a > destination > network FROM a federation. > > Brian > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, October 18, 2006 1:01 PM > > To: Stastny Richard; Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > I had taken this to mean that the Transit VSP would be advertising to > > originating VSPs reachability to various federations of the form: > > > > (to get to) (contact) > > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an arbitrary > > string) > > Federation Y --> Fed-Y@VSP.com > > Federation Z --> Fed-Z@VSP.com > > > > or: > > > > Federation X --> Fed-Any@VSP.com > > Federation Y --> Fed-Any@VSP.com > > Federation Z --> Fed-Any@VSP.com > > > > If not, count me as misunderstanding too. > > > > Mike > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, October 18, 2006 10:05 AM > > > To: Otmar Lendl; Daryl Malas > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > >> If a peer is providing connectivity to multiple federations, it > > > >> should disclose AoRs providing indirect peering relationships to > > > >> servicing peers or federations. > > > > > > >Sorry, I don't understand that sentence. > > > > > > >Do you mean that when a VSP adds an AoR to a federations routing > > > >database, then it needs to discluse whether that is a direct > > > customer > > > >or just a transit offer? > > > > > > Sorry, but I do not understand the whole issue: > > > > > > An AoR is a a special type of SIP URI (a Public User > > > Identity) defining the destination network (administrative domain) > > > > > > How can it be disclosed or not, especially for a transit network? > > > It is always public. > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > > Gesendet: Mi 18.10.2006 15:54 > > > An: Daryl Malas > > > Cc: speermint@ietf.org > > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > Daryl, > > > > > > > peering requirements from one operators perspective. I can > > > post these > > > > to the list if you would like. Here is a list of peering > > > requirements > > > > (this is certainly not exhaustive, but is a platform): > > > > > > Here are my comments to that list: > > > > > > General: this seems to be a list providing details on what > > > federations have to do (or agree on). > > > > > > > Transport (Layer 1 3): > > > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > > > A federation must agree upon a common mechanism for IP transport > > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > Fine. > > > > > > > Billing: > > > > > > Good. > > > > > > > Policy: > > > > > > > > > > Could you be a bit more specific on what you mean by "policy" > > > in this context? > > > > > > > Policies may be implemented locally to the peer or via a > > > centralized > > > > mechanism within the federation. > > > > > > > > Local policies should be disclosed when creating direct peering > > > > relationships with the applicable direct peer. > > > > > > > > Local policies may supersede centralized federation policies. > > > > > > > > (Net of this...some peering relationships will be 1:1, so policies > > > > will likely be local only. Some peering relationships will > > > be 1:N, so > > > > policies will likely be implemented within DNS or some centralized > > > > mechanism.) > > > > > > Could you provide some examples of such policies? > > > > > > > Membership: > > > > > > > > A peer may be a member of multiple federations > > > > > > > > A peer must maintain compliancy for policies as defined by each > > > > federation the peer is a member of. > > > > > > > > If a peer is providing connectivity to multiple > > > federations, it should > > > > disclose AoRs providing indirect peering relationships to > servicing > > > > peers or federations. > > > > > > Sorry, I don't understand that sentence. > > > > > > Do you mean that when a VSP adds an AoR to a federations > > > routing database, then it needs to discluse whether that is a > > > direct customer or just a transit offer? > > > > > > > Peers providing indirect peering must enforce federation > > > policies on > > > > behalf of the destination federation. > > > > > > > > A peer providing indirect peering may enforce undisclosed > > > policies for > > > > processing session requests between federations. > > > > > > > > (Net of this...some peers will only desire to be part of a single > > > > federation, where wholesale carriers will likely be members of > > > > multiple > > > > federations.) > > > > > > ok. > > > > > > > Media: > > > > > > ok. > > > > > > > Routing: > > > > > > > > A peer must utilize the centralized federation routing > > > mechanism if it > > > > is available. > > > > > > ok. > > > > > > > A peer allowing another peer within a federation to provide > > > indirect > > > > peering on their behalf must select only one indirect peer to host > > > > their AoRs. > > > > > > Do you mean indirect peering *within* a federation? Let me > > > name the parties here: > > > > > > > A peer (X) allowing another peer (Y) within a federation (F1) to > > > > provide indirect peering on their behalf must select only > > > one indirect > > > > peer to host their AoRs. > > > > > > Is the idea here that all members of F1 who want to place > > > calls to X need to route the calls via Y? In that case, I > > > would not consider X to be a member of F1. Instead, Y is > > > providing transit services for X. > > > > > > Or you want to restrict X to be able to only select one other > > > VSP to host it's AoRs in total? > > > > > > > A peer must not copy routing information from or make > > > assumed routing > > > > choices on behalf of the centralized routing mechanism for > > > use locally > > > > unless it takes place through standard caching methods. > > > > > > > > A common API must be utilized and available for subscriber > > > and route > > > > provisioning on any centralized federation location function. > > > > > > > > Subscriber and routing information must be dynamically > > > updated as soon > > > > as applicable for accurate routing within the federation. > > > > > > ok > > > > > > > Performance: > > > > > > > > Performance metrics must be shared between peers as they apply > > > > directly to peering signaling and media on a consistent > > > basis within > > > > the federation. > > > > > > ok > > > > > > /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 From speermint-bounces@ietf.org Wed Oct 18 17:54:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJMF-0007hn-HT; Wed, 18 Oct 2006 17:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ4L-0001HU-MP for speermint@ietf.org; Wed, 18 Oct 2006 17:35:21 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaIiw-00057z-5n for speermint@ietf.org; Wed, 18 Oct 2006 17:13:16 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 7418C1A35F; Wed, 18 Oct 2006 23:13:12 +0200 (CEST) Date: Wed, 18 Oct 2006 23:13:12 +0200 From: Otmar Lendl To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061018211312.GO19113@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , "'Michael Hammer (mhammer)'" , 'Stastny Richard' , 'Daryl Malas' , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E30211F6C1@xmb-rtp-20b.amer.cisco.com> <00a601c6f2de$7d066370$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a601c6f2de$7d066370$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 'Stastny Richard' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/18 19:10, Brian Rosen wrote: > To me, this is off the deep end. > > I think we don't care what federations a destination network belongs to. > Sorry Otmar. Sorry Brian, but it seems like you're approaching that problem with a telco mind-set that doesn't keep in mind the scale we get to once SIP domain use reaches the same level as email domain use. In SIP terms, destination network equals domain in the SIP AoR. As I tried to get across at the interim meeting: The potential number of different destination domains (= SIP networks) is *huge*. If we ever manage to move from E.164 based addressing to SIP AoR based one, then user-owned domains will replace number-portability and thus the number of domain in play for SIP will skyrocket. > I think a federation may advertise what peers it can get you access to. Note that a federation in its simplest form is just a mathematical set of VSPs which agree to a full mesh peering setup amongst themselves. The assumption that there is some entity which acts as the manager of that federation is just that: an assumption. That may be the case for certain real-life federations (think xconnect), but that not a given at all. Anyway, if "what peers" equals "what domains", then we're already off the deep end here. The equivalent in the email space would be if all SMTP servers tell their neighbors what domains they serve. This just does not scale. > That may include transit peers, and those transit peers may get you to other > peers through other federations. The federation advertises the aggregate of > what networks it can reach, direct or indirect. Just turn the thing around: Peers advertise to each other which federations they can reach (meaning all members of those federations) and to which they are willing to provide transit to. What do we gain by this inversion? * VSPs are the players in the game which define for themselves what service they provide to whom. I just don't see the need to invent intermediaries for a role that the VSPs can play themselves. * We reduce the size of the routing table by several orders of magnitude. The set of federations will probably scale roughly with the number of commercial VSP + non-commercial peering arrangements. We're thus now in the range of where we are with AS numbers in BGP routing, instead of the number of domains active in email routing. The only cost we incur for this reduced complexity is one single lookup on the destination domain. (Whose results we need anyway if we do RFC 3263 NAPTR parsing.) > I don't want a peer to have to keep relationships (how it gets to Fed X) > straight, I want it to be able to ask the federations or transit networks it > deals with if they have a route to the destination network. Have a look at BGP: Who aggregates the routes learned there? Some external company who manages the peerings for the ISP and which feeds the forwarding table to the routers or isn't that a function that the ISP very much wants to control himself? Oh yes, sometimes an Internet Exchange operates a BGP route server to help its members with the peering, but let's be realistic: 99% of the Internet traffic doesn't need such services. Why do you think we need that for SIP? Just because that's the way it's currently done in the NANP PSTN? [...] > So let's not talk about Federations a network belongs to, and specifically, > don't talk about routes TO A FEDERATION, but rather routes to a destination > network FROM a federation. Sorry, no deal. Why do you want to make the system more complex and invent external actors which are not needed in the simple one? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 18:08:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJaX-000153-N6; Wed, 18 Oct 2006 18:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJaW-00014M-G3 for speermint@ietf.org; Wed, 18 Oct 2006 18:08:36 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJaO-0004Im-Hu for speermint@ietf.org; Wed, 18 Oct 2006 18:08:36 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9IM8ONU002843; Wed, 18 Oct 2006 16:08:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Date: Wed, 18 Oct 2006 16:08:23 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirement(s) for call routing addressing datavariability (was: RE: [Speermint] Basic Peering Requirements) Thread-Index: Acbxx36L4KiANQt2TcyiHmhLzkXZnABAAj9wAAL+IeAAC23GgA== From: "Jean-Francois Mule" To: "Uzelac, Adam" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam wrote: > Jean-Francois - well done shifting through all the noise to get at the > key requirements across 3 different voices! > Couple comments: > - I need to ask why you think the LF function is out of scope? Are > you > thinking that it's out of scope for speermint, but in scope for > ENUM/DNS? It is based on draft-ietf-speermint-terminology-06.txt, page 4, figure 1 as well as the following text: " he ENUM Working Group is primarily concerned with the acquisition of Call Addressing Data, or CAD, while the SPEERMINT Working Group is focused on the use of such CAD in routing session signaling requests." > - I also think the comment about how call addressing data is acquired > is via user input - regardless if it is E.164 or an URI. It's not > really an issue as the session has to start somewhere with something. Agreed. > It's the resolving of the data input that needs the attention both in > speermint/ENUM/DNS/SIP/etc. >=20 > Otmar - requirements for the routing decisions > Daryl - Operators maintaining control of how sessions ingress to them > Brian - specific list of proxy server domain names between peers >=20 > None of these, from what I can glean, have anything to do with how the > data is acquired - only the resolution once data is available. >=20 > -AU Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 19:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKbo-0002Sn-Mp; Wed, 18 Oct 2006 19:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaK2t-0003mL-Py for speermint@ietf.org; Wed, 18 Oct 2006 18:37:55 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJx0-00082m-QK for speermint@ietf.org; Wed, 18 Oct 2006 18:31:51 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 18 Oct 2006 15:29:18 -0700 X-IronPort-AV: i="4.09,325,1157353200"; d="scan'208"; a="596055594:sNHT47338680" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Policy Definition Date: Wed, 18 Oct 2006 18:31:47 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805EDCD48@proton.jnpr.net> In-Reply-To: <00aa01c6f2e1$0d4ea8a0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTAAOkohgAAA8LugAAmExsA= From: "Reinaldo Penno" To: "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Jean-Francois Mule" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, October 18, 2006 11:13 AM > To: 'Michael Hammer (mhammer)'; 'Jean-Francois Mule'; Reinaldo Penno > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > I don't see the signaling/media variable being useful. I tend to agree with Brian here. The policy entry/rule/whatever itself should be enough to tell to whom apply it. > Of course you have session dependent/independent Peer=20 > Independent policy. > The Federation may assert session dependent policy, as=20 > opposed to a peer asserting one. >=20 > So I think the tree is This approach is reasonable.=20 >=20 > Peer Independent > Session dependent > Session independent > Peer Dependent > Session dependent > Session independent >=20 > That's assuming my "addressing related" axis is subsumed. Addressing related?=20 >=20 > Brian > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, October 18, 2006 1:47 PM > > To: Jean-Francois Mule; Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > >=20 > > Still chasing down this thread, but a couple comments: > >=20 > > Agree with the fact that we are defining NNI versus the=20 > UNI-oriented=20 > > stuff SIPPING defined. > >=20 > > Agree that static v. dynamic and session v. session-independent are=20 > > two different dimensions: > >=20 > > "Dynamic" "Static" > > Time- Time- > > Variant Non-Variant > > +--------+--------+ > > Session- | | | > > Variant | | | > > +--------+--------+ > > Session- | | | > > Non-variant | | | > > +--------+--------+ > >=20 > > BTW, the term "session" is sometimes used to mean media and=20 > sometimes=20 > > used to mean signaling or dialog, which creates lots of confusion. > > Also, if there are restrictions on what can be put into an=20 > SDP body, I=20 > > assume that is lumped with the media (session) stuff. > >=20 > > I would prefer using terms like "signaling" for SIP constraints and=20 > > "media" for SDP/RTP constraints. > >=20 > > Are there signaling-dependent and signaling-independent=20 > aspects also? > > We may be struggling with a branch of the tree but not=20 > discovered the=20 > > root yet: > >=20 > > Root > > +--PeerIndependent > > +--PeerDependent > > +--Call/Signaling Independent > > +--Call/Signaling Dependent > > +--Session/Media Independent > > +--Session/Media Dependent > >=20 > > Mix and match to get all branches. Thoughts? > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Tuesday, October 17, 2006 9:53 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > Reinaldo wrote: > > > > I suggest we just we use the terms already defined by the > > > SIPPING WG. > > > > These are session-dependent and session-independent > > > policies. This was > > > > what Jon P. mentioned in the interim meeting. > > > > > > Yes for helping distinguish between the things that are=20 > > > session-dependent vs. session independent. But there are=20 > 2 points we=20 > > > are trying to clarify here and capture in our common=20 > understanding=20 > > > that are not addressed in the SIPPING drafts: > > > > > > a) the policy definitions in > > > draft-ietf-sipping-session-policy-framework-01.txt do not=20 > actually=20 > > > define what a policy is other than by using examples of policy=20 > > > parameters in areas which have been declared out of scope such as=20 > > > codec, and QoS. > > > > > > =3D=3D> we should keep the basic sentence Brian originally = proposed: > > > "the set of parameters and other information needed by=20 > one VSP/ASP=20 > > > to connect to another." > > > > > > b) the SIPPING drafts are geared towards *intra*-domain=20 > policies=20 > > > applicable to UAs of a given domain (UA <-> Policy > > > Server) whereas much of what we are discussing here is=20 > > > *inter*-domain, stuff between Policy Servers or PFs. This may be=20 > > > obvious but it needs to be clear in our definition. > > > > > > Jean-Francois. > > > > > > > > > > > You can find it here draft-ietf-sipping-policy-package-01 > > > > > > > > I leveraged these definitions in thse drafts: > > > > > > > > draft-ietf-speermint-architecture-02 (to be submiited soon)=20 > > > > draft-penno-sipping-peering-package-00 > > > > > > > > > > > > If that does not make everybody happy, we can try to=20 > map Brian's=20 > > > > suggestions into the SIPPING definitions and make a > > > sub-hierarchy if > > > > needed. > > > > > > > > Let me know your thoughts. > > > > > > > > Thanks, > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Monday, October 16, 2006 5:28 AM > > > > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > > While I think this definition is good, I think it is not > > > sufficient. > > > > > > > > > > I think we need to break policy up into several=20 > buckets and give=20 > > > > > each a name. > > > > > > > > > > There is policy expressed statically (possibly by a > > > contract, a web > > > > > page, or some other thing that is human understandable). > > > > > > > > > > There is policy that has to do with addressing and > > > routing, such as > > > > > which federations it belongs to or which transit networks it=20 > > > > > connects to, or what ingress gateways it uses. > > > > > > > > > > There is dynamically discoverable policy that governs > > > things beyond > > > > > addressing. At any point in time, or maybe variable with=20 > > > > > federations, the this and static policy may have the same > > > items in > > > > > them, that is, we may start with, say, a static policy on > > > how many > > > > > calls per second we accept, and later come up with an > > > automated way > > > > > to discover it. > > > > > > > > > > I propose: "static policy" "addressing (or routing) policy" > > > > > and "dynamic policy" > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > > > Sent: Monday, October 16, 2006 6:15 AM > > > > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > > > > "In the context of session peering, a policy is defined as > > > > > the set of > > > > > > parameters and other information needed by one VSP to > > > connect to > > > > > > another. A policy may be agreed to by Peers, or > > > specified by some > > > > > > explicit protocol mechanism, or defined by a contract in a > > > > > Federation. > > > > > > A policy is typically applicable to multiple sessions: > > > it is not a > > > > > > per-call specific." > > > > > > > > > > > > Notes: > > > > > > - VSP or VSP/ASP to re-use the ecrit > > > terminology in order to > > > > > > integrate other types of session peering per the=20 > comments that > > > > this > > > > > > should not be voice-specific; > > > > > > - it incorporates the comments received on the fact > > > > > that how a policy > > > > > > is agreed to, or specify by is open to various models > > > > > (Daryl's "agreed > > > > > > to by Peers" and Richard's comment on the fact that the > > > > > reference to > > > > > > federation in this definition is not needed) > > > > > > - it does not prevent a VSP from including > > > endpoint-related > > > > > > parameters as long as those are representing what the > > > VSP think is > > > > > > required to 'connect' (per David's question) > > > > > > > > > > > > Jean-Francois. > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 18 20:22:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLfe-0006rw-Vz; Wed, 18 Oct 2006 20:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLfd-0006rC-JU for speermint@ietf.org; Wed, 18 Oct 2006 20:22:01 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLfc-00044M-Ck for speermint@ietf.org; Wed, 18 Oct 2006 20:22:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaLfQ-0000cs-DM; Wed, 18 Oct 2006 19:21:48 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Michael Hammer \(mhammer\)'" , "'Jean-Francois Mule'" Subject: RE: [Speermint] Policy Definition Date: Wed, 18 Oct 2006 20:21:53 -0400 Message-ID: <02cb01c6f314$96ba11f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTAAOkohgAAA8LugAAmExsAAA9xM8A== In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805EDCD48@proton.jnpr.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > > > That's assuming my "addressing related" axis is subsumed. > > > Addressing related? In my email starting this discussion I said: >There is policy that has to do with addressing and routing, such as which >federations it belongs to or which transit networks it connects to, or what >ingress gateways it uses. I broke out addressing policy (and wanted a term) because it really is the fundamental part of peering, whereas the other stuff is more secondary. We don't really NEED to break out the addressing/routing part, but I thought it made some sense to. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 05:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTli-0003DQ-Mj; Thu, 19 Oct 2006 05:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTlg-000361-PT for speermint@ietf.org; Thu, 19 Oct 2006 05:00:48 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaTlf-0003AA-A0 for speermint@ietf.org; Thu, 19 Oct 2006 05:00:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: [Speermint] Requirement(s) for call routing addressingdatavariability (was: RE: [Speermint] Basic Peering Requirements) Date: Thu, 19 Oct 2006 10:56:56 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BA8@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirement(s) for call routing addressingdatavariability (was: RE: [Speermint] Basic Peering Requirements) Thread-Index: Acbxx36L4KiANQt2TcyiHmhLzkXZnABAAj9wAAL+IeAAC23GgAAW1BmT References: From: "Stastny Richard" To: "Jean-Francois Mule" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Adam wrote: >> Jean-Francois - well done shifting through all the noise to get at = the >> key requirements across 3 different voices! >> Couple comments: >> - I need to ask why you think the LF function is out of scope? Are >> you >> thinking that it's out of scope for speermint, but in scope for >> ENUM/DNS? >It is based on draft-ietf-speermint-terminology-06.txt, page 4, figure = 1 >as well as the following text: >" he ENUM Working Group is primarily > concerned with the acquisition of Call Addressing Data, or CAD, = while > the SPEERMINT Working Group is focused on the use of such CAD in > routing session signaling requests." Hmm, I understand this that ENUM (or the User) is providing an AoR. The LF is now finding out where this AoR is and how it can be reached, which is definitely withing scope of SPEERMINT =20 Richard ________________________________ Von: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Gesendet: Do 19.10.2006 00:08 An: Uzelac, Adam; speermint@ietf.org Betreff: RE: [Speermint] Requirement(s) for call routing = addressingdatavariability (was: RE: [Speermint] Basic Peering = Requirements) Adam wrote: > Jean-Francois - well done shifting through all the noise to get at the > key requirements across 3 different voices! > Couple comments: > - I need to ask why you think the LF function is out of scope? Are > you > thinking that it's out of scope for speermint, but in scope for > ENUM/DNS? It is based on draft-ietf-speermint-terminology-06.txt, page 4, figure 1 as well as the following text: " he ENUM Working Group is primarily concerned with the acquisition of Call Addressing Data, or CAD, while the SPEERMINT Working Group is focused on the use of such CAD in routing session signaling requests." > - I also think the comment about how call addressing data is acquired > is via user input - regardless if it is E.164 or an URI. It's not > really an issue as the session has to start somewhere with something. Agreed. > It's the resolving of the data input that needs the attention both in > speermint/ENUM/DNS/SIP/etc. > > Otmar - requirements for the routing decisions > Daryl - Operators maintaining control of how sessions ingress to them > Brian - specific list of proxy server domain names between peers > > None of these, from what I can glean, have anything to do with how the > data is acquired - only the resolution once data is available. > > -AU Jean-Francois. _______________________________________________ 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 From speermint-bounces@ietf.org Thu Oct 19 10:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZCd-00051B-UC; Thu, 19 Oct 2006 10:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZ9w-0000tW-Mt for speermint@ietf.org; Thu, 19 Oct 2006 10:46:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZ9m-0004Gk-Fx for speermint@ietf.org; Thu, 19 Oct 2006 10:46:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 07:46:02 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JEk2X7025492; Thu, 19 Oct 2006 10:46:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9JEjoDU025678; Thu, 19 Oct 2006 10:45:59 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 10:45:52 -0400 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] Basic Peering Requirements Date: Thu, 19 Oct 2006 10:45:51 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F9DB@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5Q From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 19 Oct 2006 14:45:52.0721 (UTC) FILETIME=[469C1410:01C6F38D] DKIM-Signature: a=rsa-sha1; q=dns; l=10655; t=1161269162; x=1162133162; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Stastny=20Richard=22=20, =0A=20=20=20=20=20=20=20= 20=22Otmar=20Lendl=22=20, =20=22Daryl=20Malas=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=QQisPEO2/vZuYCPhRMB+/HwDvxzI5hmnMB8vX/ZOTCKFY5ntYTmjIeEMLhViP/aNS61CDJtv JmKmMb1JcDsI8ayGeX9olOWpB6C6M7GUSYMSTuMK+loP4L5cu3FbEHuf; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, Which would you rather maintain and advertise: reachability to a hundred federations, or reachability to millions of VSPs? What you suggest doesn't scale. The idea here was that once you know that a VSP belongs to a federation (via ENUM and DNS), you are now looking for information that your Transit VSP supports that federation and to which signaling address of the Transit VSP to send the next signaling message. Isn't that simpler? Don't know why you want to make it harder. There can be an address from which a federation membership can be fetched, but I would rather be pointed to the answer, than scanning through lengthy membership lists to discover relationships. I think the main value is in having a federation point to the Transit providers serving a federation only. That should be a much smaller list. But, that step would not be needed by the originating VSP if it already knows what federations its own Transit VSP serves and the terminating federation is on that list. In summary, routing towards federations as an aggregation mechanism rather than individual VSPs scales better. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, October 18, 2006 1:55 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar=20 > Lendl'; 'Daryl Malas' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > To me, this is off the deep end. >=20 > I think we don't care what federations a destination network=20 > belongs to. > Sorry Otmar. >=20 > I think a federation may advertise what peers it can get you=20 > access to. > That may include transit peers, and those transit peers may=20 > get you to other peers through other federations. The=20 > federation advertises the aggregate of what networks it can=20 > reach, direct or indirect. >=20 > I don't want a peer to have to keep relationships (how it=20 > gets to Fed X) straight, I want it to be able to ask the=20 > federations or transit networks it deals with if they have a=20 > route to the destination network. >=20 > If you take this view, then you always get what you want to=20 > know, regardless of how convoluted the routes are, by simple=20 > queries to each federation/transit network. If you try to=20 > trace routes in advance (let's see, I want to get to network=20 > A, he is part of Fed 1 and Fed 2, I'm not in fed 1 or 2,=20 > hmmm, peer Z is part of fed 2 and he is also part of Fed 3,=20 > and I'm in fed 3, so I can send it to Z via fed 3, and he can=20 > send to fed 2 to get to A). >=20 > Much better if Fed 3 advertises it can reach A. >=20 > This is how route advertisements work, and I think we should=20 > assume that's the best way until proven otherwise. >=20 > So let's not talk about Federations a network belongs to, and=20 > specifically, don't talk about routes TO A FEDERATION, but=20 > rather routes to a destination network FROM a federation. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, October 18, 2006 1:01 PM > > To: Stastny Richard; Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > I had taken this to mean that the Transit VSP would be=20 > advertising to=20 > > originating VSPs reachability to various federations of the form: > >=20 > > (to get to) (contact) > > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an arbitrary > > string) > > Federation Y --> Fed-Y@VSP.com > > Federation Z --> Fed-Z@VSP.com > >=20 > > or: > >=20 > > Federation X --> Fed-Any@VSP.com > > Federation Y --> Fed-Any@VSP.com > > Federation Z --> Fed-Any@VSP.com > >=20 > > If not, count me as misunderstanding too. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, October 18, 2006 10:05 AM > > > To: Otmar Lendl; Daryl Malas > > > Cc: speermint@ietf.org > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > >> If a peer is providing connectivity to multiple=20 > federations, it=20 > > > >> should disclose AoRs providing indirect peering=20 > relationships to=20 > > > >> servicing peers or federations. > > > > > > >Sorry, I don't understand that sentence. > > > > > > >Do you mean that when a VSP adds an AoR to a federations routing=20 > > > >database, then it needs to discluse whether that is a direct > > > customer > > > >or just a transit offer? > > > > > > Sorry, but I do not understand the whole issue: > > > > > > An AoR is a a special type of SIP URI (a Public User > > > Identity) defining the destination network (administrative domain) > > > > > > How can it be disclosed or not, especially for a transit network? > > > It is always public. > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > > Gesendet: Mi 18.10.2006 15:54 > > > An: Daryl Malas > > > Cc: speermint@ietf.org > > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > Daryl, > > > > > > > peering requirements from one operators perspective. I can > > > post these > > > > to the list if you would like. Here is a list of peering > > > requirements > > > > (this is certainly not exhaustive, but is a platform): > > > > > > Here are my comments to that list: > > > > > > General: this seems to be a list providing details on what=20 > > > federations have to do (or agree on). > > > > > > > Transport (Layer 1 3): > > > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > > > A federation must agree upon a common mechanism for IP=20 > transport=20 > > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > Fine. > > > > > > > Billing: > > > > > > Good. > > > > > > > Policy: > > > > > > > > > > Could you be a bit more specific on what you mean by "policy" > > > in this context? > > > > > > > Policies may be implemented locally to the peer or via a > > > centralized > > > > mechanism within the federation. > > > > > > > > Local policies should be disclosed when creating direct peering=20 > > > > relationships with the applicable direct peer. > > > > > > > > Local policies may supersede centralized federation policies. > > > > > > > > (Net of this...some peering relationships will be 1:1,=20 > so policies=20 > > > > will likely be local only. Some peering relationships will > > > be 1:N, so > > > > policies will likely be implemented within DNS or some=20 > centralized > > > > mechanism.) > > > > > > Could you provide some examples of such policies? > > > > > > > Membership: > > > > > > > > A peer may be a member of multiple federations > > > > > > > > A peer must maintain compliancy for policies as defined by each=20 > > > > federation the peer is a member of. > > > > > > > > If a peer is providing connectivity to multiple > > > federations, it should > > > > disclose AoRs providing indirect peering relationships to=20 > > > > servicing peers or federations. > > > > > > Sorry, I don't understand that sentence. > > > > > > Do you mean that when a VSP adds an AoR to a federations routing=20 > > > database, then it needs to discluse whether that is a direct=20 > > > customer or just a transit offer? > > > > > > > Peers providing indirect peering must enforce federation > > > policies on > > > > behalf of the destination federation. > > > > > > > > A peer providing indirect peering may enforce undisclosed > > > policies for > > > > processing session requests between federations. > > > > > > > > (Net of this...some peers will only desire to be part=20 > of a single=20 > > > > federation, where wholesale carriers will likely be members of=20 > > > > multiple > > > > federations.) > > > > > > ok. > > > > > > > Media: > > > > > > ok. > > > > > > > Routing: > > > > > > > > A peer must utilize the centralized federation routing > > > mechanism if it > > > > is available. > > > > > > ok. > > > > > > > A peer allowing another peer within a federation to provide > > > indirect > > > > peering on their behalf must select only one indirect=20 > peer to host=20 > > > > their AoRs. > > > > > > Do you mean indirect peering *within* a federation? Let=20 > me name the=20 > > > parties here: > > > > > > > A peer (X) allowing another peer (Y) within a=20 > federation (F1) to=20 > > > > provide indirect peering on their behalf must select only > > > one indirect > > > > peer to host their AoRs. > > > > > > Is the idea here that all members of F1 who want to place=20 > calls to X=20 > > > need to route the calls via Y? In that case, I would not=20 > consider X=20 > > > to be a member of F1. Instead, Y is providing transit=20 > services for=20 > > > X. > > > > > > Or you want to restrict X to be able to only select one=20 > other VSP to=20 > > > host it's AoRs in total? > > > > > > > A peer must not copy routing information from or make > > > assumed routing > > > > choices on behalf of the centralized routing mechanism for > > > use locally > > > > unless it takes place through standard caching methods. > > > > > > > > A common API must be utilized and available for subscriber > > > and route > > > > provisioning on any centralized federation location function. > > > > > > > > Subscriber and routing information must be dynamically > > > updated as soon > > > > as applicable for accurate routing within the federation. > > > > > > ok > > > > > > > Performance: > > > > > > > > Performance metrics must be shared between peers as they apply=20 > > > > directly to peering signaling and media on a consistent > > > basis within > > > > the federation. > > > > > > ok > > > > > > /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 > > > > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 10:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZGe-0003Ue-Nm; Thu, 19 Oct 2006 10:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZGd-0003UI-GU for speermint@ietf.org; Thu, 19 Oct 2006 10:53:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZFz-0006GA-O7 for speermint@ietf.org; Thu, 19 Oct 2006 10:53:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2006 10:52:28 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JEqRMp029231; Thu, 19 Oct 2006 10:52:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JEqRYJ017043; Thu, 19 Oct 2006 10:52:27 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 10:52:27 -0400 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] Policy Definition Date: Thu, 19 Oct 2006 10:52:26 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F9EA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Policy Definition Thread-Index: AcbbLzEUXUhRoXc2ToSjuWWgohj6wAAAcHHgBXZBgbAABOYMYAAKUlHwACqzVTAAOkohgAAA8LugACveuTA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Jean-Francois Mule" , "Reinaldo Penno" X-OriginalArrivalTime: 19 Oct 2006 14:52:27.0371 (UTC) FILETIME=[31D6E3B0:01C6F38E] DKIM-Signature: a=rsa-sha1; q=dns; l=8958; t=1161269547; x=1162133547; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Policy=20Definition |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Jean-Francois=20Mule=22=20, =0A=20=20=20=20=20=20=20= 20=22Reinaldo=20Penno=22=20; X=v=3Dcisco.com=3B=20h=3DF60+CVv5TtTB9gi+7Fqgr95xEVY=3D; b=nj58NdZnZ9xP8awS4lML27LG86Pobta0k275LFJcVUrzGJFqHoaProl/sflsbF/L769+RdkI oNM6eL2iWMMl8LpzvsICP95yNY750T6zIBgvEbcLPuLxqZAUfU3yvucq; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org OK, so any call signaling related stuff goes into the session-independent area and these are modulo the timing variant/invariant stuff. Ok, I'll go with the flow. Mike =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, October 18, 2006 2:13 PM > To: Michael Hammer (mhammer); 'Jean-Francois Mule'; 'Reinaldo Penno' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Policy Definition >=20 > I don't see the signaling/media variable being useful. > Of course you have session dependent/independent Peer=20 > Independent policy. > The Federation may assert session dependent policy, as=20 > opposed to a peer asserting one. >=20 > So I think the tree is >=20 > Peer Independent > Session dependent > Session independent > Peer Dependent > Session dependent > Session independent >=20 > That's assuming my "addressing related" axis is subsumed. >=20 > Brian > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, October 18, 2006 1:47 PM > > To: Jean-Francois Mule; Reinaldo Penno > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Policy Definition > >=20 > > Still chasing down this thread, but a couple comments: > >=20 > > Agree with the fact that we are defining NNI versus the=20 > UNI-oriented=20 > > stuff SIPPING defined. > >=20 > > Agree that static v. dynamic and session v. session-independent are=20 > > two different dimensions: > >=20 > > "Dynamic" "Static" > > Time- Time- > > Variant Non-Variant > > +--------+--------+ > > Session- | | | > > Variant | | | > > +--------+--------+ > > Session- | | | > > Non-variant | | | > > +--------+--------+ > >=20 > > BTW, the term "session" is sometimes used to mean media and=20 > sometimes=20 > > used to mean signaling or dialog, which creates lots of confusion. > > Also, if there are restrictions on what can be put into an=20 > SDP body, I=20 > > assume that is lumped with the media (session) stuff. > >=20 > > I would prefer using terms like "signaling" for SIP constraints and=20 > > "media" for SDP/RTP constraints. > >=20 > > Are there signaling-dependent and signaling-independent=20 > aspects also? > > We may be struggling with a branch of the tree but not=20 > discovered the=20 > > root yet: > >=20 > > Root > > +--PeerIndependent > > +--PeerDependent > > +--Call/Signaling Independent > > +--Call/Signaling Dependent > > +--Session/Media Independent > > +--Session/Media Dependent > >=20 > > Mix and match to get all branches. Thoughts? > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Tuesday, October 17, 2006 9:53 AM > > > To: Reinaldo Penno > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Policy Definition > > > > > > Reinaldo wrote: > > > > I suggest we just we use the terms already defined by the > > > SIPPING WG. > > > > These are session-dependent and session-independent > > > policies. This was > > > > what Jon P. mentioned in the interim meeting. > > > > > > Yes for helping distinguish between the things that are=20 > > > session-dependent vs. session independent. But there are=20 > 2 points we=20 > > > are trying to clarify here and capture in our common=20 > understanding=20 > > > that are not addressed in the SIPPING drafts: > > > > > > a) the policy definitions in > > > draft-ietf-sipping-session-policy-framework-01.txt do not=20 > actually=20 > > > define what a policy is other than by using examples of policy=20 > > > parameters in areas which have been declared out of scope such as=20 > > > codec, and QoS. > > > > > > =3D=3D> we should keep the basic sentence Brian originally = proposed: > > > "the set of parameters and other information needed by=20 > one VSP/ASP=20 > > > to connect to another." > > > > > > b) the SIPPING drafts are geared towards *intra*-domain=20 > policies=20 > > > applicable to UAs of a given domain (UA <-> Policy > > > Server) whereas much of what we are discussing here is=20 > > > *inter*-domain, stuff between Policy Servers or PFs. This may be=20 > > > obvious but it needs to be clear in our definition. > > > > > > Jean-Francois. > > > > > > > > > > > You can find it here draft-ietf-sipping-policy-package-01 > > > > > > > > I leveraged these definitions in thse drafts: > > > > > > > > draft-ietf-speermint-architecture-02 (to be submiited soon)=20 > > > > draft-penno-sipping-peering-package-00 > > > > > > > > > > > > If that does not make everybody happy, we can try to=20 > map Brian's=20 > > > > suggestions into the SIPPING definitions and make a > > > sub-hierarchy if > > > > needed. > > > > > > > > Let me know your thoughts. > > > > > > > > Thanks, > > > > > > > > Reinaldo > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Monday, October 16, 2006 5:28 AM > > > > > To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz' > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > > While I think this definition is good, I think it is not > > > sufficient. > > > > > > > > > > I think we need to break policy up into several=20 > buckets and give=20 > > > > > each a name. > > > > > > > > > > There is policy expressed statically (possibly by a > > > contract, a web > > > > > page, or some other thing that is human understandable). > > > > > > > > > > There is policy that has to do with addressing and > > > routing, such as > > > > > which federations it belongs to or which transit networks it=20 > > > > > connects to, or what ingress gateways it uses. > > > > > > > > > > There is dynamically discoverable policy that governs > > > things beyond > > > > > addressing. At any point in time, or maybe variable with=20 > > > > > federations, the this and static policy may have the same > > > items in > > > > > them, that is, we may start with, say, a static policy on > > > how many > > > > > calls per second we accept, and later come up with an > > > automated way > > > > > to discover it. > > > > > > > > > > I propose: "static policy" "addressing (or routing) policy" > > > > > and "dynamic policy" > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > > > > Sent: Monday, October 16, 2006 6:15 AM > > > > > > To: Brian Rosen; Daryl Malas; David Schwartz > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Policy Definition > > > > > > > > > > > > > > > > > > Here is my read of the thread on the 'policy' definition: > > > > > > "In the context of session peering, a policy is defined as > > > > > the set of > > > > > > parameters and other information needed by one VSP to > > > connect to > > > > > > another. A policy may be agreed to by Peers, or > > > specified by some > > > > > > explicit protocol mechanism, or defined by a contract in a > > > > > Federation. > > > > > > A policy is typically applicable to multiple sessions: > > > it is not a > > > > > > per-call specific." > > > > > > > > > > > > Notes: > > > > > > - VSP or VSP/ASP to re-use the ecrit > > > terminology in order to > > > > > > integrate other types of session peering per the=20 > comments that > > > > this > > > > > > should not be voice-specific; > > > > > > - it incorporates the comments received on the fact > > > > > that how a policy > > > > > > is agreed to, or specify by is open to various models > > > > > (Daryl's "agreed > > > > > > to by Peers" and Richard's comment on the fact that the > > > > > reference to > > > > > > federation in this definition is not needed) > > > > > > - it does not prevent a VSP from including > > > endpoint-related > > > > > > parameters as long as those are representing what the > > > VSP think is > > > > > > required to 'connect' (per David's question) > > > > > > > > > > > > Jean-Francois. > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 11:02:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZPC-0008Cl-KF; Thu, 19 Oct 2006 11:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZPB-0008CZ-Nr for speermint@ietf.org; Thu, 19 Oct 2006 11:01:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZOu-0007kt-HS for speermint@ietf.org; Thu, 19 Oct 2006 11:01:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 08:01:40 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JF1e1a002337; Thu, 19 Oct 2006 11:01:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9JF1eDM001213; Thu, 19 Oct 2006 11:01:40 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:01:39 -0400 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] Requirement(s) for call routing addressingdatavariability (was: RE: [Speermint] Basic Peering Requirements) Date: Thu, 19 Oct 2006 11:01:38 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F9F9@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Requirement(s) for call routing addressingdatavariability (was: RE: [Speermint] Basic Peering Requirements) Thread-Index: Acbxx36L4KiANQt2TcyiHmhLzkXZnABAAj9wAAL+IeAAC23GgAAjYCeQ From: "Michael Hammer \(mhammer\)" To: "Jean-Francois Mule" , "Uzelac, Adam" , X-OriginalArrivalTime: 19 Oct 2006 15:01:39.0827 (UTC) FILETIME=[7B20FC30:01C6F38F] DKIM-Signature: a=rsa-sha1; q=dns; l=2397; t=1161270100; x=1162134100; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Requirement(s)=20for=20call=20routing=20addressing datavariability=20(was=3A=20RE=3A=20[Speermint]=20Basic=20Peering=20Require ments) |To:=22Jean-Francois=20Mule=22=20, =0A=20=20=20=20=20= 20=20=20=22Uzelac, =20Adam=22=20, =20; X=v=3Dcisco.com=3B=20h=3D3aVDuDrhD3hA1ywpvKFuHQlF+T4=3D; b=nr4YYGWKFATIUuU1uk4yVapZjEniIsrYCIVCW6fct2xXlYjtFqg+FbKa3pKbIwJYxK1dIeGu huO6An+6HiyJSOE03VpCFEUOHRzvqcrGd0CzUXeEoyLO6RxfEbfy5JvB; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The term "acquisition" seems strange. ENUM translates an E.164 into a domain name from which a URI mapping can be retrieved. That URI determines what protocol and addressing information may then be used by Speermint to target peering points and complete the communications. In many cases, these will be SIP URIs leading to completion of calls via SIP-based mechanisms. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Wednesday, October 18, 2006 6:08 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Requirement(s) for call routing=20 > addressingdatavariability (was: RE: [Speermint] Basic Peering=20 > Requirements) >=20 > Adam wrote: > > Jean-Francois - well done shifting through all the noise to=20 > get at the=20 > > key requirements across 3 different voices! > > Couple comments: > > - I need to ask why you think the LF function is out of=20 > scope? Are=20 > > you thinking that it's out of scope for speermint, but in scope for=20 > > ENUM/DNS? >=20 > It is based on draft-ietf-speermint-terminology-06.txt, page=20 > 4, figure 1 as well as the following text: > " he ENUM Working Group is primarily > concerned with the acquisition of Call Addressing Data, or=20 > CAD, while > the SPEERMINT Working Group is focused on the use of such CAD in > routing session signaling requests." >=20 >=20 > > - I also think the comment about how call addressing data=20 > is acquired=20 > > is via user input - regardless if it is E.164 or an URI. It's not=20 > > really an issue as the session has to start somewhere with=20 > something. > Agreed. >=20 > > It's the resolving of the data input that needs the=20 > attention both in=20 > > speermint/ENUM/DNS/SIP/etc. > >=20 > > Otmar - requirements for the routing decisions Daryl - Operators=20 > > maintaining control of how sessions ingress to them Brian -=20 > specific=20 > > list of proxy server domain names between peers > >=20 > > None of these, from what I can glean, have anything to do=20 > with how the=20 > > data is acquired - only the resolution once data is available. > >=20 > > -AU >=20 > Jean-Francois. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 11:39:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzK-0003pN-Aj; Thu, 19 Oct 2006 11:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzI-0003mD-Vj for speermint@ietf.org; Thu, 19 Oct 2006 11:39:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZkD-00057f-P7 for speermint@ietf.org; Thu, 19 Oct 2006 11:23:44 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 08:23:42 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JFNfOJ006177; Thu, 19 Oct 2006 11:23:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JFNeYJ027310; Thu, 19 Oct 2006 11:23:40 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:23:40 -0400 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] TLS related requirements for speermint ID Date: Thu, 19 Oct 2006 11:23:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211FA2C@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS related requirements for speermint ID Thread-Index: AcbyAldCYxDkox8FRLipDq2U4cJoIQBj8J5w From: "Michael Hammer \(mhammer\)" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 19 Oct 2006 15:23:40.0090 (UTC) FILETIME=[8E1121A0:01C6F392] DKIM-Signature: a=rsa-sha1; q=dns; l=5510; t=1161271421; x=1162135421; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20TLS=20related=20requirements=20for=20speermint=20I D |To:=22Jean-Francois=20Mule=22=20, =20; X=v=3Dcisco.com=3B=20h=3DzhDIrpj3cpwKeAhwndKsH2PH/sE=3D; b=0BPQlJi2CYaQBI38o3kpjpTItDjrkT63NmfTT26yHIoRECBMXkP6+YjyUxRMnFAj1n87z1fh yI9pRSEFqHuDE7NezmWhigHH9yz2fFeQAOvyFWMyJSD1WGyhA13ckXwg; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This looks to be a good start. Re: self-signed certs If bi-lateral, possible manual setups are considered, you might also look at the possibility that the two parties simply cross-certify each other. A signs a certificate for B and=20 B signs a certificate for A=20 The end result would then just be a much shorter certificate path to follow, while leaving the general process for validation the same. Mike > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Tuesday, October 17, 2006 11:38 AM > To: speermint@ietf.org > Cc: vkg@bell-labs.com > Subject: [Speermint] TLS related requirements for speermint ID >=20 > All, > =20 > --- pre-amble > At the interim meeting, we had a consensus that the goal of=20 > the requirement document is not to mandate the use of any=20 > protocol mechanisms, but when those mechanisms are in use, we=20 > should describe what's required to guarantee some levels of=20 > interoperability. > While the focus of this msg is TLS, it was also noted that=20 > other mechanisms intended to secure the lower layers of=20 > session peering like IPSec or L2/L3VPNs may exist or co-exist=20 > with L5 session security based on the threat models, keying=20 > exchange capabilities and trust relationships... FFS based on=20 > threat model. > (just wanted to note upfront this so that the thread does not deviate) >=20 > --- TLS: > At the wg's interim meeting, folks thought it would be good=20 > to add more details on what's required for 2 VSP/ASPs to=20 > "turn on" or use TLS (if/when it is enabled). The comment was=20 > that the BCP/requirement draft should go a level deeper than=20 > just saying "MUST support TLS".=20 >=20 > Here is some very first text to propose some directions. This=20 > is for review based on the SIP and SIPPING work on Identity,=20 > use of TLS, and the 2 I-Ds from Rohan and Vijay referenced below. >=20 > The intent here is to capture what 2 VSPs/ASPs should discuss=20 > and agree on in order to establish a TLS connection for sip=20 > session peering (pending the threat analysis document). >=20 >=20 > --- 1. Peers SHOULD mutually trust each other's root CAs > - Motivations: > A VSP/ASP should have control over which root CA it trusts;=20 > this may imply creating a certificate trust list to include=20 > the peer's CA for each authorized domain. > This requirement allows for the initiating side to verify=20 > that the server cert is rooted in a well-known CA. > - Derivative requirement: > SIP servers SHOULD allow the configuration of certificate=20 > trust lists in order to allow a VSP/ASP to control which=20 > peer's CAs are trusted for TLS connections. >=20 > --- 2. Peers SHOULD indicate whether their domain policies=20 > require proxy servers to inspect and verify the identity=20 > provided in SIP requests per RFC 4474. >=20 > --- 3. When TLS is used between peers, SIP servers involved=20 > in the session establishment MUST have valid X.509=20 > certificates and MUST be able to receive a TLS connection. >=20 > Motivations: > If TLS is supported for session peering, SIP servers must have valid > X.509 certificates and they should listen on the SIP TLS port=20 > for incoming connections. >=20 > --- 4. The following TLS/SIP Protocol parameters SHOULD be=20 > agreed upon as part of session peering policies: > + The version of TLS (TLSv1, TLSv1.1) > + The SIP TLS port (default 5061) > + The server-side session timeout (default 300 seconds) > + The list of supported or recommended ciphersuite > + list of trusted root CAs >=20 >=20 > --- 5. SIP entities involved in the session establishment=20 > exchanges MUST follow the following requirements: > + check certs :=20 > "the client certificate MUST contain a DNS or URI choice type=20 > in the subjectAltName which corresponds to the domain=20 > asserted in the host production of the From header URI."=20 > (from Rohan's I-D) > + check identity in cert per section 4 of=20 > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? > + add details and pointers to the use of RFC=20 > 4474 inter-domain. >=20 > =3D=3D> open questions: > These are best current practices that should be followed.=20 > We can either reference the work-in-progress IDs or paste=20 > some of the most relevant text and then refer to the I-Ds. >=20 > REFERENCEs: > - Rohan's direct peering draft > http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct > -peering-0 > 0.txt, > - Vijay's > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: >=20 > --- 6. A session peering policy SHOULD include details on SIP=20 > session establishment over TLS (see above, to be briefly=20 > summarized1111). >=20 >=20 > --- Open questions: > - should we re-iterate the requirement of RFC 4474 that=20 > self-signed certs should not be trusted unless prior key=20 > exchange has occurred? > Given the goals of speermint, should there be more guidance=20 > on the use of self-signed certs? > - should there be a minimum set of ciphersuites to recommend=20 > or leave it open? >=20 >=20 > Is this on the right track and what folks had in mind? >=20 > Comments and input are appreciated. > Jean-Francois. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 11:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaa0f-0005Py-19; Thu, 19 Oct 2006 11:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaa0d-0005LG-Jm for speermint@ietf.org; Thu, 19 Oct 2006 11:40:39 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaa0c-00019d-5w for speermint@ietf.org; Thu, 19 Oct 2006 11:40:39 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9JFak87017446; Thu, 19 Oct 2006 09:36:46 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] TLS related requirements for speermint ID Date: Thu, 19 Oct 2006 09:36:46 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS related requirements for speermint ID Thread-Index: AcbyAldCYxDkox8FRLipDq2U4cJoIQBj8J5wAABZqQA= From: "Jean-Francois Mule" To: "Michael Hammer (mhammer)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Mike, Thanks for the comments. Mike wrote: > This looks to be a good start. >=20 > Re: self-signed certs >=20 > If bi-lateral, possible manual setups are considered, you might also > look at the possibility that the two parties simply cross-certify each > other. >=20 > A signs a certificate for B and > B signs a certificate for A Do we consider these as part of best current practices or even something worth logging in a requirement doc? I originally wondered whether we should mention this. Folks will do this anyway and it keeps re-inforcing the small clubs/federation models with limited scale as opposed to open, flexible and dynamic peering. That said, I'm open to adding a sentence to mention this case if folks believe it should be explicitly captured as a possibility. =20 > The end result would then just be a much shorter certificate path to > follow, while leaving the general process for validation the same. Jean-Francois. >=20 > Mike >=20 >=20 >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Tuesday, October 17, 2006 11:38 AM > > To: speermint@ietf.org > > Cc: vkg@bell-labs.com > > Subject: [Speermint] TLS related requirements for speermint ID > > > > All, > > > > --- pre-amble > > At the interim meeting, we had a consensus that the goal of > > the requirement document is not to mandate the use of any > > protocol mechanisms, but when those mechanisms are in use, we > > should describe what's required to guarantee some levels of > > interoperability. > > While the focus of this msg is TLS, it was also noted that > > other mechanisms intended to secure the lower layers of > > session peering like IPSec or L2/L3VPNs may exist or co-exist > > with L5 session security based on the threat models, keying > > exchange capabilities and trust relationships... FFS based on > > threat model. > > (just wanted to note upfront this so that the thread does not > deviate) > > > > --- TLS: > > At the wg's interim meeting, folks thought it would be good > > to add more details on what's required for 2 VSP/ASPs to > > "turn on" or use TLS (if/when it is enabled). The comment was > > that the BCP/requirement draft should go a level deeper than > > just saying "MUST support TLS". > > > > Here is some very first text to propose some directions. This > > is for review based on the SIP and SIPPING work on Identity, > > use of TLS, and the 2 I-Ds from Rohan and Vijay referenced below. > > > > The intent here is to capture what 2 VSPs/ASPs should discuss > > and agree on in order to establish a TLS connection for sip > > session peering (pending the threat analysis document). > > > > > > --- 1. Peers SHOULD mutually trust each other's root CAs > > - Motivations: > > A VSP/ASP should have control over which root CA it trusts; > > this may imply creating a certificate trust list to include > > the peer's CA for each authorized domain. > > This requirement allows for the initiating side to verify > > that the server cert is rooted in a well-known CA. > > - Derivative requirement: > > SIP servers SHOULD allow the configuration of certificate > > trust lists in order to allow a VSP/ASP to control which > > peer's CAs are trusted for TLS connections. > > > > --- 2. Peers SHOULD indicate whether their domain policies > > require proxy servers to inspect and verify the identity > > provided in SIP requests per RFC 4474. > > > > --- 3. When TLS is used between peers, SIP servers involved > > in the session establishment MUST have valid X.509 > > certificates and MUST be able to receive a TLS connection. > > > > Motivations: > > If TLS is supported for session peering, SIP servers must have valid > > X.509 certificates and they should listen on the SIP TLS port > > for incoming connections. > > > > --- 4. The following TLS/SIP Protocol parameters SHOULD be > > agreed upon as part of session peering policies: > > + The version of TLS (TLSv1, TLSv1.1) > > + The SIP TLS port (default 5061) > > + The server-side session timeout (default 300 seconds) > > + The list of supported or recommended ciphersuite > > + list of trusted root CAs > > > > > > --- 5. SIP entities involved in the session establishment > > exchanges MUST follow the following requirements: > > + check certs : > > "the client certificate MUST contain a DNS or URI choice type > > in the subjectAltName which corresponds to the domain > > asserted in the host production of the From header URI." > > (from Rohan's I-D) > > + check identity in cert per section 4 of > > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? > > + add details and pointers to the use of RFC > > 4474 inter-domain. > > > > =3D=3D> open questions: > > These are best current practices that should be followed. > > We can either reference the work-in-progress IDs or paste > > some of the most relevant text and then refer to the I-Ds. > > > > REFERENCEs: > > - Rohan's direct peering draft > > http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct > > -peering-0 > > 0.txt, > > - Vijay's > > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: > > > > --- 6. A session peering policy SHOULD include details on SIP > > session establishment over TLS (see above, to be briefly > > summarized1111). > > > > > > --- Open questions: > > - should we re-iterate the requirement of RFC 4474 that > > self-signed certs should not be trusted unless prior key > > exchange has occurred? > > Given the goals of speermint, should there be more guidance > > on the use of self-signed certs? > > - should there be a minimum set of ciphersuites to recommend > > or leave it open? > > > > > > Is this on the right track and what folks had in mind? > > > > Comments and input are appreciated. > > Jean-Francois. > > > > > > _______________________________________________ > > 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 From speermint-bounces@ietf.org Thu Oct 19 12:29:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaals-0001Ei-7c; Thu, 19 Oct 2006 12:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaalr-0001Cy-74 for speermint@ietf.org; Thu, 19 Oct 2006 12:29:27 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaalk-00039H-32 for speermint@ietf.org; Thu, 19 Oct 2006 12:29:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaalQ-0005NX-RF; Thu, 19 Oct 2006 11:29:01 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Otmar Lendl'" , "'Daryl Malas'" Subject: RE: [Speermint] Basic Peering Requirements Date: Thu, 19 Oct 2006 12:29:03 -0400 Message-ID: <046601c6f39b$b2950970$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30211F9DB@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Which scaling limits are you working from, PSTN or the Internet? Reachability to thousands (or tens of thousands, or a couple hundred thousand) VSPs is what I want. I want the "best" route to a VSP (which I may only know by a TN in a registry). A federation is one potential route. Scaling to tens or hundreds of thousands of routes is usually considered to be quite reasonable, and even millions is quite reasonable for L5 routing since we don't need to keep the routes in memory. Certainly a federation returning VSP reachability to that many VSPs is easy. If all I have is one transit peer, and no federations, then I can launch my call and if it doesn't work, all I can do is send it via the PSTN. Same if I am only a member of one federation. As soon as I have two routes, I need to know where to send it for the next hop. I have the destination VSP, I choose a route: VSP in, route out. I check my routes for reachability. If there is only one route, I send out the call that way. If I have more than one route, then I need a cost metric, and we don't have to go there right now. The point is that for each route, what I want is the complete set of VSPs that route can get me to. Seems like getting that information directly is the simplest way to go. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, October 19, 2006 10:46 AM > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Brian, > > Which would you rather maintain and advertise: > > reachability to a hundred federations, or > reachability to millions of VSPs? > > What you suggest doesn't scale. > > The idea here was that once you know that a VSP belongs to a federation > (via ENUM and DNS), you are now looking for information that your > Transit VSP supports that federation and to which signaling address of > the Transit VSP to send the next signaling message. > > Isn't that simpler? Don't know why you want to make it harder. > > There can be an address from which a federation membership can be > fetched, but I would rather be pointed to the answer, than scanning > through lengthy membership lists to discover relationships. I think the > main value is in having a federation point to the Transit providers > serving a federation only. That should be a much smaller list. But, > that step would not be needed by the originating VSP if it already knows > what federations its own Transit VSP serves and the terminating > federation is on that list. > > In summary, routing towards federations as an aggregation mechanism > rather than individual VSPs scales better. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, October 18, 2006 1:55 PM > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar > > Lendl'; 'Daryl Malas' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > To me, this is off the deep end. > > > > I think we don't care what federations a destination network > > belongs to. > > Sorry Otmar. > > > > I think a federation may advertise what peers it can get you > > access to. > > That may include transit peers, and those transit peers may > > get you to other peers through other federations. The > > federation advertises the aggregate of what networks it can > > reach, direct or indirect. > > > > I don't want a peer to have to keep relationships (how it > > gets to Fed X) straight, I want it to be able to ask the > > federations or transit networks it deals with if they have a > > route to the destination network. > > > > If you take this view, then you always get what you want to > > know, regardless of how convoluted the routes are, by simple > > queries to each federation/transit network. If you try to > > trace routes in advance (let's see, I want to get to network > > A, he is part of Fed 1 and Fed 2, I'm not in fed 1 or 2, > > hmmm, peer Z is part of fed 2 and he is also part of Fed 3, > > and I'm in fed 3, so I can send it to Z via fed 3, and he can > > send to fed 2 to get to A). > > > > Much better if Fed 3 advertises it can reach A. > > > > This is how route advertisements work, and I think we should > > assume that's the best way until proven otherwise. > > > > So let's not talk about Federations a network belongs to, and > > specifically, don't talk about routes TO A FEDERATION, but > > rather routes to a destination network FROM a federation. > > > > Brian > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Wednesday, October 18, 2006 1:01 PM > > > To: Stastny Richard; Otmar Lendl; Daryl Malas > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > I had taken this to mean that the Transit VSP would be > > advertising to > > > originating VSPs reachability to various federations of the form: > > > > > > (to get to) (contact) > > > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an arbitrary > > > string) > > > Federation Y --> Fed-Y@VSP.com > > > Federation Z --> Fed-Z@VSP.com > > > > > > or: > > > > > > Federation X --> Fed-Any@VSP.com > > > Federation Y --> Fed-Any@VSP.com > > > Federation Z --> Fed-Any@VSP.com > > > > > > If not, count me as misunderstanding too. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Wednesday, October 18, 2006 10:05 AM > > > > To: Otmar Lendl; Daryl Malas > > > > Cc: speermint@ietf.org > > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > > > >> If a peer is providing connectivity to multiple > > federations, it > > > > >> should disclose AoRs providing indirect peering > > relationships to > > > > >> servicing peers or federations. > > > > > > > > >Sorry, I don't understand that sentence. > > > > > > > > >Do you mean that when a VSP adds an AoR to a federations routing > > > > >database, then it needs to discluse whether that is a direct > > > > customer > > > > >or just a transit offer? > > > > > > > > Sorry, but I do not understand the whole issue: > > > > > > > > An AoR is a a special type of SIP URI (a Public User > > > > Identity) defining the destination network (administrative domain) > > > > > > > > How can it be disclosed or not, especially for a transit network? > > > > It is always public. > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > > > Gesendet: Mi 18.10.2006 15:54 > > > > An: Daryl Malas > > > > Cc: speermint@ietf.org > > > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > > > > > > Daryl, > > > > > > > > > peering requirements from one operators perspective. I can > > > > post these > > > > > to the list if you would like. Here is a list of peering > > > > requirements > > > > > (this is certainly not exhaustive, but is a platform): > > > > > > > > Here are my comments to that list: > > > > > > > > General: this seems to be a list providing details on what > > > > federations have to do (or agree on). > > > > > > > > > Transport (Layer 1 3): > > > > > > > > > > Peering must utilize IP as the primary mechanism for peering. > > > > > > > > > > A federation must agree upon a common mechanism for IP > > transport > > > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > > > Fine. > > > > > > > > > Billing: > > > > > > > > Good. > > > > > > > > > Policy: > > > > > > > > > > > > > Could you be a bit more specific on what you mean by "policy" > > > > in this context? > > > > > > > > > Policies may be implemented locally to the peer or via a > > > > centralized > > > > > mechanism within the federation. > > > > > > > > > > Local policies should be disclosed when creating direct peering > > > > > relationships with the applicable direct peer. > > > > > > > > > > Local policies may supersede centralized federation policies. > > > > > > > > > > (Net of this...some peering relationships will be 1:1, > > so policies > > > > > will likely be local only. Some peering relationships will > > > > be 1:N, so > > > > > policies will likely be implemented within DNS or some > > centralized > > > > > mechanism.) > > > > > > > > Could you provide some examples of such policies? > > > > > > > > > Membership: > > > > > > > > > > A peer may be a member of multiple federations > > > > > > > > > > A peer must maintain compliancy for policies as defined by each > > > > > federation the peer is a member of. > > > > > > > > > > If a peer is providing connectivity to multiple > > > > federations, it should > > > > > disclose AoRs providing indirect peering relationships to > > > > > servicing peers or federations. > > > > > > > > Sorry, I don't understand that sentence. > > > > > > > > Do you mean that when a VSP adds an AoR to a federations routing > > > > database, then it needs to discluse whether that is a direct > > > > customer or just a transit offer? > > > > > > > > > Peers providing indirect peering must enforce federation > > > > policies on > > > > > behalf of the destination federation. > > > > > > > > > > A peer providing indirect peering may enforce undisclosed > > > > policies for > > > > > processing session requests between federations. > > > > > > > > > > (Net of this...some peers will only desire to be part > > of a single > > > > > federation, where wholesale carriers will likely be members of > > > > > multiple > > > > > federations.) > > > > > > > > ok. > > > > > > > > > Media: > > > > > > > > ok. > > > > > > > > > Routing: > > > > > > > > > > A peer must utilize the centralized federation routing > > > > mechanism if it > > > > > is available. > > > > > > > > ok. > > > > > > > > > A peer allowing another peer within a federation to provide > > > > indirect > > > > > peering on their behalf must select only one indirect > > peer to host > > > > > their AoRs. > > > > > > > > Do you mean indirect peering *within* a federation? Let > > me name the > > > > parties here: > > > > > > > > > A peer (X) allowing another peer (Y) within a > > federation (F1) to > > > > > provide indirect peering on their behalf must select only > > > > one indirect > > > > > peer to host their AoRs. > > > > > > > > Is the idea here that all members of F1 who want to place > > calls to X > > > > need to route the calls via Y? In that case, I would not > > consider X > > > > to be a member of F1. Instead, Y is providing transit > > services for > > > > X. > > > > > > > > Or you want to restrict X to be able to only select one > > other VSP to > > > > host it's AoRs in total? > > > > > > > > > A peer must not copy routing information from or make > > > > assumed routing > > > > > choices on behalf of the centralized routing mechanism for > > > > use locally > > > > > unless it takes place through standard caching methods. > > > > > > > > > > A common API must be utilized and available for subscriber > > > > and route > > > > > provisioning on any centralized federation location function. > > > > > > > > > > Subscriber and routing information must be dynamically > > > > updated as soon > > > > > as applicable for accurate routing within the federation. > > > > > > > > ok > > > > > > > > > Performance: > > > > > > > > > > Performance metrics must be shared between peers as they apply > > > > > directly to peering signaling and media on a consistent > > > > basis within > > > > > the federation. > > > > > > > > ok > > > > > > > > /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 From speermint-bounces@ietf.org Thu Oct 19 12:33:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaapM-00007x-L0; Thu, 19 Oct 2006 12:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaapL-00007m-Jk for speermint@ietf.org; Thu, 19 Oct 2006 12:33:03 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaapG-0003kp-2R for speermint@ietf.org; Thu, 19 Oct 2006 12:33:03 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9JGWuWN007081; Thu, 19 Oct 2006 10:32:57 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt Date: Thu, 19 Oct 2006 10:32:56 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt Thread-Index: Acbx500a79c3oPLgR0KmXt543LeGQABr4gPg From: "Jean-Francois Mule" To: "Avshalom Houri" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Avshalom, Thank you for writing this draft. In your draft, there are a few examples that just point to different = types of session descriptors in the session establishment (page mode, = MSRP-based session): in those examples, can you point to specific = requirements that would be new or different than for the ones for voip? There are other examples however (like 3.1.) which provide new = requirements: users from different domains subscribing to each other's = presence info. Could you provide more specific examples of this kind of use cases using = common presence/simple/xmpp terminology and well-known URI schemes for = presence?=20 The reason I'm asking is that I'm looking at this wanting to capture = beyond "VoIP" requirements and it is hard to figure out what you think = is missing or should be done to allow inter-domain presence info = retrieval (if anything). --- proposal (with poor wording): Based on a well-known URI (for e.g. pres:), it SHOULD be possible to = determine whether the domain servicing the URI (VSP/ASP) allows session = peering, and if it does, it SHOULD be possible to locate the domain's = policy and signaling functions? i.e. Given that I know Bob's presence URI (e.g. pres:bob@example.com?), my = client application should be able to query example.com with my own = domain's credentials and figure out whether example.com allows me to = see/retrieve Bob's presence, and if so, where I need to subscribe to get = it? Excuse my lack of knowledge here but: - is there an equivalent of RFC3263 to locate presence servers?=20 - are things like sip identity in play in here: what are the holes? Jean-Francois. ________________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Tuesday, October 17, 2006 6:26 AM To: speermint@ietf.org Subject: [Speermint] Fw: = I-DACTION:draft-houri-speermint-usecase-presence-00.txt FYI. Title should have been "Presence and IM use cases"=20 --Avshalom Real Time Collaboration Standards ----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 -----=20 Internet-Drafts@ietf.org=20 17/10/2006 00:50=20 Please respond to internet-drafts@ietf.org To i-d-announce@ietf.org=20 cc Subject I-D ACTION:draft-houri-speermint-usecase-presence-00.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: RTC Provisioning Requirements =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 : A. Houri, et al. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = : draft-houri-speermint-usecase-presence-00.txt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 12 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2006-10-16 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 The document describes several use cases for peering between two or =A0 more communities that provide real time communications services and =A0 presence and IM in particular. =A0The communities create a peering =A0 relationship between themselves thus enabling their users to =A0 collaborate with users on other communities. =A0The target of the =A0 document is to help understanding the requirements for peering =A0 between domains with regard to real time services A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-houri-speermint-usecase-presenc= e-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-houri-speermint-usecase-presence-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mailserv@ietf.org. In the body type: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "FILE = /internet-drafts/draft-houri-speermint-usecase-presence-00.txt". =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 NOTE: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The mail server at ietf.org can = return the document in =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 MIME-encoded form by using the "mpack" = utility. =A0To use this =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 feature, insert the command "ENCODING = mime" before the "FILE" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 command. =A0To decode the response(s), = you will need "munpack" or =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a MIME-compliant mail reader. = =A0Different MIME-compliant mail readers =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exhibit different behavior, especially = when dealing with =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "multipart" MIME messages (i.e. = documents which have been split =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 up into multiple messages), so check = your local documentation on =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-speermint-usecas= e-presence-00.txt_______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 13:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabRq-0006JG-K1; Thu, 19 Oct 2006 13:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabQH-000599-Vj for speermint@ietf.org; Thu, 19 Oct 2006 13:11:13 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GabEL-0002WA-5O for speermint@ietf.org; Thu, 19 Oct 2006 12:58:59 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 19 Oct 2006 09:56:20 -0700 X-IronPort-AV: i="4.09,330,1157353200"; d="scan'208"; a="604341180:sNHT46689778" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] TLS related requirements for speermint ID Date: Thu, 19 Oct 2006 12:58:41 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805EDCE71@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS related requirements for speermint ID Thread-index: AcbyAldCYxDkox8FRLipDq2U4cJoIQBj8J5wAABZqQAAAnidsA== From: "Reinaldo Penno" To: "Jean-Francois Mule" , "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hello Jean, For TLS specifically, isn't it better just to say peers should follow RFC4346 (or 2246) it they want implement TLS? Is there a need to say that peers need to agree on a port?! This is a built-in requirement for DNS/ENUM, SIP, and any layer 4 protocol out there. Do not take it the wrong way but it seems stating the obvious.=20 As for the more security related things, TLS already have built-in capabilities for cipher negotiation and mutual-challenge. If something fails they will get an error saying "negoiation failed", "cipher suite invalid", or something like it. Specifying the minimum set of cipher suites is a slippery slope (remember the minimum codec thread...).=20 It _seems_ to me we are compensating the general lack of TLS understanding by trying to summarize the most basic TLS requirements. IMHO we should only mention those things that somebody after reading the RFCs and/or going through a basic server-server configuration process cannot figure out. A "list of trusted root CAs" is something less obvious and specific to peering. I'm sure there are others. Regards, Reinaldo > > --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed=20 > > upon as part of session peering policies: > > + The version of TLS (TLSv1, TLSv1.1) > > + The SIP TLS port (default 5061) > > + The server-side session timeout (default 300 seconds) > > + The list of supported or recommended ciphersuite > > + list of trusted root CAs=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Thursday, October 19, 2006 8:37 AM > To: Michael Hammer (mhammer); speermint@ietf.org > Cc: vkg@bell-labs.com > Subject: RE: [Speermint] TLS related requirements for speermint ID >=20 > Mike, >=20 > Thanks for the comments. >=20 > Mike wrote: > > This looks to be a good start. > >=20 > > Re: self-signed certs > >=20 > > If bi-lateral, possible manual setups are considered, you=20 > might also=20 > > look at the possibility that the two parties simply=20 > cross-certify each=20 > > other. > >=20 > > A signs a certificate for B and > > B signs a certificate for A >=20 > Do we consider these as part of best current practices or=20 > even something worth logging in a requirement doc? > I originally wondered whether we should mention this. Folks=20 > will do this anyway and it keeps re-inforcing the small=20 > clubs/federation models with limited scale as opposed to=20 > open, flexible and dynamic peering. >=20 > That said, I'm open to adding a sentence to mention this case=20 > if folks believe it should be explicitly captured as a possibility. > =20 > > The end result would then just be a much shorter=20 > certificate path to=20 > > follow, while leaving the general process for validation the same. >=20 > Jean-Francois. >=20 > >=20 > > Mike > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Tuesday, October 17, 2006 11:38 AM > > > To: speermint@ietf.org > > > Cc: vkg@bell-labs.com > > > Subject: [Speermint] TLS related requirements for speermint ID > > > > > > All, > > > > > > --- pre-amble > > > At the interim meeting, we had a consensus that the goal of the=20 > > > requirement document is not to mandate the use of any protocol=20 > > > mechanisms, but when those mechanisms are in use, we=20 > should describe=20 > > > what's required to guarantee some levels of interoperability. > > > While the focus of this msg is TLS, it was also noted that other=20 > > > mechanisms intended to secure the lower layers of session peering=20 > > > like IPSec or L2/L3VPNs may exist or co-exist with L5 session=20 > > > security based on the threat models, keying exchange capabilities=20 > > > and trust relationships... FFS based on threat model. > > > (just wanted to note upfront this so that the thread does not > > deviate) > > > > > > --- TLS: > > > At the wg's interim meeting, folks thought it would be=20 > good to add=20 > > > more details on what's required for 2 VSP/ASPs to "turn=20 > on" or use=20 > > > TLS (if/when it is enabled). The comment was that the=20 > > > BCP/requirement draft should go a level deeper than just saying=20 > > > "MUST support TLS". > > > > > > Here is some very first text to propose some directions.=20 > This is for=20 > > > review based on the SIP and SIPPING work on Identity, use of TLS,=20 > > > and the 2 I-Ds from Rohan and Vijay referenced below. > > > > > > The intent here is to capture what 2 VSPs/ASPs should discuss and=20 > > > agree on in order to establish a TLS connection for sip session=20 > > > peering (pending the threat analysis document). > > > > > > > > > --- 1. Peers SHOULD mutually trust each other's root CAs > > > - Motivations: > > > A VSP/ASP should have control over which root CA it=20 > trusts; this may=20 > > > imply creating a certificate trust list to include the=20 > peer's CA for=20 > > > each authorized domain. > > > This requirement allows for the initiating side to verify=20 > that the=20 > > > server cert is rooted in a well-known CA. > > > - Derivative requirement: > > > SIP servers SHOULD allow the configuration of certificate trust=20 > > > lists in order to allow a VSP/ASP to control which peer's CAs are=20 > > > trusted for TLS connections. > > > > > > --- 2. Peers SHOULD indicate whether their domain=20 > policies require=20 > > > proxy servers to inspect and verify the identity provided in SIP=20 > > > requests per RFC 4474. > > > > > > --- 3. When TLS is used between peers, SIP servers=20 > involved in the=20 > > > session establishment MUST have valid X.509 certificates=20 > and MUST be=20 > > > able to receive a TLS connection. > > > > > > Motivations: > > > If TLS is supported for session peering, SIP servers must=20 > have valid > > > X.509 certificates and they should listen on the SIP TLS port for=20 > > > incoming connections. > > > > > > --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed=20 > > > upon as part of session peering policies: > > > + The version of TLS (TLSv1, TLSv1.1) > > > + The SIP TLS port (default 5061) > > > + The server-side session timeout (default 300 seconds) > > > + The list of supported or recommended ciphersuite > > > + list of trusted root CAs > > > > > > > > > --- 5. SIP entities involved in the session establishment=20 > exchanges=20 > > > MUST follow the following requirements: > > > + check certs : > > > "the client certificate MUST contain a DNS or URI choice=20 > type in the=20 > > > subjectAltName which corresponds to the domain asserted=20 > in the host=20 > > > production of the From header URI." > > > (from Rohan's I-D) > > > + check identity in cert per section 4 of=20 > > >=20 > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? > > > + add details and pointers to the use of RFC > > > 4474 inter-domain. > > > > > > =3D=3D> open questions: > > > These are best current practices that should be followed. > > > We can either reference the work-in-progress IDs or paste some of=20 > > > the most relevant text and then refer to the I-Ds. > > > > > > REFERENCEs: > > > - Rohan's direct peering draft > > > http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct > > > -peering-0 > > > 0.txt, > > > - Vijay's > > >=20 > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: > > > > > > --- 6. A session peering policy SHOULD include details on SIP=20 > > > session establishment over TLS (see above, to be briefly=20 > > > summarized1111). > > > > > > > > > --- Open questions: > > > - should we re-iterate the requirement of RFC 4474 that=20 > self-signed=20 > > > certs should not be trusted unless prior key exchange has=20 > occurred? > > > Given the goals of speermint, should there be more=20 > guidance on the=20 > > > use of self-signed certs? > > > - should there be a minimum set of ciphersuites to recommend or=20 > > > leave it open? > > > > > > > > > Is this on the right track and what folks had in mind? > > > > > > Comments and input are appreciated. > > > Jean-Francois. > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 13:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabQE-00056Q-GC; Thu, 19 Oct 2006 13:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabQC-00053o-G5 for speermint@ietf.org; Thu, 19 Oct 2006 13:11:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GabGD-0002za-Dv for speermint@ietf.org; Thu, 19 Oct 2006 13:00:59 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 10:00:49 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JH0mRQ027317; Thu, 19 Oct 2006 10:00:48 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9JH0UbV023040; Thu, 19 Oct 2006 10:00:43 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 13:00:26 -0400 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] Basic Peering Requirements Date: Thu, 19 Oct 2006 13:00:24 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211FAAE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 19 Oct 2006 17:00:26.0058 (UTC) FILETIME=[12B18AA0:01C6F3A0] DKIM-Signature: a=rsa-sha1; q=dns; l=14410; t=1161277248; x=1162141248; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=jUqiYyaeS1pWmzlPFs6ZcCWQS46ZarQ6W37jTDCTGZIMT3IGZk2A4d7Dpt6C/oBEUfmXHJU9 2JheL0w9ZQjeJ5b7M8bKrx04HkE3Gj71cNpNs/mXEnz5+LCKWq9fJkvI; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org "The point is that for each route, what I want is the complete set of VSPs that route can get me to." So, you have entries for all VSPs on Earth? When 1 Federation =3D N VSPs, where N can be many orders of magnitude above 1, I would contend that: "The point is that for each route, what I want is the complete set of Federations that route can get me to." would scale better. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, October 19, 2006 12:29 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar=20 > Lendl'; 'Daryl Malas' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Which scaling limits are you working from, PSTN or the Internet? =20 >=20 > Reachability to thousands (or tens of thousands, or a couple hundred > thousand) VSPs is what I want. >=20 > I want the "best" route to a VSP (which I may only know by a=20 > TN in a registry). A federation is one potential route. >=20 > Scaling to tens or hundreds of thousands of routes is usually=20 > considered to be quite reasonable, and even millions is quite=20 > reasonable for L5 routing since we don't need to keep the=20 > routes in memory. Certainly a federation returning VSP=20 > reachability to that many VSPs is easy. >=20 > If all I have is one transit peer, and no federations, then I=20 > can launch my call and if it doesn't work, all I can do is=20 > send it via the PSTN. Same if I am only a member of one federation. >=20 > As soon as I have two routes, I need to know where to send it=20 > for the next hop. I have the destination VSP, I choose a=20 > route: VSP in, route out. I check my routes for=20 > reachability. If there is only one route, I send out the=20 > call that way. If I have more than one route, then I need a=20 > cost metric, and we don't have to go there right now. The=20 > point is that for each route, what I want is the complete set=20 > of VSPs that route can get me to. >=20 > Seems like getting that information directly is the simplest=20 > way to go. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, October 19, 2006 10:46 AM > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Brian, > >=20 > > Which would you rather maintain and advertise: > >=20 > > reachability to a hundred federations, or reachability to=20 > millions of=20 > > VSPs? > >=20 > > What you suggest doesn't scale. > >=20 > > The idea here was that once you know that a VSP belongs to a=20 > > federation (via ENUM and DNS), you are now looking for information=20 > > that your Transit VSP supports that federation and to which=20 > signaling=20 > > address of the Transit VSP to send the next signaling message. > >=20 > > Isn't that simpler? Don't know why you want to make it harder. > >=20 > > There can be an address from which a federation membership can be=20 > > fetched, but I would rather be pointed to the answer, than scanning=20 > > through lengthy membership lists to discover relationships.=20 > I think=20 > > the main value is in having a federation point to the Transit=20 > > providers serving a federation only. That should be a much smaller=20 > > list. But, that step would not be needed by the=20 > originating VSP if it=20 > > already knows what federations its own Transit VSP serves and the=20 > > terminating federation is on that list. > >=20 > > In summary, routing towards federations as an aggregation mechanism=20 > > rather than individual VSPs scales better. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, October 18, 2006 1:55 PM > > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl';=20 > > > 'Daryl Malas' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > To me, this is off the deep end. > > > > > > I think we don't care what federations a destination=20 > network belongs=20 > > > to. > > > Sorry Otmar. > > > > > > I think a federation may advertise what peers it can get=20 > you access=20 > > > to. > > > That may include transit peers, and those transit peers=20 > may get you=20 > > > to other peers through other federations. The federation=20 > advertises=20 > > > the aggregate of what networks it can reach, direct or indirect. > > > > > > I don't want a peer to have to keep relationships (how it gets to=20 > > > Fed X) straight, I want it to be able to ask the federations or=20 > > > transit networks it deals with if they have a route to the=20 > > > destination network. > > > > > > If you take this view, then you always get what you want to know,=20 > > > regardless of how convoluted the routes are, by simple queries to=20 > > > each federation/transit network. If you try to trace routes in=20 > > > advance (let's see, I want to get to network A, he is=20 > part of Fed 1=20 > > > and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of=20 > fed 2 and=20 > > > he is also part of Fed 3, and I'm in fed 3, so I can send it to Z=20 > > > via fed 3, and he can send to fed 2 to get to A). > > > > > > Much better if Fed 3 advertises it can reach A. > > > > > > This is how route advertisements work, and I think we=20 > should assume=20 > > > that's the best way until proven otherwise. > > > > > > So let's not talk about Federations a network belongs to, and=20 > > > specifically, don't talk about routes TO A FEDERATION, but rather=20 > > > routes to a destination network FROM a federation. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > Sent: Wednesday, October 18, 2006 1:01 PM > > > > To: Stastny Richard; Otmar Lendl; Daryl Malas > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > I had taken this to mean that the Transit VSP would be > > > advertising to > > > > originating VSPs reachability to various federations of=20 > the form: > > > > > > > > (to get to) (contact) > > > > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an=20 > arbitrary > > > > string) > > > > Federation Y --> Fed-Y@VSP.com > > > > Federation Z --> Fed-Z@VSP.com > > > > > > > > or: > > > > > > > > Federation X --> Fed-Any@VSP.com > > > > Federation Y --> Fed-Any@VSP.com > > > > Federation Z --> Fed-Any@VSP.com > > > > > > > > If not, count me as misunderstanding too. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > Sent: Wednesday, October 18, 2006 10:05 AM > > > > > To: Otmar Lendl; Daryl Malas > > > > > Cc: speermint@ietf.org > > > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > >> If a peer is providing connectivity to multiple > > > federations, it > > > > > >> should disclose AoRs providing indirect peering > > > relationships to > > > > > >> servicing peers or federations. > > > > > > > > > > >Sorry, I don't understand that sentence. > > > > > > > > > > >Do you mean that when a VSP adds an AoR to a federations=20 > > > > > >routing database, then it needs to discluse whether=20 > that is a=20 > > > > > >direct > > > > > customer > > > > > >or just a transit offer? > > > > > > > > > > Sorry, but I do not understand the whole issue: > > > > > > > > > > An AoR is a a special type of SIP URI (a Public User > > > > > Identity) defining the destination network (administrative=20 > > > > > domain) > > > > > > > > > > How can it be disclosed or not, especially for a=20 > transit network? > > > > > It is always public. > > > > > > > > > > Richard > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > > > > Gesendet: Mi 18.10.2006 15:54 > > > > > An: Daryl Malas > > > > > Cc: speermint@ietf.org > > > > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > > > > > > > > > > > Daryl, > > > > > > > > > > > peering requirements from one operators perspective. I can > > > > > post these > > > > > > to the list if you would like. Here is a list of peering > > > > > requirements > > > > > > (this is certainly not exhaustive, but is a platform): > > > > > > > > > > Here are my comments to that list: > > > > > > > > > > General: this seems to be a list providing details on what=20 > > > > > federations have to do (or agree on). > > > > > > > > > > > Transport (Layer 1 3): > > > > > > > > > > > > Peering must utilize IP as the primary mechanism=20 > for peering. > > > > > > > > > > > > A federation must agree upon a common mechanism for IP > > > transport > > > > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > > > > > Fine. > > > > > > > > > > > Billing: > > > > > > > > > > Good. > > > > > > > > > > > Policy: > > > > > > > > > > > > > > > > Could you be a bit more specific on what you mean by "policy" > > > > > in this context? > > > > > > > > > > > Policies may be implemented locally to the peer or via a > > > > > centralized > > > > > > mechanism within the federation. > > > > > > > > > > > > Local policies should be disclosed when creating direct=20 > > > > > > peering relationships with the applicable direct peer. > > > > > > > > > > > > Local policies may supersede centralized federation=20 > policies. > > > > > > > > > > > > (Net of this...some peering relationships will be 1:1, > > > so policies > > > > > > will likely be local only. Some peering relationships will > > > > > be 1:N, so > > > > > > policies will likely be implemented within DNS or some > > > centralized > > > > > > mechanism.) > > > > > > > > > > Could you provide some examples of such policies? > > > > > > > > > > > Membership: > > > > > > > > > > > > A peer may be a member of multiple federations > > > > > > > > > > > > A peer must maintain compliancy for policies as defined by=20 > > > > > > each federation the peer is a member of. > > > > > > > > > > > > If a peer is providing connectivity to multiple > > > > > federations, it should > > > > > > disclose AoRs providing indirect peering relationships to=20 > > > > > > servicing peers or federations. > > > > > > > > > > Sorry, I don't understand that sentence. > > > > > > > > > > Do you mean that when a VSP adds an AoR to a=20 > federations routing=20 > > > > > database, then it needs to discluse whether that is a direct=20 > > > > > customer or just a transit offer? > > > > > > > > > > > Peers providing indirect peering must enforce federation > > > > > policies on > > > > > > behalf of the destination federation. > > > > > > > > > > > > A peer providing indirect peering may enforce undisclosed > > > > > policies for > > > > > > processing session requests between federations. > > > > > > > > > > > > (Net of this...some peers will only desire to be part > > > of a single > > > > > > federation, where wholesale carriers will likely be=20 > members of=20 > > > > > > multiple > > > > > > federations.) > > > > > > > > > > ok. > > > > > > > > > > > Media: > > > > > > > > > > ok. > > > > > > > > > > > Routing: > > > > > > > > > > > > A peer must utilize the centralized federation routing > > > > > mechanism if it > > > > > > is available. > > > > > > > > > > ok. > > > > > > > > > > > A peer allowing another peer within a federation to provide > > > > > indirect > > > > > > peering on their behalf must select only one indirect > > > peer to host > > > > > > their AoRs. > > > > > > > > > > Do you mean indirect peering *within* a federation? Let > > > me name the > > > > > parties here: > > > > > > > > > > > A peer (X) allowing another peer (Y) within a > > > federation (F1) to > > > > > > provide indirect peering on their behalf must select only > > > > > one indirect > > > > > > peer to host their AoRs. > > > > > > > > > > Is the idea here that all members of F1 who want to place > > > calls to X > > > > > need to route the calls via Y? In that case, I would not > > > consider X > > > > > to be a member of F1. Instead, Y is providing transit > > > services for > > > > > X. > > > > > > > > > > Or you want to restrict X to be able to only select one > > > other VSP to > > > > > host it's AoRs in total? > > > > > > > > > > > A peer must not copy routing information from or make > > > > > assumed routing > > > > > > choices on behalf of the centralized routing mechanism for > > > > > use locally > > > > > > unless it takes place through standard caching methods. > > > > > > > > > > > > A common API must be utilized and available for subscriber > > > > > and route > > > > > > provisioning on any centralized federation location=20 > function. > > > > > > > > > > > > Subscriber and routing information must be dynamically > > > > > updated as soon > > > > > > as applicable for accurate routing within the federation. > > > > > > > > > > ok > > > > > > > > > > > Performance: > > > > > > > > > > > > Performance metrics must be shared between peers as=20 > they apply=20 > > > > > > directly to peering signaling and media on a consistent > > > > > basis within > > > > > > the federation. > > > > > > > > > > ok > > > > > > > > > > /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 > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 14:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gacbk-0004hJ-22; Thu, 19 Oct 2006 14:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gacbj-0004h8-4Z for speermint@ietf.org; Thu, 19 Oct 2006 14:27:07 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gacbi-0003PJ-CB for speermint@ietf.org; Thu, 19 Oct 2006 14:27:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GacbK-0000tO-J6; Thu, 19 Oct 2006 13:26:44 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Otmar Lendl'" , "'Daryl Malas'" Subject: RE: [Speermint] Basic Peering Requirements Date: Thu, 19 Oct 2006 14:26:45 -0400 Message-ID: <048f01c6f3ac$24338b00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIAACD+nQ In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30211FAAE@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I'm not advocating a particular solution, but, in general, I do want the ability to determine if a particular route (=federation or transit network I directly peer to) can get my call terminated correctly. It's quite acceptable, and maybe optimal to just give me the info (which might be list of VSPs, but see below). It may be acceptable to just let me query for that (can I reach this VSP from you?). What I don't need is the set of federations a VSP belongs to. I don't care a whit what federations they belong to. I only want to know which of my routes can get me to them. The number of VSPs is a small number in today's technology. It's entirely feasible to have a single database with every TN in the world. That is a big database, but not beyond current single database technology. The number of VSPs is small in database terms. This is a database problem. Let's open this up a little more. If some kind of public enum tree is built, whether it's user enum or infrastructure enum in the public DNS, then we can do real two step lookups of TN to VSP and then do some kind VSP to something lookup. Right now, I don't see that happening much. What will happen is private databases (ENUM or otherwise). We can argue if the federation runs the database. I think it will, one way or another. We have some problems. One is how indirect peering TNs are handled. Either they are imported into the database, or the query is proxied to another database. Either way, you launch a query and you get back either a URI within the federation or you get an error (not found). If you are a member of more than one federation, you may launch more than one such query, and you can get back zero, one or more than one URIs (from each query and the aggregate of all the queries). This means you end up doing TN to URI in one step. We then have to decide if you get the ingress point directly, or there is another query for that; I suspect you get the ingress point in one step. If you have one answer, that's where you send the call. If you have zero answers, PSTN gateway gets the caLL. If you have more than one answer, you are into some kind of cost metric. The point is that you get an answer that is the route TO the VSP, not the federation the VSP belongs to, OR EVEN THE IDENTITY OF THE VSP. You query by TN. You may not even be given the identity of the destination VSP. Your query by TN only yields next hop. The only scenario where you know the VSP before you know the route is where there is a registry independent of the federation. That just isn't really happening except in a very few isolated places. I suppose we need to give them some kind of solution, but I don't care much about it, because I think it's not going to be common. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, October 19, 2006 1:00 PM > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > "The point is that for each route, what I want is the complete set of > VSPs that route can get me to." > > So, you have entries for all VSPs on Earth? > > When 1 Federation = N VSPs, where N can be many orders of magnitude > above 1, I would contend that: > > "The point is that for each route, what I want is the complete set of > Federations that route can get me to." > > would scale better. > > Mike > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, October 19, 2006 12:29 PM > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar > > Lendl'; 'Daryl Malas' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > Which scaling limits are you working from, PSTN or the Internet? > > > > Reachability to thousands (or tens of thousands, or a couple hundred > > thousand) VSPs is what I want. > > > > I want the "best" route to a VSP (which I may only know by a > > TN in a registry). A federation is one potential route. > > > > Scaling to tens or hundreds of thousands of routes is usually > > considered to be quite reasonable, and even millions is quite > > reasonable for L5 routing since we don't need to keep the > > routes in memory. Certainly a federation returning VSP > > reachability to that many VSPs is easy. > > > > If all I have is one transit peer, and no federations, then I > > can launch my call and if it doesn't work, all I can do is > > send it via the PSTN. Same if I am only a member of one federation. > > > > As soon as I have two routes, I need to know where to send it > > for the next hop. I have the destination VSP, I choose a > > route: VSP in, route out. I check my routes for > > reachability. If there is only one route, I send out the > > call that way. If I have more than one route, then I need a > > cost metric, and we don't have to go there right now. The > > point is that for each route, what I want is the complete set > > of VSPs that route can get me to. > > > > Seems like getting that information directly is the simplest > > way to go. > > > > Brian > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Thursday, October 19, 2006 10:46 AM > > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Brian, > > > > > > Which would you rather maintain and advertise: > > > > > > reachability to a hundred federations, or reachability to > > millions of > > > VSPs? > > > > > > What you suggest doesn't scale. > > > > > > The idea here was that once you know that a VSP belongs to a > > > federation (via ENUM and DNS), you are now looking for information > > > that your Transit VSP supports that federation and to which > > signaling > > > address of the Transit VSP to send the next signaling message. > > > > > > Isn't that simpler? Don't know why you want to make it harder. > > > > > > There can be an address from which a federation membership can be > > > fetched, but I would rather be pointed to the answer, than scanning > > > through lengthy membership lists to discover relationships. > > I think > > > the main value is in having a federation point to the Transit > > > providers serving a federation only. That should be a much smaller > > > list. But, that step would not be needed by the > > originating VSP if it > > > already knows what federations its own Transit VSP serves and the > > > terminating federation is on that list. > > > > > > In summary, routing towards federations as an aggregation mechanism > > > rather than individual VSPs scales better. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, October 18, 2006 1:55 PM > > > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl'; > > > > 'Daryl Malas' > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > To me, this is off the deep end. > > > > > > > > I think we don't care what federations a destination > > network belongs > > > > to. > > > > Sorry Otmar. > > > > > > > > I think a federation may advertise what peers it can get > > you access > > > > to. > > > > That may include transit peers, and those transit peers > > may get you > > > > to other peers through other federations. The federation > > advertises > > > > the aggregate of what networks it can reach, direct or indirect. > > > > > > > > I don't want a peer to have to keep relationships (how it gets to > > > > Fed X) straight, I want it to be able to ask the federations or > > > > transit networks it deals with if they have a route to the > > > > destination network. > > > > > > > > If you take this view, then you always get what you want to know, > > > > regardless of how convoluted the routes are, by simple queries to > > > > each federation/transit network. If you try to trace routes in > > > > advance (let's see, I want to get to network A, he is > > part of Fed 1 > > > > and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of > > fed 2 and > > > > he is also part of Fed 3, and I'm in fed 3, so I can send it to Z > > > > via fed 3, and he can send to fed 2 to get to A). > > > > > > > > Much better if Fed 3 advertises it can reach A. > > > > > > > > This is how route advertisements work, and I think we > > should assume > > > > that's the best way until proven otherwise. > > > > > > > > So let's not talk about Federations a network belongs to, and > > > > specifically, don't talk about routes TO A FEDERATION, but rather > > > > routes to a destination network FROM a federation. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > Sent: Wednesday, October 18, 2006 1:01 PM > > > > > To: Stastny Richard; Otmar Lendl; Daryl Malas > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > I had taken this to mean that the Transit VSP would be > > > > advertising to > > > > > originating VSPs reachability to various federations of > > the form: > > > > > > > > > > (to get to) (contact) > > > > > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an > > arbitrary > > > > > string) > > > > > Federation Y --> Fed-Y@VSP.com > > > > > Federation Z --> Fed-Z@VSP.com > > > > > > > > > > or: > > > > > > > > > > Federation X --> Fed-Any@VSP.com > > > > > Federation Y --> Fed-Any@VSP.com > > > > > Federation Z --> Fed-Any@VSP.com > > > > > > > > > > If not, count me as misunderstanding too. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > Sent: Wednesday, October 18, 2006 10:05 AM > > > > > > To: Otmar Lendl; Daryl Malas > > > > > > Cc: speermint@ietf.org > > > > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > >> If a peer is providing connectivity to multiple > > > > federations, it > > > > > > >> should disclose AoRs providing indirect peering > > > > relationships to > > > > > > >> servicing peers or federations. > > > > > > > > > > > > >Sorry, I don't understand that sentence. > > > > > > > > > > > > >Do you mean that when a VSP adds an AoR to a federations > > > > > > >routing database, then it needs to discluse whether > > that is a > > > > > > >direct > > > > > > customer > > > > > > >or just a transit offer? > > > > > > > > > > > > Sorry, but I do not understand the whole issue: > > > > > > > > > > > > An AoR is a a special type of SIP URI (a Public User > > > > > > Identity) defining the destination network (administrative > > > > > > domain) > > > > > > > > > > > > How can it be disclosed or not, especially for a > > transit network? > > > > > > It is always public. > > > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > > > > > Gesendet: Mi 18.10.2006 15:54 > > > > > > An: Daryl Malas > > > > > > Cc: speermint@ietf.org > > > > > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Daryl, > > > > > > > > > > > > > peering requirements from one operators perspective. I can > > > > > > post these > > > > > > > to the list if you would like. Here is a list of peering > > > > > > requirements > > > > > > > (this is certainly not exhaustive, but is a platform): > > > > > > > > > > > > Here are my comments to that list: > > > > > > > > > > > > General: this seems to be a list providing details on what > > > > > > federations have to do (or agree on). > > > > > > > > > > > > > Transport (Layer 1 3): > > > > > > > > > > > > > > Peering must utilize IP as the primary mechanism > > for peering. > > > > > > > > > > > > > > A federation must agree upon a common mechanism for IP > > > > transport > > > > > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > > > > > > > Fine. > > > > > > > > > > > > > Billing: > > > > > > > > > > > > Good. > > > > > > > > > > > > > Policy: > > > > > > > > > > > > > > > > > > > Could you be a bit more specific on what you mean by "policy" > > > > > > in this context? > > > > > > > > > > > > > Policies may be implemented locally to the peer or via a > > > > > > centralized > > > > > > > mechanism within the federation. > > > > > > > > > > > > > > Local policies should be disclosed when creating direct > > > > > > > peering relationships with the applicable direct peer. > > > > > > > > > > > > > > Local policies may supersede centralized federation > > policies. > > > > > > > > > > > > > > (Net of this...some peering relationships will be 1:1, > > > > so policies > > > > > > > will likely be local only. Some peering relationships will > > > > > > be 1:N, so > > > > > > > policies will likely be implemented within DNS or some > > > > centralized > > > > > > > mechanism.) > > > > > > > > > > > > Could you provide some examples of such policies? > > > > > > > > > > > > > Membership: > > > > > > > > > > > > > > A peer may be a member of multiple federations > > > > > > > > > > > > > > A peer must maintain compliancy for policies as defined by > > > > > > > each federation the peer is a member of. > > > > > > > > > > > > > > If a peer is providing connectivity to multiple > > > > > > federations, it should > > > > > > > disclose AoRs providing indirect peering relationships to > > > > > > > servicing peers or federations. > > > > > > > > > > > > Sorry, I don't understand that sentence. > > > > > > > > > > > > Do you mean that when a VSP adds an AoR to a > > federations routing > > > > > > database, then it needs to discluse whether that is a direct > > > > > > customer or just a transit offer? > > > > > > > > > > > > > Peers providing indirect peering must enforce federation > > > > > > policies on > > > > > > > behalf of the destination federation. > > > > > > > > > > > > > > A peer providing indirect peering may enforce undisclosed > > > > > > policies for > > > > > > > processing session requests between federations. > > > > > > > > > > > > > > (Net of this...some peers will only desire to be part > > > > of a single > > > > > > > federation, where wholesale carriers will likely be > > members of > > > > > > > multiple > > > > > > > federations.) > > > > > > > > > > > > ok. > > > > > > > > > > > > > Media: > > > > > > > > > > > > ok. > > > > > > > > > > > > > Routing: > > > > > > > > > > > > > > A peer must utilize the centralized federation routing > > > > > > mechanism if it > > > > > > > is available. > > > > > > > > > > > > ok. > > > > > > > > > > > > > A peer allowing another peer within a federation to provide > > > > > > indirect > > > > > > > peering on their behalf must select only one indirect > > > > peer to host > > > > > > > their AoRs. > > > > > > > > > > > > Do you mean indirect peering *within* a federation? Let > > > > me name the > > > > > > parties here: > > > > > > > > > > > > > A peer (X) allowing another peer (Y) within a > > > > federation (F1) to > > > > > > > provide indirect peering on their behalf must select only > > > > > > one indirect > > > > > > > peer to host their AoRs. > > > > > > > > > > > > Is the idea here that all members of F1 who want to place > > > > calls to X > > > > > > need to route the calls via Y? In that case, I would not > > > > consider X > > > > > > to be a member of F1. Instead, Y is providing transit > > > > services for > > > > > > X. > > > > > > > > > > > > Or you want to restrict X to be able to only select one > > > > other VSP to > > > > > > host it's AoRs in total? > > > > > > > > > > > > > A peer must not copy routing information from or make > > > > > > assumed routing > > > > > > > choices on behalf of the centralized routing mechanism for > > > > > > use locally > > > > > > > unless it takes place through standard caching methods. > > > > > > > > > > > > > > A common API must be utilized and available for subscriber > > > > > > and route > > > > > > > provisioning on any centralized federation location > > function. > > > > > > > > > > > > > > Subscriber and routing information must be dynamically > > > > > > updated as soon > > > > > > > as applicable for accurate routing within the federation. > > > > > > > > > > > > ok > > > > > > > > > > > > > Performance: > > > > > > > > > > > > > > Performance metrics must be shared between peers as > > they apply > > > > > > > directly to peering signaling and media on a consistent > > > > > > basis within > > > > > > > the federation. > > > > > > > > > > > > ok > > > > > > > > > > > > /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 From speermint-bounces@ietf.org Thu Oct 19 15:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadSC-0001K2-US; Thu, 19 Oct 2006 15:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadSB-0001Dc-PH for speermint@ietf.org; Thu, 19 Oct 2006 15:21:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadS9-0003S7-Md for speermint@ietf.org; Thu, 19 Oct 2006 15:21:19 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 12:21:15 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJLFdw016955; Thu, 19 Oct 2006 12:21:15 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9JJL1OV013645; Thu, 19 Oct 2006 12:21:02 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:21:01 -0400 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] Basic Peering Requirements Date: Thu, 19 Oct 2006 15:20:58 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211FB78@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIAACD+nQAAFdrnA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 19 Oct 2006 19:21:01.0319 (UTC) FILETIME=[B6803970:01C6F3B3] DKIM-Signature: a=rsa-sha1; q=dns; l=22764; t=1161285675; x=1162149675; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=gdhRtkKoi4lu3INlg6jrRJ08cxBteKc8V1VAZAkhhU8PXnuoNqJYezNygCX9xgiIuFMoE2X9 z/rYwN98iWBRQqHzATP2Rx+YJZbvJYGXr6xShIr6dwkdaEDJxZj/Dkon; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Inline.=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, October 19, 2006 2:27 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar=20 > Lendl'; 'Daryl Malas' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > I'm not advocating a particular solution, but, in general, I=20 > do want the ability to determine if a particular route=20 > (=3Dfederation or transit network I directly peer to) can get=20 > my call terminated correctly. =20 This seems like chicken and egg problem. Were did your route come from? I think we both want to know that sending the next signaling message will result in a call setup. > It's quite acceptable, and=20 > maybe optimal to just give me the info (which might be list=20 > of VSPs, but see below). It may be acceptable to just let me=20 > query for that (can I reach this VSP from you?). Not sure what you mean by info. What type of query are we talking about? What does the query get you? Are you talking a trial an error approach? > What I don't need is the set of federations a VSP belongs to.=20 > I don't care a whit what federations they belong to. I only=20 > want to know which of my routes can get me to them. The federation is only a mechanism for finding a route. You are positing the existence of a route in advance. In other words, you seem to be assuming a solution and then some test to verify that it works. > The number of VSPs is a small number in today's technology. What do you mean by VSP? I am assuming any organization that operates a voice service and serves endpoints, which would include IP-PBX of enterprises. If you aren't counting them, then you have underestimated. > It's entirely feasible to have a single database with every=20 > TN in the world. > That is a big database, but not beyond current single=20 > database technology. > The number of VSPs is small in database terms. This is a=20 > database problem.=20 >=20 > Let's open this up a little more. >=20 > If some kind of public enum tree is built, whether it's user=20 > enum or infrastructure enum in the public DNS, then we can do=20 > real two step lookups of TN to VSP and then do some kind VSP=20 > to something lookup. Right now, I don't see that happening much. Just having the VSP is unsufficient; that doesn't gurantee they will accept your call. > What will happen is private databases (ENUM or otherwise). =20 > We can argue if the federation runs the database. I think it=20 > will, one way or another. We have some problems. >=20 > One is how indirect peering TNs are handled. Either they are=20 > imported into the database, or the query is proxied to=20 > another database. Either way, you launch a query and you get=20 > back either a URI within the federation or you get an error=20 > (not found). If you are a member of more than one=20 > federation, you may launch more than one such query, and you=20 > can get back zero, one or more than one URIs (from each query=20 > and the aggregate of all the queries). If the caller must go through a Transit VSP which runs its own federation, then the TN lookup can point to the Transit VSP directly, as well as identify the federation(s). The access to the private database that gets from the Transit VSP to the terminating VSP can be private. The problem has now morphed into how does the caller get to that Transit VSP? Does the calling VSP have a peering relationship directly, or must it go indirectly through yet another Transit VSP? Don't get hung up on the term federation, it is just a generalization of the bilateral peering arrangement. That is, bilateral peering is just the smallest federation possible; membership=3D2. > This means you end up doing TN to URI in one step. We then=20 > have to decide if you get the ingress point directly, or=20 > there is another query for that; I suspect you get the=20 > ingress point in one step. No disagreement here. Saying that I can go from the originating VSP to the terminating VSP directly, means that there is a direct peering arrangement. Saying that they both belong to the same federation is saying exactly the same thing. The more interesting question is determining when you don't have a direct peering relationship (i.e. no common federation) what to do. > If you have one answer, that's where you send the call. If=20 > you have zero answers, PSTN gateway gets the caLL. =20 No, no, no! The goal of this exercise is to avoid the PSTN. The only reason the PSTN should be used is when the TN is terminated to a TDM switch and not reachable by IP. You are identifying a gap in your approach, if a TN is a SIP phone terminated on a VSP and you end up on the PSTN. > If you=20 > have more than one answer, you are into some kind of cost metric. >=20 > The point is that you get an answer that is the route TO the=20 > VSP, not the federation the VSP belongs to, OR EVEN THE=20 > IDENTITY OF THE VSP. =20 What is the means by which you identify the "route"? > You query by TN. You may not even be=20 > given the identity of the destination VSP. Your query by TN=20 > only yields next hop. The next hop could also be just a default value and defer the problem to the originating side Transit VSP. The Transit VSP routing table could also list thousands of VSPs associated with a route. But, if those groups of thousands were associated with respective federations, then your table could be much smaller if each thousand were replaced with a single federation:route entry. Could the INVITE then be: SIP: Target URI Route:Transit VSP Route:Federation URN? > The only scenario where you know the VSP before you know the=20 > route is where there is a registry independent of the=20 > federation. =20 I would call that registry the DNS. I think you are putting the cart before the horse. Find the destination peer, then the route to get there. Mike > That just isn't really happening except in a=20 > very few isolated places. I suppose we need to give them=20 > some kind of solution, but I don't care much about it,=20 > because I think it's not going to be common. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, October 19, 2006 1:00 PM > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > "The point is that for each route, what I want is the=20 > complete set of=20 > > VSPs that route can get me to." > >=20 > > So, you have entries for all VSPs on Earth? > >=20 > > When 1 Federation =3D N VSPs, where N can be many orders of = magnitude=20 > > above 1, I would contend that: > >=20 > > "The point is that for each route, what I want is the=20 > complete set of=20 > > Federations that route can get me to." > >=20 > > would scale better. > >=20 > > Mike > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, October 19, 2006 12:29 PM > > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl';=20 > > > 'Daryl Malas' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Which scaling limits are you working from, PSTN or the Internet? > > > > > > Reachability to thousands (or tens of thousands, or a=20 > couple hundred > > > thousand) VSPs is what I want. > > > > > > I want the "best" route to a VSP (which I may only know=20 > by a TN in a=20 > > > registry). A federation is one potential route. > > > > > > Scaling to tens or hundreds of thousands of routes is usually=20 > > > considered to be quite reasonable, and even millions is quite=20 > > > reasonable for L5 routing since we don't need to keep the=20 > routes in=20 > > > memory. Certainly a federation returning VSP=20 > reachability to that=20 > > > many VSPs is easy. > > > > > > If all I have is one transit peer, and no federations, then I can=20 > > > launch my call and if it doesn't work, all I can do is=20 > send it via=20 > > > the PSTN. Same if I am only a member of one federation. > > > > > > As soon as I have two routes, I need to know where to send it for=20 > > > the next hop. I have the destination VSP, I choose a > > > route: VSP in, route out. I check my routes for=20 > reachability. If=20 > > > there is only one route, I send out the call that way. If I have=20 > > > more than one route, then I need a cost metric, and we=20 > don't have to=20 > > > go there right now. The point is that for each route,=20 > what I want=20 > > > is the complete set of VSPs that route can get me to. > > > > > > Seems like getting that information directly is the=20 > simplest way to=20 > > > go. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > Sent: Thursday, October 19, 2006 10:46 AM > > > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > > > > Cc: speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > Brian, > > > > > > > > Which would you rather maintain and advertise: > > > > > > > > reachability to a hundred federations, or reachability to > > > millions of > > > > VSPs? > > > > > > > > What you suggest doesn't scale. > > > > > > > > The idea here was that once you know that a VSP belongs to a=20 > > > > federation (via ENUM and DNS), you are now looking for=20 > information=20 > > > > that your Transit VSP supports that federation and to which > > > signaling > > > > address of the Transit VSP to send the next signaling message. > > > > > > > > Isn't that simpler? Don't know why you want to make it harder. > > > > > > > > There can be an address from which a federation=20 > membership can be=20 > > > > fetched, but I would rather be pointed to the answer, than=20 > > > > scanning through lengthy membership lists to discover=20 > relationships. > > > I think > > > > the main value is in having a federation point to the Transit=20 > > > > providers serving a federation only. That should be a much=20 > > > > smaller list. But, that step would not be needed by the > > > originating VSP if it > > > > already knows what federations its own Transit VSP=20 > serves and the=20 > > > > terminating federation is on that list. > > > > > > > > In summary, routing towards federations as an aggregation=20 > > > > mechanism rather than individual VSPs scales better. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Wednesday, October 18, 2006 1:55 PM > > > > > To: Michael Hammer (mhammer); 'Stastny Richard';=20 > 'Otmar Lendl';=20 > > > > > 'Daryl Malas' > > > > > Cc: speermint@ietf.org > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > To me, this is off the deep end. > > > > > > > > > > I think we don't care what federations a destination > > > network belongs > > > > > to. > > > > > Sorry Otmar. > > > > > > > > > > I think a federation may advertise what peers it can get > > > you access > > > > > to. > > > > > That may include transit peers, and those transit peers > > > may get you > > > > > to other peers through other federations. The federation > > > advertises > > > > > the aggregate of what networks it can reach, direct=20 > or indirect. > > > > > > > > > > I don't want a peer to have to keep relationships=20 > (how it gets=20 > > > > > to Fed X) straight, I want it to be able to ask the=20 > federations=20 > > > > > or transit networks it deals with if they have a route to the=20 > > > > > destination network. > > > > > > > > > > If you take this view, then you always get what you want to=20 > > > > > know, regardless of how convoluted the routes are, by simple=20 > > > > > queries to each federation/transit network. If you=20 > try to trace=20 > > > > > routes in advance (let's see, I want to get to=20 > network A, he is > > > part of Fed 1 > > > > > and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of > > > fed 2 and > > > > > he is also part of Fed 3, and I'm in fed 3, so I can=20 > send it to=20 > > > > > Z via fed 3, and he can send to fed 2 to get to A). > > > > > > > > > > Much better if Fed 3 advertises it can reach A. > > > > > > > > > > This is how route advertisements work, and I think we > > > should assume > > > > > that's the best way until proven otherwise. > > > > > > > > > > So let's not talk about Federations a network belongs to, and=20 > > > > > specifically, don't talk about routes TO A FEDERATION, but=20 > > > > > rather routes to a destination network FROM a federation. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > > Sent: Wednesday, October 18, 2006 1:01 PM > > > > > > To: Stastny Richard; Otmar Lendl; Daryl Malas > > > > > > Cc: speermint@ietf.org > > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > > I had taken this to mean that the Transit VSP would be > > > > > advertising to > > > > > > originating VSPs reachability to various federations of > > > the form: > > > > > > > > > > > > (to get to) (contact) > > > > > > Federation X --> Fed-X@VSP.com (Fed-X etc. could be an > > > arbitrary > > > > > > string) > > > > > > Federation Y --> Fed-Y@VSP.com Federation Z -->=20 > Fed-Z@VSP.com > > > > > > > > > > > > or: > > > > > > > > > > > > Federation X --> Fed-Any@VSP.com Federation Y -->=20 > > > > > > Fed-Any@VSP.com Federation Z --> Fed-Any@VSP.com > > > > > > > > > > > > If not, count me as misunderstanding too. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > > > > Sent: Wednesday, October 18, 2006 10:05 AM > > > > > > > To: Otmar Lendl; Daryl Malas > > > > > > > Cc: speermint@ietf.org > > > > > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > >> If a peer is providing connectivity to multiple > > > > > federations, it > > > > > > > >> should disclose AoRs providing indirect peering > > > > > relationships to > > > > > > > >> servicing peers or federations. > > > > > > > > > > > > > > >Sorry, I don't understand that sentence. > > > > > > > > > > > > > > >Do you mean that when a VSP adds an AoR to a federations=20 > > > > > > > >routing database, then it needs to discluse whether > > > that is a > > > > > > > >direct > > > > > > > customer > > > > > > > >or just a transit offer? > > > > > > > > > > > > > > Sorry, but I do not understand the whole issue: > > > > > > > > > > > > > > An AoR is a a special type of SIP URI (a Public User > > > > > > > Identity) defining the destination network (administrative > > > > > > > domain) > > > > > > > > > > > > > > How can it be disclosed or not, especially for a > > > transit network? > > > > > > > It is always public. > > > > > > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > Von: Otmar Lendl [mailto:lendl@nic.at] > > > > > > > Gesendet: Mi 18.10.2006 15:54 > > > > > > > An: Daryl Malas > > > > > > > Cc: speermint@ietf.org > > > > > > > Betreff: Re: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Daryl, > > > > > > > > > > > > > > > peering requirements from one operators perspective. I=20 > > > > > > > > can > > > > > > > post these > > > > > > > > to the list if you would like. Here is a list=20 > of peering > > > > > > > requirements > > > > > > > > (this is certainly not exhaustive, but is a platform): > > > > > > > > > > > > > > Here are my comments to that list: > > > > > > > > > > > > > > General: this seems to be a list providing=20 > details on what=20 > > > > > > > federations have to do (or agree on). > > > > > > > > > > > > > > > Transport (Layer 1 3): > > > > > > > > > > > > > > > > Peering must utilize IP as the primary mechanism > > > for peering. > > > > > > > > > > > > > > > > A federation must agree upon a common mechanism for IP > > > > > transport > > > > > > > > either private (e.g. IPVPN, IPSEC, etc.) or public. > > > > > > > > > > > > > > Fine. > > > > > > > > > > > > > > > Billing: > > > > > > > > > > > > > > Good. > > > > > > > > > > > > > > > Policy: > > > > > > > > > > > > > > > > > > > > > > Could you be a bit more specific on what you mean=20 > by "policy" > > > > > > > in this context? > > > > > > > > > > > > > > > Policies may be implemented locally to the peer or via a > > > > > > > centralized > > > > > > > > mechanism within the federation. > > > > > > > > > > > > > > > > Local policies should be disclosed when creating direct=20 > > > > > > > > peering relationships with the applicable direct peer. > > > > > > > > > > > > > > > > Local policies may supersede centralized federation > > > policies. > > > > > > > > > > > > > > > > (Net of this...some peering relationships will be 1:1, > > > > > so policies > > > > > > > > will likely be local only. Some peering relationships=20 > > > > > > > > will > > > > > > > be 1:N, so > > > > > > > > policies will likely be implemented within DNS or some > > > > > centralized > > > > > > > > mechanism.) > > > > > > > > > > > > > > Could you provide some examples of such policies? > > > > > > > > > > > > > > > Membership: > > > > > > > > > > > > > > > > A peer may be a member of multiple federations > > > > > > > > > > > > > > > > A peer must maintain compliancy for policies as=20 > defined by=20 > > > > > > > > each federation the peer is a member of. > > > > > > > > > > > > > > > > If a peer is providing connectivity to multiple > > > > > > > federations, it should > > > > > > > > disclose AoRs providing indirect peering=20 > relationships to=20 > > > > > > > > servicing peers or federations. > > > > > > > > > > > > > > Sorry, I don't understand that sentence. > > > > > > > > > > > > > > Do you mean that when a VSP adds an AoR to a > > > federations routing > > > > > > > database, then it needs to discluse whether that=20 > is a direct=20 > > > > > > > customer or just a transit offer? > > > > > > > > > > > > > > > Peers providing indirect peering must enforce federation > > > > > > > policies on > > > > > > > > behalf of the destination federation. > > > > > > > > > > > > > > > > A peer providing indirect peering may enforce=20 > undisclosed > > > > > > > policies for > > > > > > > > processing session requests between federations. > > > > > > > > > > > > > > > > (Net of this...some peers will only desire to be part > > > > > of a single > > > > > > > > federation, where wholesale carriers will likely be > > > members of > > > > > > > > multiple > > > > > > > > federations.) > > > > > > > > > > > > > > ok. > > > > > > > > > > > > > > > Media: > > > > > > > > > > > > > > ok. > > > > > > > > > > > > > > > Routing: > > > > > > > > > > > > > > > > A peer must utilize the centralized federation routing > > > > > > > mechanism if it > > > > > > > > is available. > > > > > > > > > > > > > > ok. > > > > > > > > > > > > > > > A peer allowing another peer within a federation to=20 > > > > > > > > provide > > > > > > > indirect > > > > > > > > peering on their behalf must select only one indirect > > > > > peer to host > > > > > > > > their AoRs. > > > > > > > > > > > > > > Do you mean indirect peering *within* a federation? Let > > > > > me name the > > > > > > > parties here: > > > > > > > > > > > > > > > A peer (X) allowing another peer (Y) within a > > > > > federation (F1) to > > > > > > > > provide indirect peering on their behalf must=20 > select only > > > > > > > one indirect > > > > > > > > peer to host their AoRs. > > > > > > > > > > > > > > Is the idea here that all members of F1 who want to place > > > > > calls to X > > > > > > > need to route the calls via Y? In that case, I would not > > > > > consider X > > > > > > > to be a member of F1. Instead, Y is providing transit > > > > > services for > > > > > > > X. > > > > > > > > > > > > > > Or you want to restrict X to be able to only select one > > > > > other VSP to > > > > > > > host it's AoRs in total? > > > > > > > > > > > > > > > A peer must not copy routing information from or make > > > > > > > assumed routing > > > > > > > > choices on behalf of the centralized routing=20 > mechanism for > > > > > > > use locally > > > > > > > > unless it takes place through standard caching methods. > > > > > > > > > > > > > > > > A common API must be utilized and available for=20 > subscriber > > > > > > > and route > > > > > > > > provisioning on any centralized federation location > > > function. > > > > > > > > > > > > > > > > Subscriber and routing information must be dynamically > > > > > > > updated as soon > > > > > > > > as applicable for accurate routing within the=20 > federation. > > > > > > > > > > > > > > ok > > > > > > > > > > > > > > > Performance: > > > > > > > > > > > > > > > > Performance metrics must be shared between peers as > > > they apply > > > > > > > > directly to peering signaling and media on a consistent > > > > > > > basis within > > > > > > > > the federation. > > > > > > > > > > > > > > ok > > > > > > > > > > > > > > /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 > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 15:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gadf0-0001Zu-2Y; Thu, 19 Oct 2006 15:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gadey-0001Zb-NU for speermint@ietf.org; Thu, 19 Oct 2006 15:34:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gadex-0005js-Di for speermint@ietf.org; Thu, 19 Oct 2006 15:34:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 12:34:32 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJYVR4000736 for ; Thu, 19 Oct 2006 15:34:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9JJYVDM007965 for ; Thu, 19 Oct 2006 15:34:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:34:31 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:34:30 -0400 Message-ID: <4537D346.4070702@cisco.com> Date: Thu, 19 Oct 2006 15:34:30 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:34:30.0717 (UTC) FILETIME=[98F08ED0:01C6F3B5] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161286471; x=1162150471; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:speermint@ietf.org; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=U0ZBZZyUaIOnJtzzQVH8Wf0WIzhwbvpbeGtvz1i4TLepV7o1oVsW2qj4aYLtXm/3BAaUn6md pJHhB5CpzhTxNWHrIxU+eXlwGNPsNq+AIELiBajUle+0Jf5pik1XY1Lc; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Speermint] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 16:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaeh5-0004Bl-FE; Thu, 19 Oct 2006 16:40:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadUe-0005Na-6P; Thu, 19 Oct 2006 15:23:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadUc-0003xD-RP; Thu, 19 Oct 2006 15:23:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 12:23:51 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JJNotj004329; Thu, 19 Oct 2006 15:23:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9JJNlYP028366; Thu, 19 Oct 2006 15:23:50 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:23:49 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:23:48 -0400 Message-ID: <4537D0C4.5020105@cisco.com> Date: Thu, 19 Oct 2006 15:23:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avt@ietf.org, ecrit@ietf.org, enum@ietf.org, geopriv@ietf.org, ieprep@ietf.org, iptel@ietf.org, mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, sip@ietf.org, sipping@ietf.org, speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:23:48.0914 (UTC) FILETIME=[1A653120:01C6F3B4] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161285830; x=1162149830; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:avt@ietf.org, =20ecrit@ietf.org, =20enum@ietf.org, =20geopriv@ietf.org, =0A= 20=20=20=20=20=20=20=20ieprep@ietf.org, =20iptel@ietf.org, =20mmusic@ietf.org , =20sigtran@ietf.org, =0A=20=20=20=20=20=20=20=20simple@ietf.org, =20sip@ietf .org, =20sipping@ietf.org, =20speechsc@ietf.org, =0A=20=20=20=20=20=20=20=20sp eermint@ietf.org,=20xcon@ietf.org; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=KrOzK3fR06ATri/gT7YJZroJcol7TSpMYe5BZE33gFcC/1PSyZC+oxmWK+oIC+fJQIbVoFL+ nf48uscnxvpV77HTZ0nnFeZmJMX4MuuOimxi0aG7+C8ixmvrHWsG0fmT; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 19 Oct 2006 16:40:45 -0400 Cc: Subject: [Speermint] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 19:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahU5-00028y-6t; Thu, 19 Oct 2006 19:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahU3-00028f-QA for speermint@ietf.org; Thu, 19 Oct 2006 19:39:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GahU1-0001hG-Hf for speermint@ietf.org; Thu, 19 Oct 2006 19:39:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GahTX-0004pg-9F; Thu, 19 Oct 2006 18:39:02 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Otmar Lendl'" , "'Daryl Malas'" Subject: RE: [Speermint] Basic Peering Requirements Date: Thu, 19 Oct 2006 19:38:58 -0400 Message-ID: <069101c6f3d7$c608c6e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIAACD+nQAAFdrnAAAcThcA== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30211FB78@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Wow, lots to disagree with ;) > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Thursday, October 19, 2006 3:21 PM > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Inline. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, October 19, 2006 2:27 PM > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar > > Lendl'; 'Daryl Malas' > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > I'm not advocating a particular solution, but, in general, I > > do want the ability to determine if a particular route > > (=federation or transit network I directly peer to) can get > > my call terminated correctly. > > This seems like chicken and egg problem. Were did your route come from? You ask the sources you have (the federations or the transit networks) if they can terminate your call. You don't care HOW they do it. > I think we both want to know that sending the next signaling message > will result in a call setup. Agree, of course > > > It's quite acceptable, and > > maybe optimal to just give me the info (which might be list > > of VSPs, but see below). It may be acceptable to just let me > > query for that (can I reach this VSP from you?). > > Not sure what you mean by info. What type of query are we talking > about? One way to do this is to provide a query to the federation: can you terminate a call to this VSP? As I discuss below, I don't think you really do this, because I think you don't have a TN to VSP database, but if you did, then a query to the federation by VSP with a yes/no answer is a satisfactory solution. Another is just a list (of VSPs reachable from this federation); it doesn't change very often. You can arrange your own query mechanism. Another is an announcement. That really is a routing protocol, and I don't think we need that, at least yet. > What does the query get you? Are you talking a trial an error approach? Well, sort of. You may have more than one federation membership. Since I don't see a God Box who could tell you which federation YOU BELONG TO can get you to the destination, you have to ask them all and, if more than one says yes, you have to have a way to decide which one. For the moment, I'm ignoring the how you decide. It's "trial and error" in the sense that you ask each federation, and get an answer from each, some of which may be error reports ("you can't get there from here via me") > > > What I don't need is the set of federations a VSP belongs to. > > I don't care a whit what federations they belong to. I only > > want to know which of my routes can get me to them. > > The federation is only a mechanism for finding a route. You are > positing the existence of a route in advance. In other words, you seem > to be assuming a solution and then some test to verify that it works. No, I'm assuming the federation can tell me next hop, and that's all it can tell me. That's more or less the way all routing works. It's more like you try all paths and see how many lead to your destination, but in this case you only get the next hop. But, like all routing problems, you may have zero, one, or more than one next hop choices that are valid. Whether you have in your possession all the routing data, or you query for it, or you query and cache for it, the result is the same: you ask every federation if they can route your call, and select one. > > > The number of VSPs is a small number in today's technology. > > What do you mean by VSP? I am assuming any organization that operates a > voice service and serves endpoints, which would include IP-PBX of > enterprises. If you aren't counting them, then you have underestimated. Well, one of the reasons I say it's a TN based query is that I don't really care how many VSPs there are. I further posit that some federations will deliberately obscure what happens behind their curtain; they won't tell you WHO they peer with directly, they will only give you the aggregate data. So, I don't care if it's 100, 1000, a million, or tens of millions. I'd rather it be billions (one per TN). Works for me :) > > > It's entirely feasible to have a single database with every > > TN in the world. > > That is a big database, but not beyond current single > > database technology. > > The number of VSPs is small in database terms. This is a > > database problem. > > > > Let's open this up a little more. > > > > If some kind of public enum tree is built, whether it's user > > enum or infrastructure enum in the public DNS, then we can do > > real two step lookups of TN to VSP and then do some kind VSP > > to something lookup. Right now, I don't see that happening much. > > Just having the VSP is unsufficient; that doesn't gurantee they will > accept your call. Yes, I agree with that. Presumably if a federation advertises reachability to a VSP, then the VSP will accept your call via that federation, however it is done. So, if you knew the VSP, you can ask the federations if they can route to that VSP and if they say yes, then that's a valid route. Similarly, you do know the TN, so you ask your federation(s) if they can route your TN and if they say yes, then that's your valid next hop route. > > > What will happen is private databases (ENUM or otherwise). > > We can argue if the federation runs the database. I think it > > will, one way or another. We have some problems. > > > > One is how indirect peering TNs are handled. Either they are > > imported into the database, or the query is proxied to > > another database. Either way, you launch a query and you get > > back either a URI within the federation or you get an error > > (not found). If you are a member of more than one > > federation, you may launch more than one such query, and you > > can get back zero, one or more than one URIs (from each query > > and the aggregate of all the queries). > > If the caller must go through a Transit VSP which runs its own > federation, then the TN lookup can point to the Transit VSP directly, as > well as identify the federation(s). Sure, as you say below, and I agree with your contention that a transit network looks like a federation of 2. And I agree that if you query that transit network's registry, you should see all the TNs it can get you to. Why you care what federations it is using to terminate your traffic, or why you think it will TELL you what federations it is using is beyond me. >The access to the private database > that gets from the Transit VSP to the terminating VSP can be private. Hmm, well somehow, the transit network has to tell you that it CAN terminate your call. I agree it doesn't have to tell you how it does that. If the query is, as I posit, by TN, then it has to give you access to some mechanism that will tell you if it can terminate your call which you query by TN. I think that is a registry. What you as originating network see is the aggregated information from the transit network's downstream arrangements. You get to see something that lets you figure out if this transit network can terminate your call. All of the URIs you would get back from a query would be URIs in the transit network's domain (federation of 2, right?). Now, HE has access to some other registries that contain different data: how he routes the call once you give it to him. You don't get to see them. You see a registry that (one way or another) is an aggregation of all of the downstream registries. > The problem has now morphed into how does the caller get to that Transit > VSP? Does the calling VSP have a peering relationship directly, or must > it go indirectly through yet another Transit VSP? Ah, yes, that is the point. Your transit network may be a peer in a federation. Another peer in that federation may itself be a transit network to yet another federation. Your transit network doesn't know how one of the peers of its federation gets to the other federation, and it doesn't care. It doesn't even know there is another transit network; all it knows is that the registry its connected to can terminate the call. The federation your transit network belongs to provides it with a registry of all of the TNs it can reach. That is in turn reflected to you via your transit provider, along with the TNs it can reach through any other arrangements it has (perhaps it is a member of several federations). Again, this is really like route advertisements moving up the chain. You don't get in those advertisements the intermediate connections, you only get your next hop route, expressed as reachability by one of your peers. > > Don't get hung up on the term federation, it is just a generalization of > the bilateral peering arrangement. That is, bilateral peering is just > the smallest federation possible; membership=2. YES! as above > > > This means you end up doing TN to URI in one step. We then > > have to decide if you get the ingress point directly, or > > there is another query for that; I suspect you get the > > ingress point in one step. > > No disagreement here. Saying that I can go from the originating VSP to > the terminating VSP directly, means that there is a direct peering > arrangement. Saying that they both belong to the same federation is > saying exactly the same thing. The more interesting question is > determining when you don't have a direct peering relationship (i.e. no > common federation) what to do. Well, there is no common federation between the originating carrier and the terminating carrier, and there is that circumstance (no common federation), but there is a route, via at least one of your federations, due to indirect peering relationships it has. Of course there is also the case of no route at all, meaning even with all the indirect relationships for all of your federation memberships taken into account, you still can't get the call routed to the destination VSP > > > If you have one answer, that's where you send the call. If > > you have zero answers, PSTN gateway gets the caLL. > > No, no, no! The goal of this exercise is to avoid the PSTN. The only > reason the PSTN should be used is when the TN is terminated to a TDM > switch and not reachable by IP. You are identifying a gap in your > approach, if a TN is a SIP phone terminated on a VSP and you end up on > the PSTN. Well, it would be very nice if we had some way to guarantee that there always is an IP route, but so far, I don't see that happening any time soon. If we all converge on a small set of federations, and those federations are all interconnected by some kind of indirect peering, so that from anywhere there is a path to anywhere else, then what you are looking for may happen. Right now, that isn't in anyone's horizon, even if they would like it to be true. There is still way too much jockeying for position to get universal connectivity. Now if we gave up on federations, and just used the Internet, why all of those problems disappear. > > > If you > > have more than one answer, you are into some kind of cost metric. > > > > The point is that you get an answer that is the route TO the > > VSP, not the federation the VSP belongs to, OR EVEN THE > > IDENTITY OF THE VSP. > > What is the means by which you identify the "route"? You ask each of your federations if they can terminate your call. Any of them who answer yes is a candidate route. Then you need a metric to choose. In my world, each of those federations has a database; you query that database by TN. You get a URI (which is the next hop) or you get no record found. > > > You query by TN. You may not even be > > given the identity of the destination VSP. Your query by TN > > only yields next hop. > > The next hop could also be just a default value and defer the problem to > the originating side Transit VSP. Not unless the transit VSP had direct or indirect peering with each and every VSP on the planet. I don't think such a thing is practical any time soon. > > The Transit VSP routing table could also list thousands of VSPs > associated with a route. But, if those groups of thousands were > associated with respective federations, then your table could be much > smaller if each thousand were replaced with a single federation:route > entry. Could the INVITE then be: > > SIP: Target URI > Route:Transit VSP > Route:Federation URN? Well, as I said way earlier, there is this idea some relatively small number of SPEERMINT participants think will happen where you can query the public DNS by TN for VSP, and then you need something that tells you route by VSP. I don't think that is going to happen. I think you query a private federation run database by TN, and you get next hop directly; you don't know who the termination VSP is. The result of the query becomes your Request URI and there is no Route header. > > > The only scenario where you know the VSP before you know the > > route is where there is a registry independent of the > > federation. > > I would call that registry the DNS. I think you are putting the cart > before the horse. Find the destination peer, then the route to get > there. Yeah, I would call that registry the DNS too. That isn't happening. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 19 20:35:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiMK-0003UC-8B; Thu, 19 Oct 2006 20:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiMG-0003MW-Na; Thu, 19 Oct 2006 20:35:32 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaiMF-000327-7H; Thu, 19 Oct 2006 20:35:32 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Oct 2006 17:35:26 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9K0WwvV004528; Thu, 19 Oct 2006 17:32:58 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k9K0YoeC005766; Thu, 19 Oct 2006 17:35:08 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 17:35:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Oct 2006 17:34:06 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141235@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reflections on Internet Transparency Thread-Index: Acbz3uEgekvUKJbHQ8Co6JzPaCd39Q== From: "Henry Sinnreich" To: , , X-OriginalArrivalTime: 20 Oct 2006 00:35:05.0415 (UTC) FILETIME=[96751570:01C6F3DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: elwynd@dial.pipex.com, bernarda@microsoft.com Subject: [Speermint] Reflections on Internet Transparency X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1119281647==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1119281647== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F3DF.95BCAA18" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F3DF.95BCAA18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My apology for posting this note about the AIB document on all three lists, but it seems all three WGs (and other as well) must request their contributors to specify in a _new section_ stating to what extent their I-Ds take into account the Internet e2e principle: =20 http://www.ietf.org/internet-drafts/draft-iab-net-transparent-00.txt=20 =20 It seems too many I-Ds in these WG are disregarding Internet Transparency as it applies to application, to QoS, to DNS usage and other. =20 Such a note is as important as the sections on Security and IANA IMHO, since it affects the very survival of the Internet. =20 Thanks, Henry ------_=_NextPart_001_01C6F3DF.95BCAA18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My apology for posting this note about the AIB document on all = three lists, but it seems all three WGs (and other as well) must request their contributors to specify in a _new = section_ stating to what extent their I-Ds take into account the Internet e2e = principle:

 

http://www.ietf.org/internet-drafts/draft-iab-net-transparent-00.txt=

 

It seems too many I-Ds in these = WG are disregarding Internet Transparency as it applies to application, to QoS, = to DNS usage and other.

 

Such a note is as important as = the sections on Security and IANA IMHO, since it affects the very survival = of the Internet.

 

Thanks, = Henry

------_=_NextPart_001_01C6F3DF.95BCAA18-- --===============1119281647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1119281647==-- From speermint-bounces@ietf.org Fri Oct 20 05:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gar8a-0001s7-8D; Fri, 20 Oct 2006 05:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gar8Y-0001rl-1o for speermint@ietf.org; Fri, 20 Oct 2006 05:57:58 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gar8W-0006mI-FC for speermint@ietf.org; Fri, 20 Oct 2006 05:57:57 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9K9vsJP005801; Fri, 20 Oct 2006 03:57:55 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt Date: Fri, 20 Oct 2006 03:57:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt Thread-Index: Acbx500a79c3oPLgR0KmXt543LeGQABr4gPgACXDx4A= From: "Jean-Francois Mule" To: "Avshalom Houri" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I asked: > - is there an equivalent of RFC3263 to locate presence servers? I guess this may be RFC 3861. Jean-Francois _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 06:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarwS-0007Gj-2R; Fri, 20 Oct 2006 06:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarwO-0006vf-Eu for speermint@ietf.org; Fri, 20 Oct 2006 06:49:28 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Garo0-0000GR-Lp for speermint@ietf.org; Fri, 20 Oct 2006 06:40:50 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 860422100A0; Fri, 20 Oct 2006 12:40:44 +0200 (CEST) Message-ID: <4538A7AE.6030505@pernau.at> Date: Fri, 20 Oct 2006 12:40:46 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Daryl Malas Subject: Re: [Speermint] Basic Peering Requirements References: <1160087883.16895.26.camel@montag.eng.level3.com> <20061018135408.GM19113@nic.at> <1161184583.16895.117.camel@montag.eng.level3.com> <20061018152331.GO15701@nic.at> <1161186955.16895.124.camel@montag.eng.level3.com> In-Reply-To: <1161186955.16895.124.camel@montag.eng.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl Malas wrote: >>>> Or you want to restrict X to be able to only select one other >>>> VSP to host it's AoRs in total? >>> Yes >>> >> How does multihoming (e.g. a small VSP which wants to by upstream services >> from multiple transit VSPs) fit into that scheme? > Again, I talked about this in a previous thread. A small VSP can be > multi-homed to a single transit VSP (e.g. multiple SF's). They will > also likely be connected "indirectly" to multiple federations, which > also may be contracted to provide an indirect route back to this > federation through one of the peers. > > I think this simplifies it greatly. If we must, then I suggest a > maximum of two peers in a federation may provide indirect peering to an > external VSP. I do not think it is possible to dictate a federation how many of its members may provide transit peering too. regards klaus -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 07:24:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GasTF-00005a-BD; Fri, 20 Oct 2006 07:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GasTD-00005A-Q1 for speermint@ietf.org; Fri, 20 Oct 2006 07:23:23 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GasT9-0001Re-31 for speermint@ietf.org; Fri, 20 Oct 2006 07:23:21 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 675D92100A0; Fri, 20 Oct 2006 13:22:44 +0200 (CEST) Message-ID: <4538B184.5070608@pernau.at> Date: Fri, 20 Oct 2006 13:22:44 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <00a601c6f2de$7d066370$640fa8c0@cis.neustar.com> In-Reply-To: <00a601c6f2de$7d066370$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > To me, this is off the deep end. > > I think we don't care what federations a destination network belongs to. ^^ we? Maybe you do not care. But there are people who care about the federation of a destination network. > Sorry Otmar. > > I think a federation may advertise what peers it can get you access to. > That may include transit peers, and those transit peers may get you to other > peers through other federations. The federation advertises the aggregate of > what networks it can reach, direct or indirect. In a steady state, the aggregate will be all VSPs in the world. That sounds like you want BGP for SIP - make sure not to forget loop detection. IMO a federation should only advertise federation members. If one of the federation members is also a transit provider, it should not be the task of the federation to collect all transit routes and announce them to the peers. Otherwise I do not really see the need of federations. > > I don't want a peer to have to keep relationships (how it gets to Fed X) > straight, I want it to be able to ask the federations or transit networks it Who will you ask? The federation or the transit networks? If the transit providers are also in federations, what is the difference between a transist network and a federation network which offers transit too? > deals with if they have a route to the destination network. > > If you take this view, then you always get what you want to know, regardless > of how convoluted the routes are, by simple queries to each > federation/transit network. If you try to trace routes in advance (let's > see, I want to get to network A, he is part of Fed 1 and Fed 2, I'm not in > fed 1 or 2, hmmm, peer Z is part of fed 2 and he is also part of Fed 3, and > I'm in fed 3, so I can send it to Z via fed 3, and he can send to fed 2 to > get to A). Of course it won't be that easy as peer 2 will charge different costs (or require additional transit contracts) if it terminates a call or forward it. > > Much better if Fed 3 advertises it can reach A. > > This is how route advertisements work, and I think we should assume that's > the best way until proven otherwise. > > So let's not talk about Federations a network belongs to, and specifically, > don't talk about routes TO A FEDERATION, but rather routes to a destination > network FROM a federation. Again. If the federations are irrelevant - for what purpose do you still need them? regards klaus -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 07:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GassV-0005Qf-33; Fri, 20 Oct 2006 07:49:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GassS-0005QJ-Tj for speermint@ietf.org; Fri, 20 Oct 2006 07:49:28 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GassO-0007um-Va for speermint@ietf.org; Fri, 20 Oct 2006 07:49:28 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 34031210076; Fri, 20 Oct 2006 13:49:14 +0200 (CEST) Message-ID: <4538B7BB.3070505@pernau.at> Date: Fri, 20 Oct 2006 13:49:15 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <048f01c6f3ac$24338b00$640fa8c0@cis.neustar.com> In-Reply-To: <048f01c6f3ac$24338b00$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > I'm not advocating a particular solution, but, in general, I do want the > ability to determine if a particular route (=federation or transit network I > directly peer to) can get my call terminated correctly. It's quite > acceptable, and maybe optimal to just give me the info (which might be list > of VSPs, but see below). It may be acceptable to just let me query for that > (can I reach this VSP from you?). > > What I don't need is the set of federations a VSP belongs to. I don't care > a whit what federations they belong to. I only want to know which of my > routes can get me to them. > > The number of VSPs is a small number in today's technology. > > It's entirely feasible to have a single database with every TN in the world. > That is a big database, but not beyond current single database technology. And every VSP is dependent on the provider of this database...real nice. > The number of VSPs is small in database terms. This is a database problem. Every enterprise with an IP PBX will be its own VSPs. Thus, you may not only count TDM carriers or big VSPs. > > Let's open this up a little more. > > If some kind of public enum tree is built, whether it's user enum or > infrastructure enum in the public DNS, then we can do real two step lookups > of TN to VSP and then do some kind VSP to something lookup. Right now, I > don't see that happening much. > What will happen is private databases (ENUM or otherwise). We can argue if > the federation runs the database. I think it will, one way or another. We > have some problems. > > One is how indirect peering TNs are handled. Either they are imported into > the database, or the query is proxied to another database. Either way, you > launch a query and you get back either a URI within the federation or you > get an error (not found). If you are a member of more than one federation, > you may launch more than one such query, and you can get back zero, one or > more than one URIs (from each query and the aggregate of all the queries). > > This means you end up doing TN to URI in one step. We then have to decide > if you get the ingress point directly, or there is another query for that; I > suspect you get the ingress point in one step. Why do you propose a solution which makes VSP dependent on provider of this big routing databases? IMO an IETF solution should not force VSPs to private ENUM trees and peering providers. regards klaus > > If you have one answer, that's where you send the call. If you have zero > answers, PSTN gateway gets the caLL. If you have more than one answer, you > are into some kind of cost metric. > > The point is that you get an answer that is the route TO the VSP, not the > federation the VSP belongs to, OR EVEN THE IDENTITY OF THE VSP. You query > by TN. You may not even be given the identity of the destination VSP. Your > query by TN only yields next hop. > > The only scenario where you know the VSP before you know the route is where > there is a registry independent of the federation. That just isn't really > happening except in a very few isolated places. I suppose we need to give > them some kind of solution, but I don't care much about it, because I think > it's not going to be common. > > Brian > >> -----Original Message----- >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> Sent: Thursday, October 19, 2006 1:00 PM >> To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas >> Cc: speermint@ietf.org >> Subject: RE: [Speermint] Basic Peering Requirements >> >> "The point is that for each route, what I want is the complete set of >> VSPs that route can get me to." >> >> So, you have entries for all VSPs on Earth? >> >> When 1 Federation = N VSPs, where N can be many orders of magnitude >> above 1, I would contend that: >> >> "The point is that for each route, what I want is the complete set of >> Federations that route can get me to." >> >> would scale better. >> >> Mike >> >> >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Thursday, October 19, 2006 12:29 PM >>> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar >>> Lendl'; 'Daryl Malas' >>> Cc: speermint@ietf.org >>> Subject: RE: [Speermint] Basic Peering Requirements >>> >>> Which scaling limits are you working from, PSTN or the Internet? >>> >>> Reachability to thousands (or tens of thousands, or a couple hundred >>> thousand) VSPs is what I want. >>> >>> I want the "best" route to a VSP (which I may only know by a >>> TN in a registry). A federation is one potential route. >>> >>> Scaling to tens or hundreds of thousands of routes is usually >>> considered to be quite reasonable, and even millions is quite >>> reasonable for L5 routing since we don't need to keep the >>> routes in memory. Certainly a federation returning VSP >>> reachability to that many VSPs is easy. >>> >>> If all I have is one transit peer, and no federations, then I >>> can launch my call and if it doesn't work, all I can do is >>> send it via the PSTN. Same if I am only a member of one federation. >>> >>> As soon as I have two routes, I need to know where to send it >>> for the next hop. I have the destination VSP, I choose a >>> route: VSP in, route out. I check my routes for >>> reachability. If there is only one route, I send out the >>> call that way. If I have more than one route, then I need a >>> cost metric, and we don't have to go there right now. The >>> point is that for each route, what I want is the complete set >>> of VSPs that route can get me to. >>> >>> Seems like getting that information directly is the simplest >>> way to go. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>>> Sent: Thursday, October 19, 2006 10:46 AM >>>> To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas >>>> Cc: speermint@ietf.org >>>> Subject: RE: [Speermint] Basic Peering Requirements >>>> >>>> Brian, >>>> >>>> Which would you rather maintain and advertise: >>>> >>>> reachability to a hundred federations, or reachability to >>> millions of >>>> VSPs? >>>> >>>> What you suggest doesn't scale. >>>> >>>> The idea here was that once you know that a VSP belongs to a >>>> federation (via ENUM and DNS), you are now looking for information >>>> that your Transit VSP supports that federation and to which >>> signaling >>>> address of the Transit VSP to send the next signaling message. >>>> >>>> Isn't that simpler? Don't know why you want to make it harder. >>>> >>>> There can be an address from which a federation membership can be >>>> fetched, but I would rather be pointed to the answer, than scanning >>>> through lengthy membership lists to discover relationships. >>> I think >>>> the main value is in having a federation point to the Transit >>>> providers serving a federation only. That should be a much smaller >>>> list. But, that step would not be needed by the >>> originating VSP if it >>>> already knows what federations its own Transit VSP serves and the >>>> terminating federation is on that list. >>>> >>>> In summary, routing towards federations as an aggregation mechanism >>>> rather than individual VSPs scales better. >>>> >>>> Mike >>>> >>>> >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Wednesday, October 18, 2006 1:55 PM >>>>> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl'; >>>>> 'Daryl Malas' >>>>> Cc: speermint@ietf.org >>>>> Subject: RE: [Speermint] Basic Peering Requirements >>>>> >>>>> To me, this is off the deep end. >>>>> >>>>> I think we don't care what federations a destination >>> network belongs >>>>> to. >>>>> Sorry Otmar. >>>>> >>>>> I think a federation may advertise what peers it can get >>> you access >>>>> to. >>>>> That may include transit peers, and those transit peers >>> may get you >>>>> to other peers through other federations. The federation >>> advertises >>>>> the aggregate of what networks it can reach, direct or indirect. >>>>> >>>>> I don't want a peer to have to keep relationships (how it gets to >>>>> Fed X) straight, I want it to be able to ask the federations or >>>>> transit networks it deals with if they have a route to the >>>>> destination network. >>>>> >>>>> If you take this view, then you always get what you want to know, >>>>> regardless of how convoluted the routes are, by simple queries to >>>>> each federation/transit network. If you try to trace routes in >>>>> advance (let's see, I want to get to network A, he is >>> part of Fed 1 >>>>> and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of >>> fed 2 and >>>>> he is also part of Fed 3, and I'm in fed 3, so I can send it to Z >>>>> via fed 3, and he can send to fed 2 to get to A). >>>>> >>>>> Much better if Fed 3 advertises it can reach A. >>>>> >>>>> This is how route advertisements work, and I think we >>> should assume >>>>> that's the best way until proven otherwise. >>>>> >>>>> So let's not talk about Federations a network belongs to, and >>>>> specifically, don't talk about routes TO A FEDERATION, but rather >>>>> routes to a destination network FROM a federation. >>>>> >>>>> Brian >>>>> >>>>>> -----Original Message----- >>>>>> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>>>>> Sent: Wednesday, October 18, 2006 1:01 PM >>>>>> To: Stastny Richard; Otmar Lendl; Daryl Malas >>>>>> Cc: speermint@ietf.org >>>>>> Subject: RE: [Speermint] Basic Peering Requirements >>>>>> >>>>>> I had taken this to mean that the Transit VSP would be >>>>> advertising to >>>>>> originating VSPs reachability to various federations of >>> the form: >>>>>> (to get to) (contact) >>>>>> Federation X --> Fed-X@VSP.com (Fed-X etc. could be an >>> arbitrary >>>>>> string) >>>>>> Federation Y --> Fed-Y@VSP.com >>>>>> Federation Z --> Fed-Z@VSP.com >>>>>> >>>>>> or: >>>>>> >>>>>> Federation X --> Fed-Any@VSP.com >>>>>> Federation Y --> Fed-Any@VSP.com >>>>>> Federation Z --> Fed-Any@VSP.com >>>>>> >>>>>> If not, count me as misunderstanding too. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>>>> Sent: Wednesday, October 18, 2006 10:05 AM >>>>>>> To: Otmar Lendl; Daryl Malas >>>>>>> Cc: speermint@ietf.org >>>>>>> Subject: Re: [Speermint] Basic Peering Requirements >>>>>>> >>>>>>>>> If a peer is providing connectivity to multiple >>>>> federations, it >>>>>>>>> should disclose AoRs providing indirect peering >>>>> relationships to >>>>>>>>> servicing peers or federations. >>>>>>>> Sorry, I don't understand that sentence. >>>>>>>> Do you mean that when a VSP adds an AoR to a federations >>>>>>>> routing database, then it needs to discluse whether >>> that is a >>>>>>>> direct >>>>>>> customer >>>>>>>> or just a transit offer? >>>>>>> Sorry, but I do not understand the whole issue: >>>>>>> >>>>>>> An AoR is a a special type of SIP URI (a Public User >>>>>>> Identity) defining the destination network (administrative >>>>>>> domain) >>>>>>> >>>>>>> How can it be disclosed or not, especially for a >>> transit network? >>>>>>> It is always public. >>>>>>> >>>>>>> Richard >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> Von: Otmar Lendl [mailto:lendl@nic.at] >>>>>>> Gesendet: Mi 18.10.2006 15:54 >>>>>>> An: Daryl Malas >>>>>>> Cc: speermint@ietf.org >>>>>>> Betreff: Re: [Speermint] Basic Peering Requirements >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Daryl, >>>>>>> >>>>>>>> peering requirements from one operators perspective. I can >>>>>>> post these >>>>>>>> to the list if you would like. Here is a list of peering >>>>>>> requirements >>>>>>>> (this is certainly not exhaustive, but is a platform): >>>>>>> Here are my comments to that list: >>>>>>> >>>>>>> General: this seems to be a list providing details on what >>>>>>> federations have to do (or agree on). >>>>>>> >>>>>>>> Transport (Layer 1 3): >>>>>>>> >>>>>>>> Peering must utilize IP as the primary mechanism >>> for peering. >>>>>>>> A federation must agree upon a common mechanism for IP >>>>> transport >>>>>>>> either private (e.g. IPVPN, IPSEC, etc.) or public. >>>>>>> Fine. >>>>>>> >>>>>>>> Billing: >>>>>>> Good. >>>>>>> >>>>>>>> Policy: >>>>>>>> >>>>>>> Could you be a bit more specific on what you mean by "policy" >>>>>>> in this context? >>>>>>> >>>>>>>> Policies may be implemented locally to the peer or via a >>>>>>> centralized >>>>>>>> mechanism within the federation. >>>>>>>> >>>>>>>> Local policies should be disclosed when creating direct >>>>>>>> peering relationships with the applicable direct peer. >>>>>>>> >>>>>>>> Local policies may supersede centralized federation >>> policies. >>>>>>>> (Net of this...some peering relationships will be 1:1, >>>>> so policies >>>>>>>> will likely be local only. Some peering relationships will >>>>>>> be 1:N, so >>>>>>>> policies will likely be implemented within DNS or some >>>>> centralized >>>>>>>> mechanism.) >>>>>>> Could you provide some examples of such policies? >>>>>>> >>>>>>>> Membership: >>>>>>>> >>>>>>>> A peer may be a member of multiple federations >>>>>>>> >>>>>>>> A peer must maintain compliancy for policies as defined by >>>>>>>> each federation the peer is a member of. >>>>>>>> >>>>>>>> If a peer is providing connectivity to multiple >>>>>>> federations, it should >>>>>>>> disclose AoRs providing indirect peering relationships to >>>>>>>> servicing peers or federations. >>>>>>> Sorry, I don't understand that sentence. >>>>>>> >>>>>>> Do you mean that when a VSP adds an AoR to a >>> federations routing >>>>>>> database, then it needs to discluse whether that is a direct >>>>>>> customer or just a transit offer? >>>>>>> >>>>>>>> Peers providing indirect peering must enforce federation >>>>>>> policies on >>>>>>>> behalf of the destination federation. >>>>>>>> >>>>>>>> A peer providing indirect peering may enforce undisclosed >>>>>>> policies for >>>>>>>> processing session requests between federations. >>>>>>>> >>>>>>>> (Net of this...some peers will only desire to be part >>>>> of a single >>>>>>>> federation, where wholesale carriers will likely be >>> members of >>>>>>>> multiple >>>>>>>> federations.) >>>>>>> ok. >>>>>>> >>>>>>>> Media: >>>>>>> ok. >>>>>>> >>>>>>>> Routing: >>>>>>>> >>>>>>>> A peer must utilize the centralized federation routing >>>>>>> mechanism if it >>>>>>>> is available. >>>>>>> ok. >>>>>>> >>>>>>>> A peer allowing another peer within a federation to provide >>>>>>> indirect >>>>>>>> peering on their behalf must select only one indirect >>>>> peer to host >>>>>>>> their AoRs. >>>>>>> Do you mean indirect peering *within* a federation? Let >>>>> me name the >>>>>>> parties here: >>>>>>> >>>>>>>> A peer (X) allowing another peer (Y) within a >>>>> federation (F1) to >>>>>>>> provide indirect peering on their behalf must select only >>>>>>> one indirect >>>>>>>> peer to host their AoRs. >>>>>>> Is the idea here that all members of F1 who want to place >>>>> calls to X >>>>>>> need to route the calls via Y? In that case, I would not >>>>> consider X >>>>>>> to be a member of F1. Instead, Y is providing transit >>>>> services for >>>>>>> X. >>>>>>> >>>>>>> Or you want to restrict X to be able to only select one >>>>> other VSP to >>>>>>> host it's AoRs in total? >>>>>>> >>>>>>>> A peer must not copy routing information from or make >>>>>>> assumed routing >>>>>>>> choices on behalf of the centralized routing mechanism for >>>>>>> use locally >>>>>>>> unless it takes place through standard caching methods. >>>>>>>> >>>>>>>> A common API must be utilized and available for subscriber >>>>>>> and route >>>>>>>> provisioning on any centralized federation location >>> function. >>>>>>>> Subscriber and routing information must be dynamically >>>>>>> updated as soon >>>>>>>> as applicable for accurate routing within the federation. >>>>>>> ok >>>>>>> >>>>>>>> Performance: >>>>>>>> >>>>>>>> Performance metrics must be shared between peers as >>> they apply >>>>>>>> directly to peering signaling and media on a consistent >>>>>>> basis within >>>>>>>> the federation. >>>>>>> ok >>>>>>> >>>>>>> /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 -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 08:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gat8C-0001Nb-Iz; Fri, 20 Oct 2006 08:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gat8B-0001LA-97 for speermint@ietf.org; Fri, 20 Oct 2006 08:05:43 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gat87-0001gT-SJ for speermint@ietf.org; Fri, 20 Oct 2006 08:05:43 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1161345938!906614!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6586 invoked from network); 20 Oct 2006 12:05:38 -0000 Received: from unknown (HELO attrh8i.attrh.att.com) (134.24.146.4) by server-13.tower-120.messagelabs.com with SMTP; 20 Oct 2006 12:05:38 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9KC4SV8025629 for ; Fri, 20 Oct 2006 08:04:28 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh8i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9KC3Gl5025286 for ; Fri, 20 Oct 2006 08:04:24 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C33000CF0F6; Fri, 20 Oct 2006 08:05:32 -0400 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] Basic Peering Requirements Date: Fri, 20 Oct 2006 08:05:30 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DEA6A40@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <4538B7BB.3070505@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb0PgkpQBRRD89VQN2AppamOkcbEgAAatCA From: "Pfautz, Penn L, GBLAM" To: "Klaus Darilion" , "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Klaus: The VSPs (and the Internet) are already dependent on big databases. It's just DNS. I share your concern about a being captive to the owner Of such a database. That's why some of us are working to implement user ENUM and infrastructure ENUM in a way similar TLD registries so that it's no one entity's private property but is managed cooperatively.=20 Penn Pfautz -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Friday, October 20, 2006 7:49 AM To: Brian Rosen Cc: 'Stastny Richard'; speermint@ietf.org; 'Otmar Lendl' Subject: Re: [Speermint] Basic Peering Requirements Brian Rosen wrote: > I'm not advocating a particular solution, but, in general, I do want the > ability to determine if a particular route (=3Dfederation or transit network I > directly peer to) can get my call terminated correctly. It's quite > acceptable, and maybe optimal to just give me the info (which might be list > of VSPs, but see below). It may be acceptable to just let me query for that > (can I reach this VSP from you?). >=20 > What I don't need is the set of federations a VSP belongs to. I don't care > a whit what federations they belong to. I only want to know which of my > routes can get me to them. >=20 > The number of VSPs is a small number in today's technology. >=20 > It's entirely feasible to have a single database with every TN in the world. > That is a big database, but not beyond current single database technology. And every VSP is dependent on the provider of this database...real nice. > The number of VSPs is small in database terms. This is a database problem.=20 Every enterprise with an IP PBX will be its own VSPs. Thus, you may not=20 only count TDM carriers or big VSPs. >=20 > Let's open this up a little more. >=20 > If some kind of public enum tree is built, whether it's user enum or > infrastructure enum in the public DNS, then we can do real two step lookups > of TN to VSP and then do some kind VSP to something lookup. Right now, I > don't see that happening much. > What will happen is private databases (ENUM or otherwise). We can argue if > the federation runs the database. I think it will, one way or another. We > have some problems. >=20 > One is how indirect peering TNs are handled. Either they are imported into > the database, or the query is proxied to another database. Either way, you > launch a query and you get back either a URI within the federation or you > get an error (not found). If you are a member of more than one federation, > you may launch more than one such query, and you can get back zero, one or > more than one URIs (from each query and the aggregate of all the queries). >=20 > This means you end up doing TN to URI in one step. We then have to decide > if you get the ingress point directly, or there is another query for that; I > suspect you get the ingress point in one step. Why do you propose a solution which makes VSP dependent on provider of=20 this big routing databases? IMO an IETF solution should not force VSPs=20 to private ENUM trees and peering providers. regards klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 08:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gatke-0005xI-AN; Fri, 20 Oct 2006 08:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gatkc-0005xA-IQ for speermint@ietf.org; Fri, 20 Oct 2006 08:45:26 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GatkZ-0007vu-2O for speermint@ietf.org; Fri, 20 Oct 2006 08:45:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GatgP-00050c-98; Fri, 20 Oct 2006 07:41:05 -0500 From: "Brian Rosen" To: "'Klaus Darilion'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 08:41:04 -0400 Message-ID: <089001c6f445$04bd3f70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb0PcmnocUqizR8TlaIx7eU5qFAhgAALPIA In-Reply-To: <4538B7BB.3070505@pernau.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > And every VSP is dependent on the provider of this database...real nice. Well, actually, it works, but I wasn't imaging that there would really be one huge database that one entity administered. Now, if we can all get together and do it, why I'm sure I know a firm who would bid on the job. > > > The number of VSPs is small in database terms. This is a database > problem. > > Every enterprise with an IP PBX will be its own VSPs. Thus, you may not > only count TDM carriers or big VSPs. I really don't think federations will be used for huge numbers of Enterprise VSPs. I think that will be done on the Internet. It is carriers that are paranoid about the Internet, and insist on private peering arrangements. Another viable, and reasonable scenario is that, like the Internet, Enterprise purchases transit from a transit carrier. The transit carrier is, as Mike points out, a federation of 2 to each peer, or it can look like a federation itself if it permits arbitrary call termination to all of the entities it provides transit for. Regardless, it aggregates routing data among all of its customers. The transit network then peers at one or more federations. To a direct peer of one of those federations, the enterprise TNs appear to be terminated by the federation (at the transit network peer connection). This is just another route aggregation, and it scales very well. ...snip... > > This means you end up doing TN to URI in one step. We then have to > decide > > if you get the ingress point directly, or there is another query for > that; I > > suspect you get the ingress point in one step. > > Why do you propose a solution which makes VSP dependent on provider of > this big routing databases? IMO an IETF solution should not force VSPs > to private ENUM trees and peering providers. If anyone wants to put information in the public (user) enum tree, they are free do so. They can then peer on the Internet, surely the best IETF solution. If a carrier puts numbers in a public enum tree (anywhere in .arpa), it can advertise in that tree how it may be contacted. I don't think the notion that your number is in a public tree, but your ingress points at whatever federations you peer at are secret makes any sense and I don't see the point in 2 or 3 level lookup in this case; just put the ingress points in the federations in the main enum response and let a peer pick one of them that it likes based on its memberships and your order/preference. If you have no common federations then you need to identify a route. I've never understood how you proposed to do that. I'm dealing with reality. Reality is that the numbers ARE NOT in a public database, the peering points, or even federation membership ARE NOT in a public database, but all-IP connections and RFCs are used between consenting peers. I'm trying to get a system that allows us to build interoperable implementations that gracefully scale, and work in the real world. It would be great if there was one database in the sky (say, the DNS). It's not happening yet, except in a very few isolated instances. I also think that the notion that the originating network figures out the entire path to the terminating network by tracing paths from the terminating networks federation memberships back towards it is a bad idea. I think route availability is fed towards the originating network by the terminating network, so that the originating network need only discover its next hop. That's a route mechanism we know works really well, and when we need to automate it (BGP), we can. We don't need to automate that now. I'm not proposing that we do automate that now. I'm proposing we use that model to advertise routes. Of course, I'm also advocating that the route query is a TN and not a VSP, because I don't believe there is a way to get the VSP without also getting next hop in one lookup. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 09:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauJv-0006Xd-7W; Fri, 20 Oct 2006 09:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauJt-0006XS-Qm for speermint@ietf.org; Fri, 20 Oct 2006 09:21:53 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GauJs-0005Wk-Bd for speermint@ietf.org; Fri, 20 Oct 2006 09:21:53 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id DA0E221006C; Fri, 20 Oct 2006 15:21:33 +0200 (CEST) Message-ID: <4538CD5F.90009@pernau.at> Date: Fri, 20 Oct 2006 15:21:35 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <089001c6f445$04bd3f70$640fa8c0@cis.neustar.com> In-Reply-To: <089001c6f445$04bd3f70$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > ...snip... >>> This means you end up doing TN to URI in one step. We then have to >> decide >>> if you get the ingress point directly, or there is another query for >> that; I >>> suspect you get the ingress point in one step. >> Why do you propose a solution which makes VSP dependent on provider of >> this big routing databases? IMO an IETF solution should not force VSPs >> to private ENUM trees and peering providers. > If anyone wants to put information in the public (user) enum tree, they are > free do so. They can then peer on the Internet, surely the best IETF Really? In USA every telco can immediately put its numbers in e164.arpa? I suspect this is more an authoritative problem than a technical and probably lots of people will be happy if these problems are never solved. > solution. If a carrier puts numbers in a public enum tree (anywhere in > .arpa), it can advertise in that tree how it may be contacted. I don't > think the notion that your number is in a public tree, but your ingress > points at whatever federations you peer at are secret makes any sense and I > don't see the point in 2 or 3 level lookup in this case; just put the > ingress points in the federations in the main enum response and let a peer 1. because there are SIP URIs - yes I want the SPEERMINT solution also to work with > pick one of them that it likes based on its memberships and your > order/preference. If you have no common federations then you need to ^^^^^^^^ exactly, only in the case of no common federation a transit peering is needed. If VSPs are in the same federation, they should be able to automatically find each other and peer without the need of a central routing database. > identify a route. I've never understood how you proposed to do that. These are probably to steps: 1. find out if I can contact the peer directly, 2. find out a transit route if 1 does not. If I understand you correctly you will do both steps in a single lookup. Thus, binding VSPs to the central routing table provider even if it is not needed (step 1). I guess there are lots of companies which prefer doing an additional free DNS lookup before looking up the almighty, per lookup charged, routing database. > I'm dealing with reality. Reality is that the numbers ARE NOT in a public Reality is also that there are forces which try to slow down user ENUM and infrastructure ENUM development. And once again: SPEERMINT is not about numbers - it's about peering with SIP. > database, the peering points, or even federation membership ARE NOT in a > public database, but all-IP connections and RFCs are used between consenting > peers. I'm trying to get a system that allows us to build interoperable > implementations that gracefully scale, and work in the real world. Sorry, I did not knew that a central lookup database is a scaling solution. regards klaus > It would be great if there was one database in the sky (say, the DNS). It's > not happening yet, except in a very few isolated instances. > > I also think that the notion that the originating network figures out the > entire path to the terminating network by tracing paths from the terminating > networks federation memberships back towards it is a bad idea. I think > route availability is fed towards the originating network by the terminating > network, so that the originating network need only discover its next hop. > That's a route mechanism we know works really well, and when we need to > automate it (BGP), we can. We don't need to automate that now. I'm not > proposing that we do automate that now. I'm proposing we use that model to > advertise routes. > > Of course, I'm also advocating that the route query is a TN and not a VSP, > because I don't believe there is a way to get the VSP without also getting > next hop in one lookup. > > Brian > -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 09:24:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauLp-0000DA-Lb; Fri, 20 Oct 2006 09:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauLo-0000D4-A3 for speermint@ietf.org; Fri, 20 Oct 2006 09:23:52 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GauLm-0005tL-ER for speermint@ietf.org; Fri, 20 Oct 2006 09:23:52 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 9994C21006C; Fri, 20 Oct 2006 15:23:46 +0200 (CEST) Message-ID: <4538CDE4.1070606@pernau.at> Date: Fri, 20 Oct 2006 15:23:48 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Pfautz, Penn L, GBLAM" Subject: Re: [Speermint] Basic Peering Requirements References: <34DA635B184A644DA4588E260EC0A25A0DEA6A40@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0DEA6A40@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Pfautz, Penn L, GBLAM wrote: > Klaus: > The VSPs (and the Internet) are already dependent on big databases. It's > just DNS. Yes. But DNS is open and distributed. > I share your concern about a being captive to the owner > Of such a database. That's why some of us are working to implement user > ENUM and infrastructure ENUM in a way similar TLD registries so that > it's no one entity's private property but is managed cooperatively. That's how it should be. regards klaus > > Penn Pfautz > > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Friday, October 20, 2006 7:49 AM > To: Brian Rosen > Cc: 'Stastny Richard'; speermint@ietf.org; 'Otmar Lendl' > Subject: Re: [Speermint] Basic Peering Requirements > > Brian Rosen wrote: >> I'm not advocating a particular solution, but, in general, I do want > the >> ability to determine if a particular route (=federation or transit > network I >> directly peer to) can get my call terminated correctly. It's quite >> acceptable, and maybe optimal to just give me the info (which might be > list >> of VSPs, but see below). It may be acceptable to just let me query > for that >> (can I reach this VSP from you?). >> >> What I don't need is the set of federations a VSP belongs to. I don't > care >> a whit what federations they belong to. I only want to know which of > my >> routes can get me to them. >> >> The number of VSPs is a small number in today's technology. >> >> It's entirely feasible to have a single database with every TN in the > world. >> That is a big database, but not beyond current single database > technology. > > And every VSP is dependent on the provider of this database...real nice. > >> The number of VSPs is small in database terms. This is a database > problem. > > Every enterprise with an IP PBX will be its own VSPs. Thus, you may not > only count TDM carriers or big VSPs. > >> Let's open this up a little more. >> >> If some kind of public enum tree is built, whether it's user enum or >> infrastructure enum in the public DNS, then we can do real two step > lookups >> of TN to VSP and then do some kind VSP to something lookup. Right > now, I >> don't see that happening much. >> What will happen is private databases (ENUM or otherwise). We can > argue if >> the federation runs the database. I think it will, one way or > another. We >> have some problems. >> >> One is how indirect peering TNs are handled. Either they are imported > into >> the database, or the query is proxied to another database. Either > way, you >> launch a query and you get back either a URI within the federation or > you >> get an error (not found). If you are a member of more than one > federation, >> you may launch more than one such query, and you can get back zero, > one or >> more than one URIs (from each query and the aggregate of all the > queries). >> This means you end up doing TN to URI in one step. We then have to > decide >> if you get the ingress point directly, or there is another query for > that; I >> suspect you get the ingress point in one step. > > Why do you propose a solution which makes VSP dependent on provider of > this big routing databases? IMO an IETF solution should not force VSPs > to private ENUM trees and peering providers. > > regards > klaus -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 09:26:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauOe-0005Pm-Fz; Fri, 20 Oct 2006 09:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GauOd-0005Pf-EC for speermint@ietf.org; Fri, 20 Oct 2006 09:26:47 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GauOY-0006WS-IA for speermint@ietf.org; Fri, 20 Oct 2006 09:26:47 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id BDE9D21006C; Fri, 20 Oct 2006 15:26:38 +0200 (CEST) Message-ID: <4538CE90.9020000@pernau.at> Date: Fri, 20 Oct 2006 15:26:40 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Speermint] TLS related requirements for speermint ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: speermint@ietf.org, vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Jean-Francois! Great that the TLS stuff is getting a shape. comments inline Jean-Francois Mule wrote: > > --- 1. Peers SHOULD mutually trust each other's root CAs > - Motivations: > A VSP/ASP should have control over which root CA it trusts; this may > imply creating a certificate trust list to include the peer's CA for > each authorized domain. > This requirement allows for the initiating side to verify that the > server cert is rooted in a well-known CA. Please keep in mind 2 different scenarios: 1. certificates signed by well known/trusted CAs (e.g. Thawte) 2. self-signed certificates In case 1, a VSP installs the root CA of the trusted CA. In case 2, usually the VSP does not install the peers CA, but rather signs the peers certificate with its own CA cert. > - Derivative requirement: > SIP servers SHOULD allow the configuration of certificate trust lists in > order to allow a VSP/ASP to control which peer's CAs are trusted for TLS > connections. ACK. At best this should be allowed on a per-call basis, not globally for all TLS connections. At the openser summit during VON Europe I will give a talk how to do this with openser. http://www.openser.org/index.php?option=com_content&task=view&id=60&Itemid=72 > --- 2. Peers SHOULD indicate whether their domain policies require proxy > servers to inspect and verify the identity provided in SIP requests per > RFC 4474. This can be done either implicitly via federation policies or explicitly via dedicated policy NAPTRs (draft-lendl-speermint-technical-policy) > > --- 3. When TLS is used between peers, SIP servers involved in the > session establishment MUST have valid X.509 certificates and MUST be > able to receive a TLS connection. > > Motivations: > If TLS is supported for session peering, SIP servers must have valid > X.509 certificates and they should listen on the SIP TLS port for > incoming connections. Maybe "valid" should be described in more detail. not expired, not self signed, hostname in the cert vs. hostname of the server, CA, ...? > > --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed upon > as part of session peering policies: > + The version of TLS (TLSv1, TLSv1.1) > + The SIP TLS port (default 5061) > + The server-side session timeout (default 300 seconds) is this the time until an idle TLS conenction is closed? > + The list of supported or recommended ciphersuite > + list of trusted root CAs maybe also the certificate itself. Maybe a VSP has different certificates for different purposes. more next week. have a nice weekend klaus > --- 5. SIP entities involved in the session establishment exchanges MUST > follow the following requirements: > + check certs : > "the client certificate MUST contain a DNS or URI choice type in the > subjectAltName which corresponds to the domain asserted in the host > production of the From header URI." (from Rohan's I-D) > + check identity in cert per section 4 of > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? > + add details and pointers to the use of RFC 4474 > inter-domain. > > ==> open questions: > These are best current practices that should be followed. We can > either reference the work-in-progress IDs or paste some of the most > relevant text and then refer to the I-Ds. > > REFERENCEs: > - Rohan's direct peering draft > http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct-peering-0 > 0.txt, > - Vijay's > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: > > --- 6. A session peering policy SHOULD include details on SIP session > establishment over TLS (see above, to be briefly summarized1111). > > > --- Open questions: > - should we re-iterate the requirement of RFC 4474 that self-signed > certs should not be trusted unless prior key exchange has occurred? > Given the goals of speermint, should there be more guidance on the use > of self-signed certs? > - should there be a minimum set of ciphersuites to recommend or leave it > open? > > > Is this on the right track and what folks had in mind? > > Comments and input are appreciated. > Jean-Francois. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 10:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GavQr-0004Lt-6s; Fri, 20 Oct 2006 10:33:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GavQq-0004JN-1M for speermint@ietf.org; Fri, 20 Oct 2006 10:33:08 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GavQT-0001d5-24 for speermint@ietf.org; Fri, 20 Oct 2006 10:33:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GavMv-0007A9-Cx; Fri, 20 Oct 2006 09:29:06 -0500 From: "Brian Rosen" To: "'Klaus Darilion'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 10:28:59 -0400 Message-ID: <08aa01c6f454$1bb27bf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb0SqwsNcZ66EwaR+m3S/RqQ648GwAAQYLQ In-Reply-To: <4538CD5F.90009@pernau.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > If anyone wants to put information in the public (user) enum tree, they > are > > free do so. They can then peer on the Internet, surely the best IETF > > Really? In USA every telco can immediately put its numbers in e164.arpa? > I suspect this is more an authoritative problem than a technical and > probably lots of people will be happy if these problems are never solved. That's the IETF solution. User and infrastructure enum requires numbers be put in the public DNS. Some countries DO have problems with that, and there are people working on solutions. I'm not interested in workarounds other than the solutions we have now (private databases). > > and I > > don't see the point in 2 or 3 level lookup in this case; just put the > > ingress points in the federations in the main enum response and let a > peer > > 1. because there are SIP URIs - yes I want the SPEERMINT solution also > to work with If you have a SIP URI, then you have an SRV record in the domain that ALL the SIP URIs that come to you should be using. I think that is a sufficient mechanism for all federations where public data is acceptable. > > > pick one of them that it likes based on its memberships and your > > order/preference. If you have no common federations then you need to > ^^^^^^^^ > exactly, only in the case of no common federation a transit peering is > needed. If VSPs are in the same federation, they should be able to > automatically find each other and peer without the need of a central > routing database. > > > identify a route. I've never understood how you proposed to do that. > > These are probably to steps: 1. find out if I can contact the peer > directly, 2. find out a transit route if 1 does not. That is much too simplistic. You are assuming that there is a transit network that can reach EVERY TN that is not in your federation. You have to have a solution that allows a route through multiple federations, using possibly multiple transit networks between each pair of federations on the route. My proposal does just that; it aggregates route data at every step, providing reachability for direct peers of the federation as well as every indirect peer, and, by aggregation, all of THEIR indirect peers, and all of THEIR indirect peers.... You see, at the federation, ALL of the numbers you can get to, and you get, in one query, your next hop (or, if there is more than one route, your next hop choices). When you choose your next hop, then where ever you send it may (if they are a transit provider) have to do the same thing at their federation to choose their next hop. That repeats until it gets to the termination network. > > If I understand you correctly you will do both steps in a single lookup. > Thus, binding VSPs to the central routing table provider even if it is > not needed (step 1). You always have at least one query to something. I'm getting everything done with one query TN to next hop. I'm not assuming a central routing table. I'm assuming a per-federation routing table. The query, however, gets you aggregated data, either by importing indirect numbers, or (more likely) referral, so you can ask your federation if it has a route to the termination TN, and the federation can tell you if it does, even if there are 4 indirect peers in the path. > > I guess there are lots of companies which prefer doing an additional > free DNS lookup before looking up the almighty, per lookup charged, > routing database. Well, if there is one query you pay for, then I'm giving you everything in that one query. Ignoring what the charging mechanism is, if the federation has some kind of charging to terminate calls through it, then you pay the query as part of that charging mechanism. If the federation has no charge, then your one lookup is "free". You don't need any other free DNS lookups unless everything is in the DNS. That's one possible route. I just don't think we will see many TNs in the public DNS for a long time. > > > I'm dealing with reality. Reality is that the numbers ARE NOT in a > public > > Reality is also that there are forces which try to slow down user ENUM > and infrastructure ENUM development. Yeah, true. I personally think I should own my number and control the uses to which I put it. I personally LIKE user ENUM. That doesn't mean I think we will see many TNs in the public DNS tree. It's not happening for a whole lot of reasons. The question is, do we ignore the reality (think NAT), or deal with the reality? > > And once again: SPEERMINT is not about numbers - it's about peering with > SIP. Yeah, sure, but we don't need a lot of mechanism for SIP based peering, especially if the URI is in a public DNS tree anywhere. What I don't see much use for is a non-public URI resolution process. I know there are carriers who will do this (GSMA for example), but I don't see needing any more mechanism like federation resolution of private URI name spaces than we have now. You can have SRVs in a private DNS. I certainly wouldn't want to encourage it. > > > database, the peering points, or even federation membership ARE NOT in a > > public database, but all-IP connections and RFCs are used between > consenting > > peers. I'm trying to get a system that allows us to build interoperable > > implementations that gracefully scale, and work in the real world. > > Sorry, I did not knew that a central lookup database is a scaling > solution. What scales is a linear tables with billions of records. Route aggregation COULD be done that way. I suspect referral will be more palatable. Referral + caching would work quite nicely. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 11:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawDy-0005Ka-Dj; Fri, 20 Oct 2006 11:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GawDw-0005IP-Ua for speermint@ietf.org; Fri, 20 Oct 2006 11:23:53 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GawDi-0001Q5-Ui for speermint@ietf.org; Fri, 20 Oct 2006 11:23:52 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id E30551A36D; Fri, 20 Oct 2006 17:23:36 +0200 (CEST) Date: Fri, 20 Oct 2006 17:23:36 +0200 From: Otmar Lendl To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061020152336.GP19113@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , "'Michael Hammer (mhammer)'" , 'Stastny Richard' , 'Daryl Malas' , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E30211FAAE@xmb-rtp-20b.amer.cisco.com> <048f01c6f3ac$24338b00$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <048f01c6f3ac$24338b00$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'Stastny Richard' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Things start to get clearer. This mail helps. On 2006/10/19 20:10, Brian Rosen wrote: > I'm not advocating a particular solution, but, in general, I do want the > ability to determine if a particular route (=federation or transit network I > directly peer to) can get my call terminated correctly. It's quite > acceptable, and maybe optimal to just give me the info (which might be list > of VSPs, but see below). It may be acceptable to just let me query for that > (can I reach this VSP from you?). So you just want to query for the next-hop information? You write "can get my call terminated". What's the addresssing information you have for that call? Is this a number? Is this a SIP AoR? > What I don't need is the set of federations a VSP belongs to. I don't care > a whit what federations they belong to. I only want to know which of my > routes can get me to them. Ok. You only want that information if it helps you with your next-hop decision. Otherwise, I agree, you don't care. > The number of VSPs is a small number in today's technology. > > It's entirely feasible to have a single database with every TN in the world. > That is a big database, but not beyond current single database technology. > The number of VSPs is small in database terms. This is a database problem. Not all that is feasible is also desireable. You probably can build routers which would cope with a billion /32 routes. That doesn't make it a good idea to do away with route aggregation, though. Regarding the number of VSPs: As I've been trying to argue: If we want to build a system that can cope with URI-based addressing, then our baseline is the number of domains in use for email. That is not a small number. As you mention above: you sure can build database to store that amount of information. Whether it is wise to do so is a different question. After all, there is already a database out there which contains all these domains as primary keys, where the write access rights are sorted out and which is open for querying. So if our primary key is the domain name, why not use the DNS as the Database? > Let's open this up a little more. > > If some kind of public enum tree is built, whether it's user enum or > infrastructure enum in the public DNS, then we can do real two step lookups > of TN to VSP and then do some kind VSP to something lookup. Right now, I > don't see that happening much. > > What will happen is private databases (ENUM or otherwise). We can argue if > the federation runs the database. I think it will, one way or another. We > have some problems. > > One is how indirect peering TNs are handled. Either they are imported into > the database, or the query is proxied to another database. Either way, you > launch a query and you get back either a URI within the federation or you > get an error (not found). If you are a member of more than one federation, > you may launch more than one such query, and you can get back zero, one or > more than one URIs (from each query and the aggregate of all the queries). > > This means you end up doing TN to URI in one step. We then have to decide > if you get the ingress point directly, or there is another query for that; I > suspect you get the ingress point in one step. > > If you have one answer, that's where you send the call. If you have zero > answers, PSTN gateway gets the caLL. If you have more than one answer, you > are into some kind of cost metric. > > The point is that you get an answer that is the route TO the VSP, not the > federation the VSP belongs to, OR EVEN THE IDENTITY OF THE VSP. You query > by TN. You may not even be given the identity of the destination VSP. Your > query by TN only yields next hop. Brian, you're talking about routing based on telephone numbers. I'm not sure whether this is in scope for speermint. TN -> SIP translation is handled by the ENUM WG. We're charted to provide SIP interconnection. One could argue that you can do SIP calls based on tel: URIs, though I rather doubt that our current charter, terminology and requirements documents support that contention. What's rather clear to me is that we need to support calls where the caller entered a sip:user@domain URI as the target. So whatever we do, we can't *assume* that our addressing is done with TNs. I do think we need some more clarity on this basic question. For all I know, we're not the only group which is going in circles over that question. The same seems to be happening in the NGN and IMS worlds. > The only scenario where you know the VSP before you know the route is where > there is a registry independent of the federation. That just isn't really > happening except in a very few isolated places. I suppose we need to give > them some kind of solution, but I don't care much about it, because I think > it's not going to be common. Infrastructure ENUM is one aproach. To really be useful, I-ENUM needs a speermint solution as to define how to handle and route based on the URIs retrieved from I-ENUM. For I-ENUM to get market traction, speermint needs to deliver. And vice versa. Anyway, that's how I see the problem space. Once again, it boils down to the fact that we haven't really agreed on a clearly defined set of requirements. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 12:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxBX-0005kg-PV; Fri, 20 Oct 2006 12:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxBX-0005kY-3F for speermint@ietf.org; Fri, 20 Oct 2006 12:25:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaxBW-0004Hs-3x for speermint@ietf.org; Fri, 20 Oct 2006 12:25:27 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2006 09:25:26 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KGPPbI003912; Fri, 20 Oct 2006 09:25:25 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9KGOwOr012399; Fri, 20 Oct 2006 09:25:20 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 12:25:03 -0400 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] Basic Peering Requirements Date: Fri, 20 Oct 2006 12:25:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218BC87@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIAACD+nQAAFdrnAAAcThcAAqwZRg From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 20 Oct 2006 16:25:03.0468 (UTC) FILETIME=[4BF1C2C0:01C6F464] DKIM-Signature: a=rsa-sha1; q=dns; l=17302; t=1161361525; x=1162225525; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=hnHwuQuwOk38Y9W5vkba0MdS6KN0/H2UQayEOH31AzHjSNJ1zTmc2ZqbYoAlcSoc9p8nDDPX 0gFfTrhv8XhYNhckuNN7GUv51rIjhZQTAmlSXU1IRc6EJlgkeAbuBFTw; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, I see a fundamental point of disagreement that runs through all your comments: You are focused on routing toward TNs. I am focused on routing towards domains, where the domain is the key to finding the route to it. PSTN is about routing toward E.164 TNs. =20 Speermint is about routing toward domains. More inline... (Then I let it stew a bit.) > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Thursday, October 19, 2006 7:39 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar=20 > Lendl'; 'Daryl Malas' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Wow, lots to disagree with ;) >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Thursday, October 19, 2006 3:21 PM > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Inline. > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, October 19, 2006 2:27 PM > > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl';=20 > > > 'Daryl Malas' > > > Cc: speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > I'm not advocating a particular solution, but, in=20 > general, I do want=20 > > > the ability to determine if a particular route (=3Dfederation or=20 > > > transit network I directly peer to) can get my call terminated=20 > > > correctly. > >=20 > > This seems like chicken and egg problem. Were did your=20 > route come from? > You ask the sources you have (the federations or the transit=20 > networks) if they can terminate your call. You don't care=20 > HOW they do it. I think the idea of scanning the routing database of all potential partners will be resource intensive and in many cases a waste of effort. If you wait to do it at call setup, it may not be efficient. > > I think we both want to know that sending the next=20 > signaling message=20 > > will result in a call setup. > Agree, of course > >=20 > > > It's quite acceptable, and > > > maybe optimal to just give me the info (which might be=20 > list of VSPs,=20 > > > but see below). It may be acceptable to just let me=20 > query for that=20 > > > (can I reach this VSP from you?). > >=20 > > Not sure what you mean by info. What type of query are we talking=20 > > about? > One way to do this is to provide a query to the federation:=20 > can you terminate a call to this VSP? As I discuss below, I=20 > don't think you really do this, because I think you don't=20 > have a TN to VSP database, but if you did, then a query to=20 > the federation by VSP with a yes/no answer is a satisfactory solution. >=20 > Another is just a list (of VSPs reachable from this=20 > federation); it doesn't change very often. You can arrange=20 > your own query mechanism. You know have a stale caching problem. =20 > Another is an announcement. That really is a routing=20 > protocol, and I don't think we need that, at least yet. Agree, I don't want a protocol to spam the network with. =20 > > What does the query get you? Are you talking a trial an=20 > error approach? > Well, sort of. You may have more than one federation=20 > membership. Since I don't see a God Box who could tell you=20 > which federation YOU BELONG TO can get you to the=20 > destination, you have to ask them all and, if more than one=20 > says yes, you have to have a way to decide which one. For=20 > the moment, I'm ignoring the how you decide. It's "trial and=20 > error" in the sense that you ask each federation, and get an=20 > answer from each, some of which may be error reports ("you=20 > can't get there from here via me") You only need to know the targets federation and your own configured federation to do a simple comparison. If there is no match, you can send to a Transit VSP that could be derived from a couple simple DNS lookups. =20 > > > What I don't need is the set of federations a VSP belongs to. > > > I don't care a whit what federations they belong to. I=20 > only want=20 > > > to know which of my routes can get me to them. > >=20 > > The federation is only a mechanism for finding a route. You are=20 > > positing the existence of a route in advance. In other words, you=20 > > seem to be assuming a solution and then some test to verify=20 > that it works. > No, I'm assuming the federation can tell me next hop, and=20 > that's all it can tell me. That's more or less the way all=20 > routing works. It's more like you try all paths and see how=20 > many lead to your destination, but in this case you only get=20 > the next hop. But, like all routing problems, you may have=20 > zero, one, or more than one next hop choices that are valid. =20 > Whether you have in your possession all the routing data, or=20 > you query for it, or you query and cache for it, the result=20 > is the same: you ask every federation if they can route your=20 > call, and select one. But, I don't want to query a lot of federations hoping for a hit. I want each successive lookup to result in definitive answers leading to a known next hop. > >=20 > > > The number of VSPs is a small number in today's technology. > >=20 > > What do you mean by VSP? I am assuming any organization=20 > that operates=20 > > a voice service and serves endpoints, which would include IP-PBX of=20 > > enterprises. If you aren't counting them, then you have=20 > underestimated. > Well, one of the reasons I say it's a TN based query is that=20 > I don't really care how many VSPs there are. I further posit=20 > that some federations will deliberately obscure what happens=20 > behind their curtain; they won't tell you WHO they peer with=20 > directly, they will only give you the aggregate data. >=20 > So, I don't care if it's 100, 1000, a million, or tens of=20 > millions. I'd rather it be billions (one per TN). Works for me :) > >=20 > > > It's entirely feasible to have a single database with every TN in=20 > > > the world. > > > That is a big database, but not beyond current single database=20 > > > technology. > > > The number of VSPs is small in database terms. This is a=20 > database=20 > > > problem. > > > > > > Let's open this up a little more. > > > > > > If some kind of public enum tree is built, whether it's=20 > user enum or=20 > > > infrastructure enum in the public DNS, then we can do=20 > real two step=20 > > > lookups of TN to VSP and then do some kind VSP to=20 > something lookup. =20 > > > Right now, I don't see that happening much. > >=20 > > Just having the VSP is unsufficient; that doesn't gurantee=20 > they will=20 > > accept your call. > Yes, I agree with that. Presumably if a federation=20 > advertises reachability to a VSP, then the VSP will accept=20 > your call via that federation, however it is done. So, if=20 > you knew the VSP, you can ask the federations if they can=20 > route to that VSP and if they say yes, then that's a valid route. > Similarly, you do know the TN, so you ask your federation(s)=20 > if they can route your TN and if they say yes, then that's=20 > your valid next hop route. > >=20 > > > What will happen is private databases (ENUM or otherwise). > > > We can argue if the federation runs the database. I=20 > think it will,=20 > > > one way or another. We have some problems. > > > > > > One is how indirect peering TNs are handled. Either they are=20 > > > imported into the database, or the query is proxied to another=20 > > > database. Either way, you launch a query and you get=20 > back either a=20 > > > URI within the federation or you get an error (not=20 > found). If you=20 > > > are a member of more than one federation, you may launch=20 > more than=20 > > > one such query, and you can get back zero, one or more=20 > than one URIs=20 > > > (from each query and the aggregate of all the queries). > >=20 > > If the caller must go through a Transit VSP which runs its own=20 > > federation, then the TN lookup can point to the Transit VSP=20 > directly,=20 > > as well as identify the federation(s). > Sure, as you say below, and I agree with your contention that=20 > a transit network looks like a federation of 2. And I agree=20 > that if you query that transit network's registry, you should=20 > see all the TNs it can get you to. > Why you care what federations it is using to terminate your=20 > traffic, or why you think it will TELL you what federations=20 > it is using is beyond me. Go back to the idea that a federation identity is short-hand for identifying whether you can both communicate by the same rules. You need to know this one way or the other, or you are just making random calls that will likely fail because you aren't following the rules. > >The access to the private database > > that gets from the Transit VSP to the terminating VSP can=20 > be private. > Hmm, well somehow, the transit network has to tell you that=20 > it CAN terminate your call. I agree it doesn't have to tell=20 > you how it does that. If the query is, as I posit, by TN,=20 > then it has to give you access to some mechanism that will=20 > tell you if it can terminate your call which you query by TN.=20 > I think that is a registry. =20 Again, route to domains not TNs. =20 The "somehow" and "some mechanism" is what I am calling a federation. When you know you share a federation with the next hop, you know the rules to follow. > What you as originating network=20 > see is the aggregated information from the transit network's=20 > downstream arrangements. You get to see something that lets=20 > you figure out if this transit network can terminate your=20 > call. All of the URIs you would get back from a query would=20 > be URIs in the transit network's domain (federation of 2,=20 > right?). Now, HE has access to some other registries that=20 > contain different > data: how he routes the call once you give it to him. You=20 > don't get to see them. You see a registry that (one way or=20 > another) is an aggregation of all of the downstream registries. >=20 > > The problem has now morphed into how does the caller get to that=20 > > Transit VSP? Does the calling VSP have a peering relationship=20 > > directly, or must it go indirectly through yet another Transit VSP? > Ah, yes, that is the point. Your transit network may be a=20 > peer in a federation. Another peer in that federation may=20 > itself be a transit network to yet another federation. Your=20 > transit network doesn't know how one of the peers of its=20 > federation gets to the other federation, and it doesn't care. > It doesn't even know there is another transit network; all it=20 > knows is that the registry its connected to can terminate the=20 > call. The federation your transit network belongs to=20 > provides it with a registry of all of the TNs it can reach. =20 > That is in turn reflected to you via your transit provider,=20 > along with the TNs it can reach through any other=20 > arrangements it has (perhaps it is a member of several federations). >=20 > Again, this is really like route advertisements moving up the=20 > chain. You don't get in those advertisements the=20 > intermediate connections, you only get your next hop route,=20 > expressed as reachability by one of your peers. >=20 > >=20 > > Don't get hung up on the term federation, it is just a=20 > generalization=20 > > of the bilateral peering arrangement. That is, bilateral=20 > peering is=20 > > just the smallest federation possible; membership=3D2. > YES! as above >=20 > >=20 > > > This means you end up doing TN to URI in one step. We=20 > then have to=20 > > > decide if you get the ingress point directly, or there is another=20 > > > query for that; I suspect you get the ingress point in one step. > >=20 > > No disagreement here. Saying that I can go from the=20 > originating VSP=20 > > to the terminating VSP directly, means that there is a=20 > direct peering=20 > > arrangement. Saying that they both belong to the same=20 > federation is=20 > > saying exactly the same thing. The more interesting question is=20 > > determining when you don't have a direct peering=20 > relationship (i.e. no=20 > > common federation) what to do. > Well, there is no common federation between the originating=20 > carrier and the terminating carrier, and there is that=20 > circumstance (no common federation), but there is a route,=20 > via at least one of your federations, due to indirect peering=20 > relationships it has. Of course there is also the case of no=20 > route at all, meaning even with all the indirect=20 > relationships for all of your federation memberships taken=20 > into account, you still can't get the call routed to the=20 > destination VSP > >=20 > > > If you have one answer, that's where you send the call. =20 > If you have=20 > > > zero answers, PSTN gateway gets the caLL. > >=20 > > No, no, no! The goal of this exercise is to avoid the=20 > PSTN. The only=20 > > reason the PSTN should be used is when the TN is terminated=20 > to a TDM=20 > > switch and not reachable by IP. You are identifying a gap in your=20 > > approach, if a TN is a SIP phone terminated on a VSP and=20 > you end up on=20 > > the PSTN. > Well, it would be very nice if we had some way to guarantee=20 > that there always is an IP route, but so far, I don't see=20 > that happening any time soon. > If we all converge on a small set of federations, and those=20 > federations are all interconnected by some kind of indirect=20 > peering, so that from anywhere there is a path to anywhere=20 > else, then what you are looking for may happen. > Right now, that isn't in anyone's horizon, even if they would=20 > like it to be true. There is still way too much jockeying=20 > for position to get universal connectivity. >=20 > Now if we gave up on federations, and just used the Internet,=20 > why all of those problems disappear. I am trying to use the Internet, by routing to domains, but you keep focusing on routing to TNs. But, the Internet alone is not sufficient. We need to know that we can connect to those domains via well-defined rules. Otherwise, we end up with no accountability and SPIT. > >=20 > > > If you > > > have more than one answer, you are into some kind of cost metric. > > > > > > The point is that you get an answer that is the route TO the VSP,=20 > > > not the federation the VSP belongs to, OR EVEN THE=20 > IDENTITY OF THE=20 > > > VSP. > >=20 > > What is the means by which you identify the "route"? > You ask each of your federations if they can terminate your=20 > call. Any of them who answer yes is a candidate route. Then=20 > you need a metric to choose. Seems like a lot of quries with false hits. >=20 > In my world, each of those federations has a database; you=20 > query that database by TN. You get a URI (which is the next=20 > hop) or you get no record found. >=20 > >=20 > > > You query by TN. You may not even be given the identity of the=20 > > > destination VSP. Your query by TN only yields next hop. > >=20 > > The next hop could also be just a default value and defer=20 > the problem=20 > > to the originating side Transit VSP. > Not unless the transit VSP had direct or indirect peering=20 > with each and every VSP on the planet. I don't think such a=20 > thing is practical any time soon. It is practical to have all Transit VSPs interconnecting with each other. That was the idea behind having a Transit-oriented Federation. > >=20 > > The Transit VSP routing table could also list thousands of VSPs=20 > > associated with a route. But, if those groups of thousands were=20 > > associated with respective federations, then your table=20 > could be much=20 > > smaller if each thousand were replaced with a single=20 > federation:route=20 > > entry. Could the INVITE then be: > >=20 > > SIP: Target URI > > Route:Transit VSP > > Route:Federation URN? > Well, as I said way earlier, there is this idea some=20 > relatively small number of SPEERMINT participants think will=20 > happen where you can query the public DNS by TN for VSP, and=20 > then you need something that tells you route by VSP. > I don't think that is going to happen. I think you query a=20 > private federation run database by TN, and you get next hop=20 > directly; you don't know who the termination VSP is. The=20 > result of the query becomes your Request URI and there is no=20 > Route header. > >=20 > > > The only scenario where you know the VSP before you know=20 > the route=20 > > > is where there is a registry independent of the federation. > >=20 > > I would call that registry the DNS. I think you are=20 > putting the cart=20 > > before the horse. Find the destination peer, then the route to get=20 > > there. > Yeah, I would call that registry the DNS too. That isn't happening. >=20 > Brian Just wait and see! :) Mike _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 12:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxOP-0000Q1-05; Fri, 20 Oct 2006 12:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxOO-0000Pk-8j for speermint@ietf.org; Fri, 20 Oct 2006 12:38:44 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaxOM-0006hG-Qn for speermint@ietf.org; Fri, 20 Oct 2006 12:38:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaxO0-00044q-Pj; Fri, 20 Oct 2006 11:38:21 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 12:38:21 -0400 Message-ID: <001201c6f466$2abf75f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDng In-Reply-To: <20061020152336.GP19113@nic.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: 'Stastny Richard' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > So you just want to query for the next-hop information? Yes > > You write "can get my call terminated". What's the addresssing > information you have for that call? Is this a number? Is this a SIP AoR? Well, as you note, it's complex. I think 99% of the problem is addressing with TNs, and less than 1% is sip based. Because I think that is the reality, I want an efficient solution for TN based addressing, and then I'll back fit a SIP URI solution to it. What I'd like is that the sip uri route resolve to straight DNS resolution, but the possible existence of multiple paths because of complex peering relationships makes a DNS based solution impossible. DNS gets you ONE authoritative answer, and we need more than one. I think what I'm proposing for TNs works for SIP uris. I really don't want to go there, because it DOES duplicate DNS in some ways, but we have to. So I'll give you the straight answer: it's the same. You take the URI, you ask the federation if it has a route to that URI, and it gives you a next hop URI to use if it does. But, as I said, that is less than 1% of the problem, so I look to make sure it works with TNs ..snip... > Not all that is feasible is also desireable. > > You probably can build routers which would cope with a billion /32 routes. > That doesn't make it a good idea to do away with route aggregation, > though. Right, but we have a different, and more unwieldy problem. With number portability, there is very little aggregation you can do on the actual route. So far, no two countries have permitted number portability across country boundaries, but you can't aggregate routes by prefixes for TNs. Fortunately, the routing we have to do has less dynamics. It's NOT static, but it doesn't change as often as the IP routing data does. We also don't have the same performance requirements. We don't have to keep all the routes in memory, we can keep them in databases. > > Regarding the number of VSPs: As I've been trying to argue: If we want > to build a system that can cope with URI-based addressing, then our > baseline is the number of domains in use for email. That is not a small > number. As you mention above: you sure can build database to store > that amount of information. Whether it is wise to do so is a different > question. After all, there is already a database out there which > contains all these domains as primary keys, where the write access > rights are sorted out and which is open for querying. Sure, if it's public. But if you need federations, it isn't. This is the problem we have with you guys. Somehow you think that it's acceptable for there to be some private data and some public data. I don't think it works that way. The organizations who won't peer on the Internet want ALL of their data private, not just some of it. I do want the mechanisms to work with all public data. I just don't see them being used for a long time. I'm not interested in solving problems where some of it is public and some of it is private, I think there is never any use for that. > > So if our primary key is the domain name, why not use the DNS as the > Database? Primarily, as I said above, more than one route doesn't map to DNS resolution. > > The point is that you get an answer that is the route TO the VSP, not > the > > federation the VSP belongs to, OR EVEN THE IDENTITY OF THE VSP. You > query > > by TN. You may not even be given the identity of the destination VSP. > Your > > query by TN only yields next hop. > > Brian, you're talking about routing based on telephone numbers. I'm not > sure whether this is in scope for speermint. TN -> SIP translation is > handled by the ENUM WG. We're charted to provide SIP interconnection. Yeah, I understand my problem. Sometimes dealing with reality is hard. We may have to refer some work to ENUM, or change the charter. > > One could argue that you can do SIP calls based on tel: URIs, though > I rather doubt that our current charter, terminology and requirements > documents support that contention. > > What's rather clear to me is that we need to support calls where > the caller entered a sip:user@domain URI as the target. So whatever > we do, we can't *assume* that our addressing is done with TNs. As above, I agree, but don't think that is the real driver for addressing solutions. Note of course that addressing is but one part of peering. > > The only scenario where you know the VSP before you know the route is > where > > there is a registry independent of the federation. That just isn't > really > > happening except in a very few isolated places. I suppose we need to > give > > them some kind of solution, but I don't care much about it, because I > think > > it's not going to be common. > > Infrastructure ENUM is one aproach. To really be useful, I-ENUM needs > a speermint solution as to define how to handle and route based on > the URIs retrieved from I-ENUM. Again, I-ENUM, because it's based on a public tree, is a non starter for the vast majority of carriers today. I don't think that it makes any sense to force carriers to do TN to domain, and then domain to next hop, when the actual databases could easily give you TN to next hop. Since we do have to route directly by domain, you could do this, I just think we should combine them. That's an optimization, but it's a useful one. The documents could describe it as two steps and then permit the combination if someone wanted that. Note that the direct query really could be (private) ENUM. You query with TN, you get a set of NAPTRs that resolve to your route choices, you then use normal SIP DNS/SRV mechanisms to get to the IP address where you send the call. We could make an equivalent DDDS application for the domain based route. > > For I-ENUM to get market traction, speermint needs to deliver. I don't think the problems of I-ENUM have anything to do with SPEERMINT, they are only the issues of putting numbers in the public DNS. > > And vice versa. That is definitely wrong. Most of the federations use private enum or equivalent. > > Anyway, that's how I see the problem space. > > Once again, it boils down to the fact that we haven't really agreed on a > clearly defined set of requirements. Agree Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 13:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaxof-0001cg-Vl; Fri, 20 Oct 2006 13:05:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaxoe-0001cN-H4 for speermint@ietf.org; Fri, 20 Oct 2006 13:05:52 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gaxoa-0003Cc-2c for speermint@ietf.org; Fri, 20 Oct 2006 13:05:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 19:04:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BB2@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4= References: <001201c6f466$2abf75f0$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >> Infrastructure ENUM is one aproach. To really be useful, I-ENUM needs >> a speermint solution as to define how to handle and route based on >> the URIs retrieved from I-ENUM. >Again, I-ENUM, because it's based on a public tree, is a non starter = for the >vast majority of carriers today.=20 >I don't think that it makes any sense to force carriers to do TN to = domain, >and then domain to next hop, when the actual databases could easily = give you >TN to next hop. =20 =20 So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs (e.g. = http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=3Dpdf&n= s_url=3D[http://www.gsmworld.com/documents/ireg/ir67.pdf] =20 =20 >Since we do have to route directly by domain, you could do >this, I just think we should combine them. That's an optimization, but = it's >a useful one. The documents could describe it as two steps and then = permit >the combination if someone wanted that. >Note that the direct query really could be (private) ENUM. You query = with >TN, you get a set of NAPTRs that resolve to your route choices, you = then use >normal SIP DNS/SRV mechanisms to get to the IP address where you send = the >call. We could make an equivalent DDDS application for the domain = based >route.=20 And they basically use within their federation RFC3761 and RFC3263 for = routing, and the next hop is the destination, so no need for speermint at all. But they now detect that they also have to interconnect to others and = global interconnection can only be in the long range in the global DNS. So = sometimes they have to come out of their private playgrounds Richard > > For I-ENUM to get market traction, speermint needs to deliver. I don't think the problems of I-ENUM have anything to do with SPEERMINT, they are only the issues of putting numbers in the public DNS. > > And vice versa. That is definitely wrong. Most of the federations use private enum or equivalent. > > Anyway, that's how I see the problem space. > > Once again, it boils down to the fact that we haven't really agreed on = a > clearly defined set of requirements. Agree Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 13:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GayMU-0007zW-Lg; Fri, 20 Oct 2006 13:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GayMT-0007yj-EX for speermint@ietf.org; Fri, 20 Oct 2006 13:40:49 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GayMQ-0002qc-OX for speermint@ietf.org; Fri, 20 Oct 2006 13:40:49 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GayM5-0003KO-8d; Fri, 20 Oct 2006 12:40:25 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Otmar Lendl'" , "'Daryl Malas'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 13:40:27 -0400 Message-ID: <002f01c6f46e$d709c740$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIAACD+nQAAFdrnAAAcThcAAqwZRgAAG/ptA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218BC87@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is fun, I think :) The fundamental disagreement seems to be in assumptions on route complexity. You think it's possible to build a max three hop system: origination to o-transit via o-federation, to t-transit via x-federation, to termination via t-federation. You think all transit networks IN THE GLOBE will agree to federate with each other (x-federation). I find that preposterous. I think routes will be much more complex in international routing, involving several more hops and lots of route choices. I'm not even sure that 3 hops will work for domestic cases, although I hope they will most of the time. The other disagreement is you think carriers will permit SOME, but not all, of their routing data to be public. I do not agree, I think it will all be private. I'm not happy about that, but I think that is reality. It's certainly the case for all the existing federations. > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, October 20, 2006 12:25 PM > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Brian, > > I see a fundamental point of disagreement that runs through all your > comments: > > You are focused on routing toward TNs. > I am focused on routing towards domains, where the domain is the key to > finding the route to it. > > PSTN is about routing toward E.164 TNs. > Speermint is about routing toward domains. See my prior note to Otmar. I'm all for peering on the Internet. It works really quite well. The problem is, carriers don't want to do that. I agree that we need to route towards domains if you start with a domain. I think 99% of the problem is routing towards TNs. As I said to Otmar, we can use the same solution for both, but I really want to optimize TN to domain, domain to next hop to TN to next hop. > > More inline... (Then I let it stew a bit.) > > > You ask the sources you have (the federations or the transit > > networks) if they can terminate your call. You don't care > > HOW they do it. > > I think the idea of scanning the routing database of all potential > partners will be resource intensive and in many cases a waste of effort. > If you wait to do it at call setup, it may not be efficient. I think you are stuck with this. You can cache the data, but the reality is that since it changes, you need to do the queries at call time. The biggest part of this problem is TN to domain. Because of number portability, caching is of limited usefulness. The fact that you could cache the domain to route doesn't help you if, as I propose, that's one query. If you can actually aggregate TN to domain into one database, it would be a big, but readily implementable database, and you would get the answer in one query. I don't think that will happen. You will need referral. That is where the time will come. I think referral can be made fast enough for the problem at hand. The real issue is how complex the transit network arrangements become. I believe that the simple cases will be simple - likely one or two transit networks to two or three federations (think something like cable MSO to cable federation, transit to ILEC federation, transit to CLEC). We have to make things more complex work (same as above to ILEC federation, but more than one choice of international transit to more than one choice of international federation to termination network). On the other hand, I don't think it's very hard to do this. If we can really have the tail drop really low after 3 federations (2 referrals), then likely we can make that be plenty fast enough. > > Another is just a list (of VSPs reachable from this > > federation); it doesn't change very often. You can arrange > > your own query mechanism. > > You know have a stale caching problem. Nah, you put TTL on the query and refresh when you need to. They don't change often, and the changes are planned. A larger problem is the TNs. You may have multiple routes to TNs, and when they change, you could have a stale route. You can't preplan those changes in time frame less than minutes. We need a solution for that. ..snip... > > Well, sort of. You may have more than one federation > > membership. Since I don't see a God Box who could tell you > > which federation YOU BELONG TO can get you to the > > destination, you have to ask them all and, if more than one > > says yes, you have to have a way to decide which one. For > > the moment, I'm ignoring the how you decide. It's "trial and > > error" in the sense that you ask each federation, and get an > > answer from each, some of which may be error reports ("you > > can't get there from here via me") > > You only need to know the targets federation and your own configured > federation to do a simple comparison. If there is no match, you can > send to a Transit VSP that could be derived from a couple simple DNS > lookups. You and Otmar/Klaus keep thinking that all transit networks will provide transit to every TN on the planet. Not feasible. You have a complex network diagram, and you have to figure your way through the network. Feed forward reachability works. Lookups don't work because the thing you are looking up doesn't have the network map. If there are 3 federations and two transit networks between me and the termination VSP, what series of lookups do you do, and how are you coping with more than one route in any link? That is the likely path for an international call. ...snip... > > No, I'm assuming the federation can tell me next hop, and > > that's all it can tell me. That's more or less the way all > > routing works. It's more like you try all paths and see how > > many lead to your destination, but in this case you only get > > the next hop. But, like all routing problems, you may have > > zero, one, or more than one next hop choices that are valid. > > Whether you have in your possession all the routing data, or > > you query for it, or you query and cache for it, the result > > is the same: you ask every federation if they can route your > > call, and select one. > > But, I don't want to query a lot of federations hoping for a hit. I > want each successive lookup to result in definitive answers leading to a > known next hop. You can't ever get that. If you are a part of more than one federation then you have to ask all of them if they can get you to the destination. You can aggregate data they give you, preplan routes, and make the answer be a one step lookup, but that would be something you do internally IFF the federation gives you the data. In general, in my world, they don't; you don't get a full list of peers, ESPECIALLY INDIRECT PEERS. You can query for a route, and get an answer. ...snip... > > Sure, as you say below, and I agree with your contention that > > a transit network looks like a federation of 2. And I agree > > that if you query that transit network's registry, you should > > see all the TNs it can get you to. > > Why you care what federations it is using to terminate your > > traffic, or why you think it will TELL you what federations > > it is using is beyond me. > > Go back to the idea that a federation identity is short-hand for > identifying whether you can both communicate by the same rules. You > need to know this one way or the other, or you are just making random > calls that will likely fail because you aren't following the rules. Sure, but in this case it's you and the transit network agreeing on rules. That DOES NOT mean that it has the same rules with each federation it connects to, and DOES NOT mean it tells you HOW it routes your calls. It only tells you that if you give it that call, it can, and will, route it according to the rules it has agreed with you. You may have more than one choice, each of which has a rule set. Any of those networks may have more than one route. > > > > >The access to the private database > > > that gets from the Transit VSP to the terminating VSP can > > be private. > > Hmm, well somehow, the transit network has to tell you that > > it CAN terminate your call. I agree it doesn't have to tell > > you how it does that. If the query is, as I posit, by TN, > > then it has to give you access to some mechanism that will > > tell you if it can terminate your call which you query by TN. > > I think that is a registry. > > Again, route to domains not TNs. > > The "somehow" and "some mechanism" is what I am calling a federation. > When you know you share a federation with the next hop, you know the > rules to follow. I'm working on how you know that the federation has any route to the destination, and if it does, what the Request URI should be for next hop. AFTER that, then I "know I share a federation with the next hop". Before I do, I don't really care what the rules are. ..snip... > > If we all converge on a small set of federations, and those > > federations are all interconnected by some kind of indirect > > peering, so that from anywhere there is a path to anywhere > > else, then what you are looking for may happen. > > Right now, that isn't in anyone's horizon, even if they would > > like it to be true. There is still way too much jockeying > > for position to get universal connectivity. > > > > Now if we gave up on federations, and just used the Internet, > > why all of those problems disappear. > > I am trying to use the Internet, by routing to domains, but you keep > focusing on routing to TNs. But, the Internet alone is not sufficient. > We need to know that we can connect to those domains via well-defined > rules. Otherwise, we end up with no accountability and SPIT. Federations don't exist for that purpose. Federations exist because carriers refuse to peer on the Internet for revenue, QoS and control issues. You don't need the kind of federations we are talking about for identity, although it helps, and identity is the key to accountability and SPIT. Eventually, we WILL route on the Internet, but then it will be simple DNS domain resolution. We won't need federations. Federations don't want to use the Internet to route. They do that privately. None of the routing data is allowed to be public. There are very, very few carriers who are willing to put ANY form of routing data in the public DNS. > > > What is the means by which you identify the "route"? > > You ask each of your federations if they can terminate your > > call. Any of them who answer yes is a candidate route. Then > > you need a metric to choose. > > Seems like a lot of quries with false hits. Well, it depends on exactly how you get the routing data. True if the federation doesn't give you the entire database for your internal use. If it does, you can do your own aggregation and make a single query to your own database and get the answer in one query. In reality, you probably don't get that, especially for indirect peers, and you have to launch actual queries to each federation, and they may have to refer the query to their indirect connections if they don't get a match. "Getting the entire database" is the route advertisement approach. I don't think we want to go there yet. It works, and it's efficient, but it gets complex quick. Query and referral works (somewhat like DNS, but you don't have hierarchy to help your caching resolver) ...snip... > It is practical to have all Transit VSPs interconnecting with each > other. That was the idea behind having a Transit-oriented Federation. I think this is laughably wrong. You are positing that there are a set of transit carriers who will ALL agree to peer with ALL other transit networks in the world. You are re-inventing the U.S. IXC scheme. Who would agree to such a thing? Think international. My gosh, just think how you would do that in the U.S.? Do you seriously think there is ANY transit carrier who could wangle transit from ALL federations? Not a chance. That would take regulation. It doesn't happen on the Internet. I think there are a set of carriers who THINK they can do this. I wouldn't want to build a system that would fail if it happened. I just think it's not possible to ASSUME such a thing globally. I think the interconnects will be much more complex. > > > > > > > The Transit VSP routing table could also list thousands of VSPs > > > associated with a route. But, if those groups of thousands were > > > associated with respective federations, then your table > > could be much > > > smaller if each thousand were replaced with a single > > federation:route > > > entry. Could the INVITE then be: > > > > > > SIP: Target URI > > > Route:Transit VSP > > > Route:Federation URN? > > Well, as I said way earlier, there is this idea some > > relatively small number of SPEERMINT participants think will > > happen where you can query the public DNS by TN for VSP, and > > then you need something that tells you route by VSP. > > I don't think that is going to happen. I think you query a > > private federation run database by TN, and you get next hop > > directly; you don't know who the termination VSP is. The > > result of the query becomes your Request URI and there is no > > Route header. > > > > > > > The only scenario where you know the VSP before you know > > the route > > > > is where there is a registry independent of the federation. > > > > > > I would call that registry the DNS. I think you are > > putting the cart > > > before the horse. Find the destination peer, then the route to get > > > there. > > Yeah, I would call that registry the DNS too. That isn't happening. > > > > Brian > > Just wait and see! :) > > Mike _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 13:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaydr-0004yZ-T8; Fri, 20 Oct 2006 13:58:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaydq-0004yN-3t for speermint@ietf.org; Fri, 20 Oct 2006 13:58:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaydo-0006Kr-Eo for speermint@ietf.org; Fri, 20 Oct 2006 13:58:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2006 10:58:44 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KHwibF000357; Fri, 20 Oct 2006 13:58:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9KHwhYJ012071; Fri, 20 Oct 2006 13:58:43 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 13:58:43 -0400 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] Basic Peering Requirements Date: Fri, 20 Oct 2006 13:58:46 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218BCEC@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: AcbyvN7wXpMtxi0cRi2++z4lnQfp7gAAXcrjAAUhbPAAAnYwwAArpT5QAAOXyiAAAX8RIAACD+nQAAFdrnAAAcThcAAqwZRgAAG/ptAAAkyUMA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" , "Daryl Malas" X-OriginalArrivalTime: 20 Oct 2006 17:58:43.0406 (UTC) FILETIME=[61B03EE0:01C6F471] DKIM-Signature: a=rsa-sha1; q=dns; l=16842; t=1161367124; x=1162231124; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Stastny=20Richard=22=20, =0A=20=20=20=20=20=20=20= 20=22Otmar=20Lendl=22=20, =20=22Daryl=20Malas=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=NAB9LX/gdW89KWEkUBwA7AAhL0yhjO25R7pD3Ymcb+qb2ZFp/QyDa6U6Ip2b9qZOUK96Yi23 mb/LHs/KtDr+bTS2EKHlk41tWKJOe5R7AzGzCbXpl71NbTRcCslgzlay; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, I am enjoying the challenging discussion. You are correct, I think that any middlemen that add no value will be disintermediated, sooner or later. =20 I think that getting any more than 2 Transit VSPs involved only means that a revenue pie gets split more ways, with each slice getting smaller and smaller. =20 It is also a good idea to have media go as directly as possible, else quality suffers. But, I think that having up to two is reasonable based on the idea that: 1) not everyone can agree to one federation/peering, 2) membership in federations/peerings will not overlap, 3) even Transit VSPs can't be members of all federations; so Transit VSPs provide a valuable service to interconnect the islands. Occum's Razor suggests that the less complex solution will be the better one. I also think that inefficient mechanisms could get bypassed if they aren't part of an efficient process. The revenue stream trajectory won't support inefficiencies. And finally, DNS worked, no? Cheers, Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, October 20, 2006 1:40 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar=20 > Lendl'; 'Daryl Malas' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > This is fun, I think :) >=20 > The fundamental disagreement seems to be in assumptions on=20 > route complexity. > You think it's possible to build a max three hop system:=20 > origination to o-transit via o-federation, to t-transit via=20 > x-federation, to termination via t-federation. You think all=20 > transit networks IN THE GLOBE will agree to federate with=20 > each other (x-federation). >=20 > I find that preposterous. I think routes will be much more=20 > complex in international routing, involving several more hops=20 > and lots of route choices. I'm not even sure that 3 hops=20 > will work for domestic cases, although I hope they will most=20 > of the time. >=20 > The other disagreement is you think carriers will permit=20 > SOME, but not all, of their routing data to be public. I do=20 > not agree, I think it will all be private. I'm not happy=20 > about that, but I think that is reality. It's certainly the=20 > case for all the existing federations. >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, October 20, 2006 12:25 PM > > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Brian, > >=20 > > I see a fundamental point of disagreement that runs through all your > > comments: > >=20 > > You are focused on routing toward TNs. > > I am focused on routing towards domains, where the domain=20 > is the key=20 > > to finding the route to it. > >=20 > > PSTN is about routing toward E.164 TNs. > > Speermint is about routing toward domains. > See my prior note to Otmar. >=20 > I'm all for peering on the Internet. It works really quite=20 > well. The problem is, carriers don't want to do that. I=20 > agree that we need to route towards domains if you start with=20 > a domain. I think 99% of the problem is routing towards TNs.=20 > As I said to Otmar, we can use the same solution for both,=20 > but I really want to optimize TN to domain, domain to next=20 > hop to TN to next hop. >=20 > >=20 > > More inline... (Then I let it stew a bit.) > >=20 > > > You ask the sources you have (the federations or the transit > > > networks) if they can terminate your call. You don't=20 > care HOW they=20 > > > do it. > >=20 > > I think the idea of scanning the routing database of all potential=20 > > partners will be resource intensive and in many cases a=20 > waste of effort. > > If you wait to do it at call setup, it may not be efficient. > I think you are stuck with this. You can cache the data, but=20 > the reality is that since it changes, you need to do the=20 > queries at call time. > The biggest part of this problem is TN to domain. Because of=20 > number portability, caching is of limited usefulness. The=20 > fact that you could cache the domain to route doesn't help=20 > you if, as I propose, that's one query. >=20 > If you can actually aggregate TN to domain into one database,=20 > it would be a big, but readily implementable database, and=20 > you would get the answer in one query. I don't think that=20 > will happen. You will need referral. That is where the time=20 > will come. I think referral can be made fast enough for the=20 > problem at hand. >=20 > The real issue is how complex the transit network=20 > arrangements become. I believe that the simple cases will be=20 > simple - likely one or two transit networks to two or three=20 > federations (think something like cable MSO to cable=20 > federation, transit to ILEC federation, transit to CLEC). We=20 > have to make things more complex work (same as above to ILEC=20 > federation, but more than one choice of international transit=20 > to more than one choice of international federation to=20 > termination network).=20 >=20 > On the other hand, I don't think it's very hard to do this. =20 > If we can really have the tail drop really low after 3=20 > federations (2 referrals), then likely we can make that be=20 > plenty fast enough. >=20 > > > Another is just a list (of VSPs reachable from this=20 > federation); it=20 > > > doesn't change very often. You can arrange your own query=20 > > > mechanism. > >=20 > > You know have a stale caching problem. > Nah, you put TTL on the query and refresh when you need to. > They don't change often, and the changes are planned. >=20 > A larger problem is the TNs. You may have multiple routes to=20 > TNs, and when they change, you could have a stale route. You=20 > can't preplan those changes in time frame less than minutes. =20 > We need a solution for that. >=20 >=20 > ..snip... > > > Well, sort of. You may have more than one federation=20 > membership. =20 > > > Since I don't see a God Box who could tell you which=20 > federation YOU=20 > > > BELONG TO can get you to the destination, you have to ask=20 > them all=20 > > > and, if more than one says yes, you have to have a way to decide=20 > > > which one. For the moment, I'm ignoring the how you=20 > decide. It's=20 > > > "trial and error" in the sense that you ask each=20 > federation, and get=20 > > > an answer from each, some of which may be error reports=20 > ("you can't=20 > > > get there from here via me") > >=20 > > You only need to know the targets federation and your own=20 > configured=20 > > federation to do a simple comparison. If there is no=20 > match, you can=20 > > send to a Transit VSP that could be derived from a couple=20 > simple DNS=20 > > lookups. > You and Otmar/Klaus keep thinking that all transit networks=20 > will provide transit to every TN on the planet. Not=20 > feasible. You have a complex network diagram, and you have=20 > to figure your way through the network. > Feed forward reachability works. Lookups don't work because=20 > the thing you are looking up doesn't have the network map. >=20 > If there are 3 federations and two transit networks between=20 > me and the termination VSP, what series of lookups do you do,=20 > and how are you coping with more than one route in any link? =20 > That is the likely path for an international call. =20 >=20 > ...snip... > > > No, I'm assuming the federation can tell me next hop, and=20 > that's all=20 > > > it can tell me. That's more or less the way all routing works. =20 > > > It's more like you try all paths and see how many lead to your=20 > > > destination, but in this case you only get the next hop. =20 > But, like=20 > > > all routing problems, you may have zero, one, or more=20 > than one next=20 > > > hop choices that are valid. > > > Whether you have in your possession all the routing data, or you=20 > > > query for it, or you query and cache for it, the result=20 > is the same:=20 > > > you ask every federation if they can route your call, and select=20 > > > one. > >=20 > > But, I don't want to query a lot of federations hoping for=20 > a hit. I=20 > > want each successive lookup to result in definitive answers=20 > leading to=20 > > a known next hop. > You can't ever get that. If you are a part of more than one=20 > federation then you have to ask all of them if they can get=20 > you to the destination. You can aggregate data they give=20 > you, preplan routes, and make the answer be a one step=20 > lookup, but that would be something you do internally IFF the=20 > federation gives you the data. In general, in my world, they=20 > don't; you don't get a full list of peers, ESPECIALLY=20 > INDIRECT PEERS. You can query for a route, and get an answer. >=20 > ...snip... > > > Sure, as you say below, and I agree with your contention that a=20 > > > transit network looks like a federation of 2. And I=20 > agree that if=20 > > > you query that transit network's registry, you should see all the=20 > > > TNs it can get you to. > > > Why you care what federations it is using to terminate=20 > your traffic,=20 > > > or why you think it will TELL you what federations it is using is=20 > > > beyond me. > >=20 > > Go back to the idea that a federation identity is short-hand for=20 > > identifying whether you can both communicate by the same=20 > rules. You=20 > > need to know this one way or the other, or you are just=20 > making random=20 > > calls that will likely fail because you aren't following the rules. > Sure, but in this case it's you and the transit network=20 > agreeing on rules. > That DOES NOT mean that it has the same rules with each=20 > federation it connects to, and DOES NOT mean it tells you HOW=20 > it routes your calls. It only tells you that if you give it=20 > that call, it can, and will, route it according to the rules=20 > it has agreed with you. >=20 > You may have more than one choice, each of which has a rule=20 > set. Any of those networks may have more than one route. >=20 > >=20 > >=20 > > > >The access to the private database > > > > that gets from the Transit VSP to the terminating VSP can > > > be private. > > > Hmm, well somehow, the transit network has to tell you=20 > that it CAN=20 > > > terminate your call. I agree it doesn't have to tell you how it=20 > > > does that. If the query is, as I posit, by TN, then it=20 > has to give=20 > > > you access to some mechanism that will tell you if it can=20 > terminate=20 > > > your call which you query by TN. > > > I think that is a registry. > >=20 > > Again, route to domains not TNs. > >=20 > > The "somehow" and "some mechanism" is what I am calling a=20 > federation. > > When you know you share a federation with the next hop, you=20 > know the=20 > > rules to follow. > I'm working on how you know that the federation has any route=20 > to the destination, and if it does, what the Request URI=20 > should be for next hop. > AFTER that, then I "know I share a federation with the next=20 > hop". Before I do, I don't really care what the rules are. >=20 > ..snip... > > > If we all converge on a small set of federations, and those=20 > > > federations are all interconnected by some kind of=20 > indirect peering,=20 > > > so that from anywhere there is a path to anywhere else, then what=20 > > > you are looking for may happen. > > > Right now, that isn't in anyone's horizon, even if they=20 > would like=20 > > > it to be true. There is still way too much jockeying for=20 > position=20 > > > to get universal connectivity. > > > > > > Now if we gave up on federations, and just used the Internet, why=20 > > > all of those problems disappear. > >=20 > > I am trying to use the Internet, by routing to domains, but=20 > you keep=20 > > focusing on routing to TNs. But, the Internet alone is not=20 > sufficient. > > We need to know that we can connect to those domains via=20 > well-defined=20 > > rules. Otherwise, we end up with no accountability and SPIT. > Federations don't exist for that purpose. Federations exist=20 > because carriers refuse to peer on the Internet for revenue,=20 > QoS and control issues. >=20 >=20 > You don't need the kind of federations we are talking about=20 > for identity, although it helps, and identity is the key to=20 > accountability and SPIT. > Eventually, we WILL route on the Internet, but then it will=20 > be simple DNS domain resolution. We won't need federations. >=20 > Federations don't want to use the Internet to route. They do=20 > that privately. None of the routing data is allowed to be=20 > public. There are very, very few carriers who are willing to=20 > put ANY form of routing data in the public DNS. >=20 >=20 > > > > What is the means by which you identify the "route"? > > > You ask each of your federations if they can terminate=20 > your call. =20 > > > Any of them who answer yes is a candidate route. Then you need a=20 > > > metric to choose. > >=20 > > Seems like a lot of quries with false hits. > Well, it depends on exactly how you get the routing data. =20 > True if the federation doesn't give you the entire database=20 > for your internal use. If it does, you can do your own=20 > aggregation and make a single query to your own database and=20 > get the answer in one query. In reality, you probably don't=20 > get that, especially for indirect peers, and you have to=20 > launch actual queries to each federation, and they may have=20 > to refer the query to their indirect connections if they=20 > don't get a match. >=20 > "Getting the entire database" is the route advertisement=20 > approach. I don't think we want to go there yet. It works,=20 > and it's efficient, but it gets complex quick. Query and=20 > referral works (somewhat like DNS, but you don't have=20 > hierarchy to help your caching resolver) >=20 > ...snip... > > It is practical to have all Transit VSPs interconnecting with each=20 > > other. That was the idea behind having a Transit-oriented=20 > Federation. > I think this is laughably wrong. You are positing that there=20 > are a set of transit carriers who will ALL agree to peer with=20 > ALL other transit networks in the world. You are=20 > re-inventing the U.S. IXC scheme. >=20 > Who would agree to such a thing? Think international. My=20 > gosh, just think how you would do that in the U.S.? Do you=20 > seriously think there is ANY transit carrier who could wangle=20 > transit from ALL federations? Not a chance. That would take=20 > regulation. >=20 > It doesn't happen on the Internet. >=20 > I think there are a set of carriers who THINK they can do=20 > this. I wouldn't want to build a system that would fail if=20 > it happened. I just think it's not possible to ASSUME such a=20 > thing globally.=20 >=20 > I think the interconnects will be much more complex. >=20 > =20 > >=20 > > > > > > > > The Transit VSP routing table could also list thousands of VSPs=20 > > > > associated with a route. But, if those groups of=20 > thousands were=20 > > > > associated with respective federations, then your table > > > could be much > > > > smaller if each thousand were replaced with a single > > > federation:route > > > > entry. Could the INVITE then be: > > > > > > > > SIP: Target URI > > > > Route:Transit VSP > > > > Route:Federation URN? > > > Well, as I said way earlier, there is this idea some relatively=20 > > > small number of SPEERMINT participants think will happen=20 > where you=20 > > > can query the public DNS by TN for VSP, and then you need=20 > something=20 > > > that tells you route by VSP. > > > I don't think that is going to happen. I think you query=20 > a private=20 > > > federation run database by TN, and you get next hop directly; you=20 > > > don't know who the termination VSP is. The result of the query=20 > > > becomes your Request URI and there is no Route header. > > > > > > > > > The only scenario where you know the VSP before you know > > > the route > > > > > is where there is a registry independent of the federation. > > > > > > > > I would call that registry the DNS. I think you are > > > putting the cart > > > > before the horse. Find the destination peer, then the route to=20 > > > > get there. > > > Yeah, I would call that registry the DNS too. That=20 > isn't happening. > > > > > > Brian > >=20 > > Just wait and see! :) > >=20 > > Mike >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 14:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaygP-0005zW-NY; Fri, 20 Oct 2006 14:01:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaygN-0005yI-Ur for speermint@ietf.org; Fri, 20 Oct 2006 14:01:23 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaygM-0006fx-Kf for speermint@ietf.org; Fri, 20 Oct 2006 14:01:23 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GayfP-000691-6k; Fri, 20 Oct 2006 13:00:23 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 14:00:23 -0400 Message-ID: <003601c6f471$a1222890$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38A== In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BB2@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs > (e.g. > http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=pdf&ns_u > rl=[http://www.gsmworld.com/documents/ireg/ir67.pdf] Maybe. As I said, it's an optimization, but a useful one. > But they now detect that they also have to interconnect to others and > global > interconnection can only be in the long range in the global DNS. So > sometimes > they have to come out of their private playgrounds Nope, no routing will be in the global DNS. The transit interconnects will be private, and the reachability data will be private. I don't LIKE that, but it's what is happening. Carriers don't put ANY route data in the public DNS. It's pretty straightforward to describe the scheme so that it works on the public DNS, I just don't think it will actually be deployed that way. Also, if you have more than one choice of path, you can't do that with a simple lookup, and if you have to do a series of lookups, making one choice from a list at every step, then you're playing my song. The problem here is a multi step route determination. We have a constellation of federations, and set of transit carriers making connections between them in non simple ways. At any point in the graph, you may have multiple choices. The problem is to find a path. It's not a simple one stage lookup, it's a path discovery. It's a ROUTING problem. We know how to solve routing problems. In this case, we don't yet need a dynamic route advertisement protocol, we can get away with simple query or query and referral. It's classical routing: you either start at the origin and look through all paths at every branch until you get to the destination, or you feed forward the aggregated route advertisements from the next hop to the leaf. The former is easy if the graph is not horribly complex. It would be better to feed forward aggregated routes. However, the TN to domain mapping is highly unlikely to work that way (not all registries will allow their data to be aggregated). If you need to support referral, then you might as well make the whole mechanism query and referral. You can cache, which helps with domains, but doesn't help with TNs. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 15:28:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb021-0003Mb-96; Fri, 20 Oct 2006 15:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb01z-00039e-AM for speermint@ietf.org; Fri, 20 Oct 2006 15:27:47 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gb01s-0005PA-Sz for speermint@ietf.org; Fri, 20 Oct 2006 15:27:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 21:26:48 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4BB3@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5r References: <003601c6f471$a1222890$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Otmar Lendl" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >I don't LIKE that, but it's what is happening. Carriers don't put ANY = route >data in the public DNS. I do not like it either. So the IETF is taken over by the carriers? We dump 20-30 years of development and start rebuilding the PSTN on IP? I do not think that this is the charter of SPEERMINT, this may be the task of 3GPP, ETSI TISPAN and ITU-T =20 I also agree with Mike here: =20 > I think that any middlemen that add no value will be >disintermediated, sooner or later. Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Fr 20.10.2006 20:00 An: Stastny Richard; 'Otmar Lendl' Cc: 'Michael Hammer (mhammer)'; speermint@ietf.org Betreff: RE: [Speermint] Basic Peering Requirements > So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs > (e.g. > = http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=3Dpdf&n= s_u > rl=3D[http://www.gsmworld.com/documents/ireg/ir67.pdf] Maybe. As I said, it's an optimization, but a useful one. > But they now detect that they also have to interconnect to others and > global > interconnection can only be in the long range in the global DNS. So > sometimes > they have to come out of their private playgrounds Nope, no routing will be in the global DNS. The transit interconnects = will be private, and the reachability data will be private. I don't LIKE that, but it's what is happening. Carriers don't put ANY = route data in the public DNS. It's pretty straightforward to describe the scheme so that it works on = the public DNS, I just don't think it will actually be deployed that way. = Also, if you have more than one choice of path, you can't do that with a = simple lookup, and if you have to do a series of lookups, making one choice = from a list at every step, then you're playing my song. The problem here is a multi step route determination. We have a constellation of federations, and set of transit carriers making = connections between them in non simple ways. At any point in the graph, you may = have multiple choices. The problem is to find a path. It's not a simple one stage lookup, it's a path discovery. It's a ROUTING problem. We know = how to solve routing problems. In this case, we don't yet need a dynamic = route advertisement protocol, we can get away with simple query or query and referral. It's classical routing: you either start at the origin and look through = all paths at every branch until you get to the destination, or you feed = forward the aggregated route advertisements from the next hop to the leaf. The former is easy if the graph is not horribly complex. It would be better = to feed forward aggregated routes. However, the TN to domain mapping is = highly unlikely to work that way (not all registries will allow their data to = be aggregated). If you need to support referral, then you might as well = make the whole mechanism query and referral. You can cache, which helps with domains, but doesn't help with TNs. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 16:17:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0nl-00067p-NT; Fri, 20 Oct 2006 16:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0nk-00066X-Eh for speermint@ietf.org; Fri, 20 Oct 2006 16:17:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb0nK-0005h8-0f for speermint@ietf.org; Fri, 20 Oct 2006 16:17:08 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2006 13:16:41 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KKGfC5011382; Fri, 20 Oct 2006 13:16:41 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9KKGKbj002477; Fri, 20 Oct 2006 13:16:41 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 16:16:30 -0400 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] Basic Peering Requirements Date: Fri, 20 Oct 2006 16:16:23 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218BDAE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAAEsqTAAAH2dwA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" X-OriginalArrivalTime: 20 Oct 2006 20:16:30.0590 (UTC) FILETIME=[A15069E0:01C6F484] DKIM-Signature: a=rsa-sha1; q=dns; l=6020; t=1161375401; x=1162239401; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=YQrxmOH20UVPeLnsxw9uU5R/0wcKoZyQ5T/vBZ8Wj13VDU07bYIcnGY/11LukUl+VfGR12d4 LCtH37MekUN8D9+gmuuY37jrcDe+Tp3eIrSEbwNjhKq3UMHAGmMxp/7Q; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, It doesn't necessarily have to ALL be public. The part about how the originating Transit VSP knows how to connect to the Transit VSP serving the terminating VSP could very well be by private peering arrangements between the Transit VSPs. This is a series of questions that should be answerable: Transit A-----X-----Y-----B Can A get to B directly? Yes/No If no, is B served by someone? Yes:Y Can A get to Y directly? Yes/No If no, is A served by someone? Yes:X Can X get to Y directly? Yes/No (Note this is where it can spiral, but SPs do a good job of taking care of the X to Y connectivity.) If yes, A sends call to X who sends to Y who sends to B. Call successful because peering relationships exist on all segments. Note also that each of those "directly" queries is simply asking if the sender has a peering relationship as identified by a name (i.e. federation identity). It is a simple question that should have a simply obtainable answer. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, October 20, 2006 3:57 PM > To: 'Stastny Richard'; 'Otmar Lendl' > Cc: Michael Hammer (mhammer); speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Then Richard, we are done. >=20 > User ENUM, DNS SRV, Internet Peering. We need nothing else. >=20 > I do believe that eventually, carriers will be=20 > disintermediated, especially at the enterprise level. >=20 > But we aren't there yet, and we have a lot of service=20 > providers who want to do this, with the private stuff.=20 >=20 > It's not heresy. The solutions WILL work on the Internet. =20 > They will also work on private IP networks. >=20 > But if a proposed solution ASSUMES a public database, then it=20 > won't work. >=20 > In this case, it also means if it assumes a single tree it=20 > won't be acceptable. Nothing that assumes a single tree=20 > where any carrier can see the whole tree will be acceptable. >=20 > There isn't going to be ONE enum tree, there are going to be=20 > many There isn't going to be ONE routing database, there are=20 > going to be many >=20 > Brian >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Friday, October 20, 2006 3:27 PM > > To: Brian Rosen; Otmar Lendl > > Cc: Michael Hammer (mhammer); speermint@ietf.org > > Subject: Re: [Speermint] Basic Peering Requirements > >=20 > > >I don't LIKE that, but it's what is happening. Carriers don't put=20 > > >ANY > > route > > >data in the public DNS. > >=20 > > I do not like it either. > > So the IETF is taken over by the carriers? > >=20 > > We dump 20-30 years of development and start rebuilding the PSTN on=20 > > IP? > >=20 > > I do not think that this is the charter of SPEERMINT, this=20 > may be the=20 > > task of 3GPP, ETSI TISPAN and ITU-T > >=20 > > I also agree with Mike here: > >=20 > > > I think that any middlemen that add no value will be=20 > > >disintermediated, sooner or later. > >=20 > > Richard > >=20 > >=20 > > ________________________________ > >=20 > > Von: Brian Rosen [mailto:br@brianrosen.net] > > Gesendet: Fr 20.10.2006 20:00 > > An: Stastny Richard; 'Otmar Lendl' > > Cc: 'Michael Hammer (mhammer)'; speermint@ietf.org > > Betreff: RE: [Speermint] Basic Peering Requirements > >=20 > >=20 > >=20 > > > So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs (e.g. > > > > >=20 > = http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=3Dpdf& > > ns_u > > > rl=3D[http://www.gsmworld.com/documents/ireg/ir67.pdf] > > Maybe. As I said, it's an optimization, but a useful one. > >=20 > > > But they now detect that they also have to interconnect to others=20 > > > and global interconnection can only be in the long range in the=20 > > > global DNS. So sometimes they have to come out of their private=20 > > > playgrounds > > Nope, no routing will be in the global DNS. The transit=20 > interconnects=20 > > will be private, and the reachability data will be private. > >=20 > > I don't LIKE that, but it's what is happening. Carriers=20 > don't put ANY=20 > > route data in the public DNS. > >=20 > > It's pretty straightforward to describe the scheme so that=20 > it works on=20 > > the public DNS, I just don't think it will actually be=20 > deployed that way. > > Also, > > if you have more than one choice of path, you can't do that with a=20 > > simple lookup, and if you have to do a series of lookups,=20 > making one=20 > > choice from a list at every step, then you're playing my song. > >=20 > > The problem here is a multi step route determination. We have a=20 > > constellation of federations, and set of transit carriers making=20 > > connections between them in non simple ways. At any point in the=20 > > graph, you may have multiple choices. The problem is to=20 > find a path. =20 > > It's not a simple one stage lookup, it's a path discovery. It's a=20 > > ROUTING problem. We know how to solve routing problems. In this=20 > > case, we don't yet need a dynamic route advertisement=20 > protocol, we can=20 > > get away with simple query or query and referral. > >=20 > > It's classical routing: you either start at the origin and look=20 > > through all paths at every branch until you get to the=20 > destination, or=20 > > you feed forward the aggregated route advertisements from=20 > the next hop=20 > > to the leaf. The former is easy if the graph is not=20 > horribly complex. =20 > > It would be better to feed forward aggregated routes. =20 > However, the TN=20 > > to domain mapping is highly unlikely to work that way (not all=20 > > registries will allow their data to be aggregated). If you need to=20 > > support referral, then you might as well make the whole mechanism=20 > > query and referral. You can cache, which helps with domains, but=20 > > doesn't help with TNs. > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 16:26:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0wK-0001zV-VU; Fri, 20 Oct 2006 16:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0VX-0002NQ-Pp for speermint@ietf.org; Fri, 20 Oct 2006 15:58:21 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb0V3-0002Sr-BY for speermint@ietf.org; Fri, 20 Oct 2006 15:58:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gb0Uc-0007iQ-2m; Fri, 20 Oct 2006 14:57:22 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 15:57:26 -0400 Message-ID: <005601c6f481$f937f3b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAAEsqTA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BB3@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Then Richard, we are done. User ENUM, DNS SRV, Internet Peering. We need nothing else. I do believe that eventually, carriers will be disintermediated, especially at the enterprise level. But we aren't there yet, and we have a lot of service providers who want to do this, with the private stuff. It's not heresy. The solutions WILL work on the Internet. They will also work on private IP networks. But if a proposed solution ASSUMES a public database, then it won't work. In this case, it also means if it assumes a single tree it won't be acceptable. Nothing that assumes a single tree where any carrier can see the whole tree will be acceptable. There isn't going to be ONE enum tree, there are going to be many There isn't going to be ONE routing database, there are going to be many Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Friday, October 20, 2006 3:27 PM > To: Brian Rosen; Otmar Lendl > Cc: Michael Hammer (mhammer); speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements > > >I don't LIKE that, but it's what is happening. Carriers don't put ANY > route > >data in the public DNS. > > I do not like it either. > So the IETF is taken over by the carriers? > > We dump 20-30 years of development and start rebuilding > the PSTN on IP? > > I do not think that this is the charter of SPEERMINT, this may be > the task of 3GPP, ETSI TISPAN and ITU-T > > I also agree with Mike here: > > > I think that any middlemen that add no value will be > >disintermediated, sooner or later. > > Richard > > > ________________________________ > > Von: Brian Rosen [mailto:br@brianrosen.net] > Gesendet: Fr 20.10.2006 20:00 > An: Stastny Richard; 'Otmar Lendl' > Cc: 'Michael Hammer (mhammer)'; speermint@ietf.org > Betreff: RE: [Speermint] Basic Peering Requirements > > > > > So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs > > (e.g. > > > http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=pdf&ns_u > > rl=[http://www.gsmworld.com/documents/ireg/ir67.pdf] > Maybe. As I said, it's an optimization, but a useful one. > > > But they now detect that they also have to interconnect to others and > > global > > interconnection can only be in the long range in the global DNS. So > > sometimes > > they have to come out of their private playgrounds > Nope, no routing will be in the global DNS. The transit interconnects > will > be private, and the reachability data will be private. > > I don't LIKE that, but it's what is happening. Carriers don't put ANY > route > data in the public DNS. > > It's pretty straightforward to describe the scheme so that it works on the > public DNS, I just don't think it will actually be deployed that way. > Also, > if you have more than one choice of path, you can't do that with a simple > lookup, and if you have to do a series of lookups, making one choice from > a > list at every step, then you're playing my song. > > The problem here is a multi step route determination. We have a > constellation of federations, and set of transit carriers making > connections > between them in non simple ways. At any point in the graph, you may have > multiple choices. The problem is to find a path. It's not a simple one > stage lookup, it's a path discovery. It's a ROUTING problem. We know how > to solve routing problems. In this case, we don't yet need a dynamic > route > advertisement protocol, we can get away with simple query or query and > referral. > > It's classical routing: you either start at the origin and look through > all > paths at every branch until you get to the destination, or you feed > forward > the aggregated route advertisements from the next hop to the leaf. The > former is easy if the graph is not horribly complex. It would be better > to > feed forward aggregated routes. However, the TN to domain mapping is > highly > unlikely to work that way (not all registries will allow their data to be > aggregated). If you need to support referral, then you might as well make > the whole mechanism query and referral. You can cache, which helps with > domains, but doesn't help with TNs. > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 17:09:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb1c7-0006Xw-B2; Fri, 20 Oct 2006 17:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb1c6-0006X8-8F for speermint@ietf.org; Fri, 20 Oct 2006 17:09:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb1c0-0002Lw-Ni for speermint@ietf.org; Fri, 20 Oct 2006 17:09:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gb1bn-0002AG-Ut; Fri, 20 Oct 2006 16:08:52 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Stastny Richard'" , "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Fri, 20 Oct 2006 17:08:55 -0400 Message-ID: <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAAEsqTAAAH2dwAABlmwg In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218BDAE@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This requires you to obtain information you will probably not be allowed to know. Specifically, it requires transit carriers or federations to advertise all of their peers to anyone. I don't think this is acceptable. You can ask the question: can you get me to X? You cannot ask the question: who can I contact to get me directly to X? You MIGHT get the end domain to tell you all of the paths to them. I suspect not, for all carriers, but maybe. What I don't think you will get is a complete list of peers for a domain or a federation. Furthermore, unless you are part of a federation, you cannot ask anything of them. They certainly aren't going to put all of their routes in a public database. I believe federations and transit networks are NOT going to advertise their peers. That is competitive information, and it's not going to be public, or even semi private (i.e. just because you are part of some federation which has a route to X doesn't mean that you can be told all of the peers of a federation your federation has a transit network connection to). I'm not even sure they will allow a traceroute equivalent; they may hide vias. I hope we don't get to that level. Also, if we are only looking at domains, an iterative search as you suggest is not at all different from a referral mechanism I suggest, especially if you allow multiple routes. Your mechanism would not work for TNs, while mine would. You are searching from destination towards origination, and I'm searching from origin towards destination. I'm using route aggregation data, you are using direct route listings. It is a little simpler to use direct route data if you can get it. However, it doesn't work if you DO have to move to a dynamic routing engine. My solution would migrate to a BGP like route engine. Yours would not. Of course, the fundamental problem remains you assume you know the termination domain. I don't think you can figure that out when you start with a TN unless all TNs are in a public database. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Friday, October 20, 2006 4:16 PM > To: Brian Rosen; Stastny Richard; Otmar Lendl > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Brian, > > It doesn't necessarily have to ALL be public. The part about how the > originating Transit VSP knows how to connect to the Transit VSP serving > the terminating VSP could very well be by private peering arrangements > between the Transit VSPs. > > This is a series of questions that should be answerable: > Transit > A-----X-----Y-----B > > Can A get to B directly? Yes/No > If no, is B served by someone? Yes:Y > Can A get to Y directly? Yes/No > If no, is A served by someone? Yes:X > Can X get to Y directly? Yes/No > (Note this is where it can spiral, but SPs do a good job > of taking care of the X to Y connectivity.) > If yes, A sends call to X who sends to Y who sends to B. > Call successful because peering relationships exist on all segments. > > Note also that each of those "directly" queries is simply asking if the > sender has a peering relationship as identified by a name (i.e. > federation identity). It is a simple question that should have a simply > obtainable answer. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, October 20, 2006 3:57 PM > > To: 'Stastny Richard'; 'Otmar Lendl' > > Cc: Michael Hammer (mhammer); speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > Then Richard, we are done. > > > > User ENUM, DNS SRV, Internet Peering. We need nothing else. > > > > I do believe that eventually, carriers will be > > disintermediated, especially at the enterprise level. > > > > But we aren't there yet, and we have a lot of service > > providers who want to do this, with the private stuff. > > > > It's not heresy. The solutions WILL work on the Internet. > > They will also work on private IP networks. > > > > But if a proposed solution ASSUMES a public database, then it > > won't work. > > > > In this case, it also means if it assumes a single tree it > > won't be acceptable. Nothing that assumes a single tree > > where any carrier can see the whole tree will be acceptable. > > > > There isn't going to be ONE enum tree, there are going to be > > many There isn't going to be ONE routing database, there are > > going to be many > > > > Brian > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Friday, October 20, 2006 3:27 PM > > > To: Brian Rosen; Otmar Lendl > > > Cc: Michael Hammer (mhammer); speermint@ietf.org > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > >I don't LIKE that, but it's what is happening. Carriers don't put > > > >ANY > > > route > > > >data in the public DNS. > > > > > > I do not like it either. > > > So the IETF is taken over by the carriers? > > > > > > We dump 20-30 years of development and start rebuilding the PSTN on > > > IP? > > > > > > I do not think that this is the charter of SPEERMINT, this > > may be the > > > task of 3GPP, ETSI TISPAN and ITU-T > > > > > > I also agree with Mike here: > > > > > > > I think that any middlemen that add no value will be > > > >disintermediated, sooner or later. > > > > > > Richard > > > > > > > > > ________________________________ > > > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > > Gesendet: Fr 20.10.2006 20:00 > > > An: Stastny Richard; 'Otmar Lendl' > > > Cc: 'Michael Hammer (mhammer)'; speermint@ietf.org > > > Betreff: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs (e.g. > > > > > > > > > http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=pdf& > > > ns_u > > > > rl=[http://www.gsmworld.com/documents/ireg/ir67.pdf] > > > Maybe. As I said, it's an optimization, but a useful one. > > > > > > > But they now detect that they also have to interconnect to others > > > > and global interconnection can only be in the long range in the > > > > global DNS. So sometimes they have to come out of their private > > > > playgrounds > > > Nope, no routing will be in the global DNS. The transit > > interconnects > > > will be private, and the reachability data will be private. > > > > > > I don't LIKE that, but it's what is happening. Carriers > > don't put ANY > > > route data in the public DNS. > > > > > > It's pretty straightforward to describe the scheme so that > > it works on > > > the public DNS, I just don't think it will actually be > > deployed that way. > > > Also, > > > if you have more than one choice of path, you can't do that with a > > > simple lookup, and if you have to do a series of lookups, > > making one > > > choice from a list at every step, then you're playing my song. > > > > > > The problem here is a multi step route determination. We have a > > > constellation of federations, and set of transit carriers making > > > connections between them in non simple ways. At any point in the > > > graph, you may have multiple choices. The problem is to > > find a path. > > > It's not a simple one stage lookup, it's a path discovery. It's a > > > ROUTING problem. We know how to solve routing problems. In this > > > case, we don't yet need a dynamic route advertisement > > protocol, we can > > > get away with simple query or query and referral. > > > > > > It's classical routing: you either start at the origin and look > > > through all paths at every branch until you get to the > > destination, or > > > you feed forward the aggregated route advertisements from > > the next hop > > > to the leaf. The former is easy if the graph is not > > horribly complex. > > > It would be better to feed forward aggregated routes. > > However, the TN > > > to domain mapping is highly unlikely to work that way (not all > > > registries will allow their data to be aggregated). If you need to > > > support referral, then you might as well make the whole mechanism > > > query and referral. You can cache, which helps with domains, but > > > doesn't help with TNs. > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 17:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb1zJ-00029v-0w; Fri, 20 Oct 2006 17:33:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb1zI-00029q-5U for speermint@ietf.org; Fri, 20 Oct 2006 17:33:08 -0400 Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb1zG-0001Ll-Pb for speermint@ietf.org; Fri, 20 Oct 2006 17:33:08 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J7G00L7GEFWT3@firewall.mci.com> for speermint@ietf.org; Fri, 20 Oct 2006 21:31:09 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J7G00AF7EFWNC@dgismtp04.mcilink.com> for speermint@ietf.org; Fri, 20 Oct 2006 21:31:08 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([153.39.68.167]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J7G00A4YEFVNL@dgismtp04.mcilink.com> for speermint@ietf.org; Fri, 20 Oct 2006 21:31:08 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 21:31:07 +0000 Date: Fri, 20 Oct 2006 21:30:09 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Speermint] Basic Peering Requirements In-reply-to: <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> To: Brian Rosen , "Michael Hammer (mhammer)" , Stastny Richard , Otmar Lendl Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Speermint] Basic Peering Requirements Thread-index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAAEsqTAAAH2dwAABlmwgAAFFVWA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 20 Oct 2006 21:31:07.0959 (UTC) FILETIME=[0E08B470:01C6F48F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Finally this issue is raised...=20 > Of course, the fundamental problem remains you assume you=20 > know the termination domain. I don't think you can figure=20 > that out when you start with a TN unless all TNs are in a=20 > public database. I too wonder how this can be done on a global basis. tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 20 17:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb22L-0002vu-MJ; Fri, 20 Oct 2006 17:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb22J-0002vp-Vr for speermint@ietf.org; Fri, 20 Oct 2006 17:36:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb22H-0002Tx-D2 for speermint@ietf.org; Fri, 20 Oct 2006 17:36:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2006 14:36:13 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KLaDIJ020347; Fri, 20 Oct 2006 17:36:13 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9KLaCYJ026269; Fri, 20 Oct 2006 17:36:12 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 17:36:12 -0400 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] Basic Peering Requirements Date: Fri, 20 Oct 2006 17:36:09 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218BDEA@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAAEsqTAAAH2dwAABlmwgAAEjVCA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Stastny Richard" , "Otmar Lendl" X-OriginalArrivalTime: 20 Oct 2006 21:36:12.0198 (UTC) FILETIME=[C35FE460:01C6F48F] DKIM-Signature: a=rsa-sha1; q=dns; l=10478; t=1161380173; x=1162244173; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Stastny=20Richard=22=20, =0A=20=20=20=20=20=20=20= 20=22Otmar=20Lendl=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=Zp4JZPGybnTCr6cvj8TumXr23ZTNtF++KhaVhGCiaUfU99yiv4W04F1DZeaV5LlyvNa2H9VO ZE3CTWnuVDB89x1wGe/6b/JpiwxrT1SQ4D5MMRlJXYL3YimN7F5+mWnY; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Inline.=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, October 20, 2006 5:09 PM > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl' > Cc: speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > This requires you to obtain information you will probably not=20 > be allowed to know. Specifically, it requires transit=20 > carriers or federations to advertise all of their peers to anyone. >=20 > I don't think this is acceptable. >=20 > You can ask the question: can you get me to X? > You cannot ask the question: who can I contact to get me=20 > directly to X? I am assuming that if A uses a Transit VSP X, then A certainly better know how to get to X. > You MIGHT get the end domain to tell you all of the paths to=20 > them. I suspect not, for all carriers, but maybe. What I=20 > don't think you will get is a complete list of peers for a=20 > domain or a federation. I am not looking for a list of peers in the federation. I am looking for a target domain to be able to tell me either what Transit VSP Y serves it, or what federation it belongs to from which I can learn of a list of Transit VSPs that serve that federation. It might be in the interest of a Transit VSP to advertize that they have federations covered or perhaps run the federation.=20 > Furthermore, unless you are part of a federation, you cannot=20 > ask anything of them. They certainly aren't going to put all=20 > of their routes in a public database. You mean like the LERG? or the LNP Database? =20 Careful, this could become a regulatory issue. > I believe federations and transit networks are NOT going to=20 > advertise their peers. That is competitive information, and=20 > it's not going to be public, or even semi private (i.e. just=20 > because you are part of some federation which has a route to=20 > X doesn't mean that you can be told all of the peers of a=20 > federation your federation has a transit network connection to).=20 >=20 > I'm not even sure they will allow a traceroute equivalent;=20 > they may hide vias. I hope we don't get to that level. >=20 > Also, if we are only looking at domains, an iterative search=20 > as you suggest is not at all different from a referral=20 > mechanism I suggest, especially if you allow multiple routes.=20 > Your mechanism would not work for TNs, while mine would. =20 I definitely am not trying to route on TNs. > You are searching from destination towards origination, and=20 > I'm searching from origin towards destination. I'm using=20 > route aggregation data, you are using direct route listings. =20 > It is a little simpler to use direct route data if you can=20 > get it. However, it doesn't work if you DO have to move to a=20 > dynamic routing engine. My solution would migrate to a BGP=20 > like route engine. Yours would not. I think that a BGP like mechanism is the wrong way to go, so I don't see that as a problem. > Of course, the fundamental problem remains you assume you=20 > know the termination domain. I don't think you can figure=20 > that out when you start with a TN unless all TNs are in a=20 > public database. >=20 > Brian Correct, I am starting from the ENUM assumption that defined the boundary of the problem that Speermint was supposed to solve, namely routability toward SIP URIs not routing on TNs. If we want that, the PSTN does it extremely well. Mike >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Friday, October 20, 2006 4:16 PM > > To: Brian Rosen; Stastny Richard; Otmar Lendl > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Brian, > >=20 > > It doesn't necessarily have to ALL be public. The part=20 > about how the=20 > > originating Transit VSP knows how to connect to the Transit VSP=20 > > serving the terminating VSP could very well be by private peering=20 > > arrangements between the Transit VSPs. > >=20 > > This is a series of questions that should be answerable: > > Transit > > A-----X-----Y-----B > >=20 > > Can A get to B directly? Yes/No > > If no, is B served by someone? Yes:Y > > Can A get to Y directly? Yes/No > > If no, is A served by someone? Yes:X > > Can X get to Y directly? Yes/No > > (Note this is where it can spiral, but SPs do a good job > > of taking care of the X to Y connectivity.) If yes, A=20 > sends call to=20 > > X who sends to Y who sends to B. > > Call successful because peering relationships exist on all segments. > >=20 > > Note also that each of those "directly" queries is simply asking if=20 > > the sender has a peering relationship as identified by a name (i.e. > > federation identity). It is a simple question that should have a=20 > > simply obtainable answer. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, October 20, 2006 3:57 PM > > > To: 'Stastny Richard'; 'Otmar Lendl' > > > Cc: Michael Hammer (mhammer); speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Then Richard, we are done. > > > > > > User ENUM, DNS SRV, Internet Peering. We need nothing else. > > > > > > I do believe that eventually, carriers will be disintermediated,=20 > > > especially at the enterprise level. > > > > > > But we aren't there yet, and we have a lot of service=20 > providers who=20 > > > want to do this, with the private stuff. > > > > > > It's not heresy. The solutions WILL work on the Internet. > > > They will also work on private IP networks. > > > > > > But if a proposed solution ASSUMES a public database,=20 > then it won't=20 > > > work. > > > > > > In this case, it also means if it assumes a single tree=20 > it won't be=20 > > > acceptable. Nothing that assumes a single tree where any carrier=20 > > > can see the whole tree will be acceptable. > > > > > > There isn't going to be ONE enum tree, there are going to be many=20 > > > There isn't going to be ONE routing database, there are=20 > going to be=20 > > > many > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > > Sent: Friday, October 20, 2006 3:27 PM > > > > To: Brian Rosen; Otmar Lendl > > > > Cc: Michael Hammer (mhammer); speermint@ietf.org > > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > > > >I don't LIKE that, but it's what is happening. Carriers don't=20 > > > > >put ANY > > > > route > > > > >data in the public DNS. > > > > > > > > I do not like it either. > > > > So the IETF is taken over by the carriers? > > > > > > > > We dump 20-30 years of development and start rebuilding=20 > the PSTN=20 > > > > on IP? > > > > > > > > I do not think that this is the charter of SPEERMINT, this > > > may be the > > > > task of 3GPP, ETSI TISPAN and ITU-T > > > > > > > > I also agree with Mike here: > > > > > > > > > I think that any middlemen that add no value will be=20 > > > > >disintermediated, sooner or later. > > > > > > > > Richard > > > > > > > > > > > > ________________________________ > > > > > > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > > > Gesendet: Fr 20.10.2006 20:00 > > > > An: Stastny Richard; 'Otmar Lendl' > > > > Cc: 'Michael Hammer (mhammer)'; speermint@ietf.org > > > > Betreff: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > > > So 3GPP, GSMA and ETSI TISPAN have to rewrite their=20 > specs (e.g. > > > > > > > > > > > >=20 > http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=3Dpd > > > f& > > > > ns_u > > > > > rl=3D[http://www.gsmworld.com/documents/ireg/ir67.pdf] > > > > Maybe. As I said, it's an optimization, but a useful one. > > > > > > > > > But they now detect that they also have to interconnect to=20 > > > > > others and global interconnection can only be in the=20 > long range=20 > > > > > in the global DNS. So sometimes they have to come out=20 > of their=20 > > > > > private playgrounds > > > > Nope, no routing will be in the global DNS. The transit > > > interconnects > > > > will be private, and the reachability data will be private. > > > > > > > > I don't LIKE that, but it's what is happening. Carriers > > > don't put ANY > > > > route data in the public DNS. > > > > > > > > It's pretty straightforward to describe the scheme so that > > > it works on > > > > the public DNS, I just don't think it will actually be > > > deployed that way. > > > > Also, > > > > if you have more than one choice of path, you can't do=20 > that with a=20 > > > > simple lookup, and if you have to do a series of lookups, > > > making one > > > > choice from a list at every step, then you're playing my song. > > > > > > > > The problem here is a multi step route determination. =20 > We have a=20 > > > > constellation of federations, and set of transit=20 > carriers making=20 > > > > connections between them in non simple ways. At any=20 > point in the=20 > > > > graph, you may have multiple choices. The problem is to > > > find a path. > > > > It's not a simple one stage lookup, it's a path=20 > discovery. It's a=20 > > > > ROUTING problem. We know how to solve routing=20 > problems. In this=20 > > > > case, we don't yet need a dynamic route advertisement > > > protocol, we can > > > > get away with simple query or query and referral. > > > > > > > > It's classical routing: you either start at the origin and look=20 > > > > through all paths at every branch until you get to the > > > destination, or > > > > you feed forward the aggregated route advertisements from > > > the next hop > > > > to the leaf. The former is easy if the graph is not > > > horribly complex. > > > > It would be better to feed forward aggregated routes. > > > However, the TN > > > > to domain mapping is highly unlikely to work that way (not all=20 > > > > registries will allow their data to be aggregated). If=20 > you need=20 > > > > to support referral, then you might as well make the whole=20 > > > > mechanism query and referral. You can cache, which helps with=20 > > > > domains, but doesn't help with TNs. > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Oct 21 00:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb8jx-0003sI-03; Sat, 21 Oct 2006 00:45:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb8ju-0003mj-41; Sat, 21 Oct 2006 00:45:42 -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 1Gb3NN-0002E5-RF; Fri, 20 Oct 2006 19:02:05 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gb3CC-0005QY-R7; Fri, 20 Oct 2006 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B52FA2ACBD; Fri, 20 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gb3Bi-00048N-Fa; Fri, 20 Oct 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno Filename : draft-ietf-speermint-architecture-02.txt Pages : 17 Date : 2006-10-20 This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-architecture-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-architecture-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-20155649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-architecture-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-architecture-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-20155649.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Mon Oct 23 04:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbvVR-0006lq-JC; Mon, 23 Oct 2006 04:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbvVQ-0006lb-Ln for speermint@ietf.org; Mon, 23 Oct 2006 04:50:00 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbvVO-0003ZY-Bh for speermint@ietf.org; Mon, 23 Oct 2006 04:50:00 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 6902D21009E; Mon, 23 Oct 2006 10:49:24 +0200 (CEST) Message-ID: <453C8219.3090701@pernau.at> Date: Mon, 23 Oct 2006 10:49:29 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <08aa01c6f454$1bb27bf0$640fa8c0@cis.neustar.com> In-Reply-To: <08aa01c6f454$1bb27bf0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: >> and I >>> don't see the point in 2 or 3 level lookup in this case; just put the >>> ingress points in the federations in the main enum response and let a >> peer >> >> 1. because there are SIP URIs - yes I want the SPEERMINT solution also >> to work with > If you have a SIP URI, then you have an SRV record in the domain that ALL > the SIP URIs that come to you should be using. I think that is a sufficient > mechanism for all federations where public data is acceptable. Exactly, this works only for VSPs which accept traffic from everybody. But if it would be the case that every VSP supports incoming SIP from everybody, then there would not be a SPEERMINT group at all. regards klaus -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 07:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbyNG-0002x9-5N; Mon, 23 Oct 2006 07:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbyNE-0002wM-3L for speermint@ietf.org; Mon, 23 Oct 2006 07:53:44 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbyNC-0001mq-Lb for speermint@ietf.org; Mon, 23 Oct 2006 07:53:43 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9NBrfNs007699 for ; Mon, 23 Oct 2006 05:53:42 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Speermint] avoiding transcoding and discussions at the interim Date: Mon, 23 Oct 2006 05:53:40 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] avoiding transcoding and discussions at the interim Thread-Index: Acb2me1ofn958C24Ta+74LyZZinL1Q== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org All, This message is not to re-open any codec discussion: I'm just posting the example we discussed so that it is not lost, especially since some folks were interested in the requirements to think about potential solutions for this. There was a brief discussion on how transcoding could be avoided in some cases on indirect session peering.=20 An example of use case could be: enterprise A and enterprise B end up in exchanging media sessions directly but the signaling is done via an intermediary whose domain policy is forcing some codec selection that results in media transcoding even though SIP devices from A and B actually support a common codec.=20 endpoints A support codec set (a, b) endpoints B: codec set (b, c) enterprise A goes through an intermediary whose domain policy forces A to choose codec (a) =3D> this results in transcoding no matter what b chooses. I don't think there was enough discussion to capture this requirement as a refinement of "transcoding SHOULD be avoided" so this is not in the updated requirements ID. Just thought I'd post it on the list for further discussions. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 08:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbzFB-0001XQ-1E; Mon, 23 Oct 2006 08:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbzF8-0001To-Mj for speermint@ietf.org; Mon, 23 Oct 2006 08:49:26 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gbz9h-0005lY-SH for speermint@ietf.org; Mon, 23 Oct 2006 08:43:53 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1161607428!14271904!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 16439 invoked from network); 23 Oct 2006 12:43:48 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 23 Oct 2006 12:43:48 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NChmg0018218 for ; Mon, 23 Oct 2006 08:43:48 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NCfNqj017403 for ; Mon, 23 Oct 2006 08:43:43 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C3300111279 for speermint@ietf.org; Mon, 23 Oct 2006 08:43:43 -0400 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] I-D ACTION:draft-ietf-speermint-architecture-02.txt Date: Mon, 23 Oct 2006 08:43:42 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DEDC61B@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-02.txt Thread-Index: Acb0zGDQS+ukDJGlTHOETWq2UyMNxgB0oZgg From: "Pfautz, Penn L, GBLAM" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 A few comments on this draft: 1. Section 5.1.3 on Carrier ENUM begins with the word "Next" suggesting that a carrier ENUM query will be done only after a user ENUM query. This is not necessarily the case, to put it mildly. So replace "Next" with "Alternatively." 2. The sentence also suggests the query should be done "according to the procedures in [12]".But [12] is the Speermint Terminology document and doesn't describe ENUM procedures in any case. A more appropriate reference might be draft-ietf-enum-infrastructure-00. 3. The title of the section "Carrier ENUM" doesn't match terminology in the ENUM WG? Is this because something different is intended, i.e., any ENUM namespace maintained by a carrier or carriers as opposed to a public infrastructure ENUM e.g., in ie164.arpa? Penn Pfautz _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 09:29:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbzrL-0001Xk-5C; Mon, 23 Oct 2006 09:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbzrK-0001Xe-0W for speermint@ietf.org; Mon, 23 Oct 2006 09:28:54 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbzqn-00007I-02 for speermint@ietf.org; Mon, 23 Oct 2006 09:28:53 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id D37F81A36D; Mon, 23 Oct 2006 15:28:08 +0200 (CEST) Date: Mon, 23 Oct 2006 15:28:08 +0200 From: Otmar Lendl To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061023132808.GR19113@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , speermint@ietf.org References: <4538B7BB.3070505@pernau.at> <089001c6f445$04bd3f70$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <089001c6f445$04bd3f70$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org [This thread is big enough as it is, I'll try to cut my reply down to the crucial points.] On 2006/10/20 14:10, Brian Rosen wrote: > > > > Why do you propose a solution which makes VSP dependent on provider of > > this big routing databases? IMO an IETF solution should not force VSPs > > to private ENUM trees and peering providers. > If anyone wants to put information in the public (user) enum tree, they are > free do so. They can then peer on the Internet, surely the best IETF > solution. If a carrier puts numbers in a public enum tree (anywhere in > .arpa), it can advertise in that tree how it may be contacted. That's the user ENUM case. We've got real life experience with it. > I don't > think the notion that your number is in a public tree, but your ingress > points at whatever federations you peer at are secret makes any sense and I > don't see the point in 2 or 3 level lookup in this case; just put the > ingress points in the federations in the main enum response and let a peer > pick one of them that it likes based on its memberships and your > order/preference. The main misgivings we've heard from carriers we've been pitching user-ENUM to was not the publication of the TN->URI mapping, but the fact that these URIs are supposed to resolve to publically accessible ingress points. Their concerns are not secrecy, but control and security. They want to control with whom (and how) they are going to exchange traffic with. Once we explained to them how they can achieve that (using the DP-DDDS draft), they didn't care about the secrecy. > If you have no common federations then you need to > identify a route. I've never understood how you proposed to do that. We do? Quoting draft-lendl-speermint-federations-03.txt: ---- 4.4. Routing Architecture For the direct intra-federation call, it is sufficient to match the federation memberships of the initiating and destination VSP. This matching can be achieved through the domain policy DDDS application. While direct matching of federations enables direct peering, it does not solve the universal reachability problem. [...] This document does not propose a routing protocol for that. The following options are intended to stimulate discussions in the SPEERMINT working-group. ---- /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 09:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbzsu-0001td-6f; Mon, 23 Oct 2006 09:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbzst-0001tX-24 for speermint@ietf.org; Mon, 23 Oct 2006 09:30:31 -0400 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbzsl-0000vD-Q4 for speermint@ietf.org; Mon, 23 Oct 2006 09:30:31 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Mon, 23 Oct 2006 16:30:20 +0300 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:30:19 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86038B4A44@POSTI.laru.local> In-Reply-To: <005601c6f481$f937f3b0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAAEsqTAAe5SysA== From: "Nieminen Klaus" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi all, I think that we would like to have at least a good portion of carriers to support whatever mechanism we will choose. I have seen that Brian has a clear opinion on what carriers will accept and what they won't. However, I have not seen many carriers to comment this discussion and anyway I'm more than sure that this isn't the only truth. > enable peering between two or more administrative domains over IP networks This is our goal and I was just wondering what are the main users for our coming specifications? Are bigger mobile operators going to use them anyway? Are enterprises and small VSPs more important communities? I don't have answers :) I was also trying to understand why e.g. publishing the federation information is considered harmfull or something carriers won't do? This may be the current policy, but are there some real reasons behind that opinion or is it just that people say no because they don't understand the concept. Please enlighten me. I'm not in a position to hum for either of the approaches, but I would like to understand the pros and cons better. regards, - Klaus _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 09:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbztt-0002Kl-8g; Mon, 23 Oct 2006 09:31:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbzts-0002KY-28 for speermint@ietf.org; Mon, 23 Oct 2006 09:31:32 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbztm-0001Rd-5D for speermint@ietf.org; Mon, 23 Oct 2006 09:31:32 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 0B4D121002A; Mon, 23 Oct 2006 15:31:22 +0200 (CEST) Message-ID: <453CC430.4090605@pernau.at> Date: Mon, 23 Oct 2006 15:31:28 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <002f01c6f46e$d709c740$640fa8c0@cis.neustar.com> In-Reply-To: <002f01c6f46e$d709c740$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Brian! Brian Rosen wrote: >>> No, I'm assuming the federation can tell me next hop, and >>> that's all it can tell me. That's more or less the way all >>> routing works. It's more like you try all paths and see how >>> many lead to your destination, but in this case you only get >>> the next hop. But, like all routing problems, you may have >>> zero, one, or more than one next hop choices that are valid. >>> Whether you have in your possession all the routing data, or >>> you query for it, or you query and cache for it, the result >>> is the same: you ask every federation if they can route your >>> call, and select one. >> But, I don't want to query a lot of federations hoping for a hit. I >> want each successive lookup to result in definitive answers leading to a >> known next hop. > You can't ever get that. If you are a part of more than one federation then > you have to ask all of them if they can get you to the destination. No. Have you ever read Otmar's drafts? It is the other way round: You have a SIP URI, thus you have a domain. Make a NAPTR lookup of the domain and it will tell you to which federations it belongs. Then you compare the result with the federations you are belonging too. No need for asking the federation for all members and planing in advance. regards klaus > You can > aggregate data they give you, preplan routes, and make the answer be a one > step lookup, but that would be something you do internally IFF the > federation gives you the data. In general, in my world, they don't; you > don't get a full list of peers, ESPECIALLY INDIRECT PEERS. You can query > for a route, and get an answer. > -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 10:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0Px-0004eO-4o; Mon, 23 Oct 2006 10:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0Pv-0004Zm-Jm for speermint@ietf.org; Mon, 23 Oct 2006 10:04:39 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0Pu-0001A0-5n for speermint@ietf.org; Mon, 23 Oct 2006 10:04:39 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 2ED5821002A; Mon, 23 Oct 2006 16:04:33 +0200 (CEST) Message-ID: <453CCBF8.2010504@pernau.at> Date: Mon, 23 Oct 2006 16:04:40 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Nieminen Klaus Subject: Re: [Speermint] Basic Peering Requirements References: <07BC6C0D40216E44A34BE6701694FE86038B4A44@POSTI.laru.local> In-Reply-To: <07BC6C0D40216E44A34BE6701694FE86038B4A44@POSTI.laru.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Nieminen Klaus wrote: > Hi all, > > I think that we would like to have at least a good portion of carriers > to support whatever mechanism we will choose. > > I have seen that Brian has a clear opinion on what carriers will accept > and what they won't. However, I have not seen many carriers to comment > this discussion and anyway I'm more than sure that this isn't the only > truth. > >> enable peering between two or more administrative domains over IP > networks > > This is our goal and I was just wondering what are the main users for > our coming specifications? Are bigger mobile operators going to use them > anyway? Are enterprises and small VSPs more important communities? I > don't have answers :) > > I was also trying to understand why e.g. publishing the federation > information is considered harmfull or something carriers won't do? This > may be the current policy, but are there some real reasons behind that > opinion or is it just that people say no because they don't understand > the concept. Please enlighten me. Hi Klaus! Following my view, which is based on discussion with several carriers. - Carriers do not have big research developments and in-depth knowledge of every protocol. They are used to buy what the equipment vendors are offering. If a big vendor tells them that it must be "this way", then the carrier will request a solution which does it "this way". regarding public routing info: There are several arguments why carriers will never put there TNs in public ENUM trees, e.g.: - "Carriers are afraid that others can query how many numbers(customers) they have." - "Carriers are afraid that other carriers can find out the current carrier-of-record of an enterprise and to poach this customer" IMO this arguments are not valid, because this information can be retrieved easily also in the current TDM world - at least in Austria. maybe others can tell us why carriers never will put there numbers into public infrastructure ENUM? regards klaus > > I'm not in a position to hum for either of the approaches, but I would > like to understand the pros and cons better. > > regards, > > - Klaus > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 10:10:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0Uw-000407-DJ; Mon, 23 Oct 2006 10:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0Uu-0003vT-W2 for speermint@ietf.org; Mon, 23 Oct 2006 10:09:48 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc0Ua-00024t-SQ for speermint@ietf.org; Mon, 23 Oct 2006 10:09:48 -0400 Content-class: urn:content-classes:message Subject: RE: [Speermint] Basic Peering Requirements MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Oct 2006 16:08:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C51FC@oefeg-s04.oefeg.loc> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 In-Reply-To: <453CCBF8.2010504@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements thread-index: Acb2rBwdcx5ztd4WSBiKGjn8SaTSFAAAF4NQ From: "Stastny Richard" To: "Klaus Darilion" , "Nieminen Klaus" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > maybe others can tell us why carriers never will put there numbers into > public infrastructure ENUM? e.g. because then they are forced to decide who will run it? Richard > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, October 23, 2006 4:05 PM > To: Nieminen Klaus > Cc: speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > Nieminen Klaus wrote: > > Hi all, > > > > I think that we would like to have at least a good portion of carriers > > to support whatever mechanism we will choose. > > > > I have seen that Brian has a clear opinion on what carriers will accept > > and what they won't. However, I have not seen many carriers to comment > > this discussion and anyway I'm more than sure that this isn't the only > > truth. > > > >> enable peering between two or more administrative domains over IP > > networks > > > > This is our goal and I was just wondering what are the main users for > > our coming specifications? Are bigger mobile operators going to use them > > anyway? Are enterprises and small VSPs more important communities? I > > don't have answers :) > > > > I was also trying to understand why e.g. publishing the federation > > information is considered harmfull or something carriers won't do? This > > may be the current policy, but are there some real reasons behind that > > opinion or is it just that people say no because they don't understand > > the concept. Please enlighten me. >=20 > Hi Klaus! >=20 > Following my view, which is based on discussion with several carriers. >=20 > - Carriers do not have big research developments and in-depth knowledge > of every protocol. They are used to buy what the equipment vendors are > offering. If a big vendor tells them that it must be "this way", then > the carrier will request a solution which does it "this way". >=20 > regarding public routing info: > There are several arguments why carriers will never put there TNs in > public ENUM trees, e.g.: > - "Carriers are afraid that others can query how many numbers(customers) > they have." > - "Carriers are afraid that other carriers can find out the current > carrier-of-record of an enterprise and to poach this customer" >=20 > IMO this arguments are not valid, because this information can be > retrieved easily also in the current TDM world - at least in Austria. >=20 > maybe others can tell us why carriers never will put there numbers into > public infrastructure ENUM? >=20 > regards > klaus >=20 > > > > I'm not in a position to hum for either of the approaches, but I would > > like to understand the pros and cons better. > > > > regards, > > > > - Klaus > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > -- > Klaus Darilion > nic.at >=20 >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Mon Oct 23 10:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0dW-0002d8-7F; Mon, 23 Oct 2006 10:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc0dU-0002cy-KV for speermint@ietf.org; Mon, 23 Oct 2006 10:18:40 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc0dO-0003pS-1j for speermint@ietf.org; Mon, 23 Oct 2006 10:18:40 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1161613112!15718866!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 869 invoked from network); 23 Oct 2006 14:18:32 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 23 Oct 2006 14:18:32 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NECDoe012542 for ; Mon, 23 Oct 2006 10:12:14 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NEC8Pr012476 for ; Mon, 23 Oct 2006 10:12:08 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C330011542D; Mon, 23 Oct 2006 10:18:24 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 10:18:23 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DEDC7C4@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <453CCBF8.2010504@pernau.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2rEYWF70aVdsHQTK8jI0TK6QIGAAAQLiA From: "Pfautz, Penn L, GBLAM" To: "Klaus Darilion" , "Nieminen Klaus" X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Although this shouldn't be regarded as a commitment on anyone's part, it's worth noting that the US carriers holding the lion's share of CC1 numbers in the US are working in the CC1 ENUM LLC to instantiate a public infrastructure ENUM. That doesn't represent a commitment to peer with all parties but it does reflect a willingness to make at least certain data generally available. Penn Pfautz -----Original Message----- From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20 Sent: Monday, October 23, 2006 10:05 AM To: Nieminen Klaus Cc: speermint@ietf.org Subject: Re: [Speermint] Basic Peering Requirements Nieminen Klaus wrote: > Hi all, >=20 > I think that we would like to have at least a good portion of carriers > to support whatever mechanism we will choose. >=20 > I have seen that Brian has a clear opinion on what carriers will accept > and what they won't. However, I have not seen many carriers to comment > this discussion and anyway I'm more than sure that this isn't the only > truth. >=20 >> enable peering between two or more administrative domains over IP > networks >=20 > This is our goal and I was just wondering what are the main users for > our coming specifications? Are bigger mobile operators going to use them > anyway? Are enterprises and small VSPs more important communities? I > don't have answers :) >=20 > I was also trying to understand why e.g. publishing the federation > information is considered harmfull or something carriers won't do? This > may be the current policy, but are there some real reasons behind that > opinion or is it just that people say no because they don't understand > the concept. Please enlighten me. Hi Klaus! Following my view, which is based on discussion with several carriers. - Carriers do not have big research developments and in-depth knowledge=20 of every protocol. They are used to buy what the equipment vendors are=20 offering. If a big vendor tells them that it must be "this way", then=20 the carrier will request a solution which does it "this way". regarding public routing info: There are several arguments why carriers will never put there TNs in=20 public ENUM trees, e.g.: - "Carriers are afraid that others can query how many numbers(customers) they have." - "Carriers are afraid that other carriers can find out the current=20 carrier-of-record of an enterprise and to poach this customer" IMO this arguments are not valid, because this information can be=20 retrieved easily also in the current TDM world - at least in Austria. maybe others can tell us why carriers never will put there numbers into=20 public infrastructure ENUM? regards klaus >=20 > I'm not in a position to hum for either of the approaches, but I would > like to understand the pros and cons better. >=20 > regards, >=20 > - Klaus >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint --=20 Klaus Darilion nic.at _______________________________________________ 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 From speermint-bounces@ietf.org Mon Oct 23 10:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc125-0008J5-Vz; Mon, 23 Oct 2006 10:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc124-0007ws-GD for speermint@ietf.org; Mon, 23 Oct 2006 10:44:04 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0xe-0006ig-5D for speermint@ietf.org; Mon, 23 Oct 2006 10:39:37 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id A29BA21002A; Mon, 23 Oct 2006 16:39:13 +0200 (CEST) Message-ID: <453CD418.4090604@pernau.at> Date: Mon, 23 Oct 2006 16:39:20 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> In-Reply-To: <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > This requires you to obtain information you will probably not be allowed to > know. Specifically, it requires transit carriers or federations to > advertise all of their peers to anyone. > > I don't think this is acceptable. I always wonder why carriers won't publish any ingress options. Carrying phone calls is money, and if they don't tell others there ingress points they won't have voice traffic. > You can ask the question: can you get me to X? > You cannot ask the question: who can I contact to get me directly to X? > > You MIGHT get the end domain to tell you all of the paths to them. I > suspect not, for all carriers, but maybe. What I don't think you will get > is a complete list of peers for a domain or a federation. You do not need the list of all peers of a federation - you only need the federations of a domain. > > Furthermore, unless you are part of a federation, you cannot ask anything of Yes - but it is not necessary. The key is the domain, not the federation. > them. They certainly aren't going to put all of their routes in a public > database. The federation need not to publish there members - the members publish there federations. Also I guess most federation do not provide any traffic. The mission of a federation is direct peering between its members. For transit there will be transit providers, which bridge federations. And this transit providers will tell you where they can get you - not the federations. regards klaus -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 10:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1C2-00014r-4p; Mon, 23 Oct 2006 10:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1C0-00014m-UZ for speermint@ietf.org; Mon, 23 Oct 2006 10:54:20 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1Bv-00019S-8n for speermint@ietf.org; Mon, 23 Oct 2006 10:54:20 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 4133A1A36D; Mon, 23 Oct 2006 16:54:12 +0200 (CEST) Date: Mon, 23 Oct 2006 16:54:12 +0200 From: Otmar Lendl To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061023145412.GS19113@nic.at> Mail-Followup-To: Otmar Lendl , Brian Rosen , 'Stastny Richard' , speermint@ietf.org References: <20061020152336.GP19113@nic.at> <001201c6f466$2abf75f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201c6f466$2abf75f0$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 'Stastny Richard' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/20 18:10, Brian Rosen wrote: > > I think what I'm proposing for TNs works for SIP uris. I really don't want > to go there, because it DOES duplicate DNS in some ways, but we have to. > I've once asked a room full of ETSI people what kind of public SIP identities they are planning to hand to their customers once the NGN transistion is starting. That brought quite a few uneasy glances, especially after telling them that using VSP owned domains will walk them into a big swamp regarding porting. That left them with the choice of either * replicate the public DNS inside their walled garden or * use the public DNS as part of their call setup procedure (at least for customer-owned domains). Neither option made them happy. ..snip... > This is the problem we have with you guys. Somehow you think that it's > acceptable for there to be some private data and some public data. I don't > think it works that way. The organizations who won't peer on the Internet > want ALL of their data private, not just some of it. Oh yes, they're not used to that from their PSTN business. On the other hand, they don't seem to have a problem regarding such information at the IP layer. E.g. from the RIPE db: aut-num: AS8447 as-name: TELEKOM-AT descr: Telekom Austria AutonomousSystem import: from AS174 action pref=100; accept AS174:AS-COGENT export: to AS174 announce AS-PTA import: from AS286 action pref=100; accept AS-KPN export: to AS286 announce AS-PTA import: from AS553 action pref=100; accept AS-BELWUE export: to AS553 announce AS-PTA import: from AS702 action pref=100; accept AS702:RS-AT AS702:RS-AT-CUSTOMER export: to AS702 announce AS-PTA import: from AS1200 action pref=100; accept AS1200 export: to AS1200 announce AS-PTA import: from AS1120 action pref=100; accept AS-ACOSERV export: to AS1120 announce AS-PTA import: from AS1239 action pref=100; accept ANY export: to AS1239 announce AS-PTA [...] It's public information there that Telekom Austria uses AS1239, AS3356, and AS6762 as upstream providers and peers with [...]. So why is it so _unthinkable_ to have similar information public for SIP peering? > > Brian, you're talking about routing based on telephone numbers. I'm not > > sure whether this is in scope for speermint. TN -> SIP translation is > > handled by the ENUM WG. We're charted to provide SIP interconnection. > Yeah, I understand my problem. Sometimes dealing with reality is hard. > We may have to refer some work to ENUM, or change the charter. I think we need an agenda point for that in San Diego. > > Infrastructure ENUM is one aproach. To really be useful, I-ENUM needs > > a speermint solution as to define how to handle and route based on > > the URIs retrieved from I-ENUM. > Again, I-ENUM, because it's based on a public tree, is a non starter for the > vast majority of carriers today. We really should make a poll at in San Diego. As mentioned before: I don't think the problem is with the ENUM information, it's only about running open SIP proxies. > I don't think that it makes any sense to force carriers to do TN to domain, > and then domain to next hop, when the actual databases could easily give you > TN to next hop. Since we do have to route directly by domain, you could do > this, I just think we should combine them. That's an optimization, but it's > a useful one. That optimization is IMHO a layering violation. These always look very efficient at first sight but are guaranteed to lead to architectural straight-jackets in the long term. > Note that the direct query really could be (private) ENUM. You query with > TN, you get a set of NAPTRs that resolve to your route choices, you then use > normal SIP DNS/SRV mechanisms to get to the IP address where you send the > call. We could make an equivalent DDDS application for the domain based > route. Oh yes, private ENUM might play a role in all this. I'm not ruling that out. (although I prefer a public I-ENUM). The DP-DDDS with its federation scheme can just as well direct the routing to a federation internal nexthop lookup scheme. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 11:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1NI-000093-3x; Mon, 23 Oct 2006 11:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1NH-00008x-Of for speermint@ietf.org; Mon, 23 Oct 2006 11:05:59 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1Mt-000390-5Q for speermint@ietf.org; Mon, 23 Oct 2006 11:05:59 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9NF5141031915; Mon, 23 Oct 2006 08:05:07 -0700 From: "Richard Shockey" To: "'Klaus Darilion'" , "'Nieminen Klaus'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 11:04:42 -0400 Message-ID: <03e501c6f6b4$92f5db50$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <453CCBF8.2010504@pernau.at> Thread-Index: Acb2rDkikxAPyJvfQyO3W0KZtnZeMwABrvcQ X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org IN LINE .. > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Monday, October 23, 2006 10:05 AM > To: Nieminen Klaus > Cc: speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements > > Nieminen Klaus wrote: > > Hi all, > > > > I think that we would like to have at least a good portion of carriers > > to support whatever mechanism we will choose. > > > > I have seen that Brian has a clear opinion on what carriers will accept > > and what they won't. However, I have not seen many carriers to comment > > this discussion and anyway I'm more than sure that this isn't the only > > truth. > > > >> enable peering between two or more administrative domains over IP > > networks > > > > This is our goal and I was just wondering what are the main users for > > our coming specifications? Are bigger mobile operators going to use them > > anyway? Are enterprises and small VSPs more important communities? I > > don't have answers :) > > > > I was also trying to understand why e.g. publishing the federation > > information is considered harmfull or something carriers won't do? This > > may be the current policy, but are there some real reasons behind that > > opinion or is it just that people say no because they don't understand > > the concept. Please enlighten me. > > Hi Klaus! > > Following my view, which is based on discussion with several carriers. > > - Carriers do not have big research developments and in-depth knowledge > of every protocol. They are used to buy what the equipment vendors are > offering. If a big vendor tells them that it must be "this way", then > the carrier will request a solution which does it "this way". > > regarding public routing info: > There are several arguments why carriers will never put there TNs in > public ENUM trees, e.g.: > - "Carriers are afraid that others can query how many numbers(customers) > they have." > - "Carriers are afraid that other carriers can find out the current > carrier-of-record of an enterprise and to poach this customer" Both of these arguments as you mention are completely specious.. In many countries is extremely easy to calculate how many customers a carrier has and who is the underlying service provider for a particular TN. Certainly that is the situation in the US as in Austria as you point out. There is no empirical evidence that this data creates customer poaching. > > IMO this arguments are not valid, because this information can be > retrieved easily also in the current TDM world - at least in Austria. > > maybe others can tell us why carriers never will put there numbers into > public infrastructure ENUM? The real reason carriers will never put their numbers into any form of public infrastructure ENUM is two fold. A. Only a mad man would put the location of critical VoIP ingress elements edge or otherwise into a public DNS infrastructure. The potential for DDoS alone is massive. B. Infrastructure ENUM as it has been proposed almost guarantees national regulatory delegation and oversight and most carriers are in favor of DE-Regulation of telecom not RE-Regulation. C. Some form of trusted registry of TN 2 URI mappings is absolutely necessary to insure interoperability but I suspect it will be carriers them selves that attempt to control the organization and distribution of such data. > > regards > klaus > > > > > I'm not in a position to hum for either of the approaches, but I would > > like to understand the pros and cons better. > > > > regards, > > > > - Klaus > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > -- > Klaus Darilion > nic.at > > > _______________________________________________ > 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 From speermint-bounces@ietf.org Mon Oct 23 11:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1QR-0005Ts-Ar; Mon, 23 Oct 2006 11:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1QQ-0005Tn-Ej for speermint@ietf.org; Mon, 23 Oct 2006 11:09:14 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1QO-0003o4-31 for speermint@ietf.org; Mon, 23 Oct 2006 11:09:14 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id EED1F1A36D; Mon, 23 Oct 2006 17:09:10 +0200 (CEST) Date: Mon, 23 Oct 2006 17:09:10 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061023150910.GT19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E30218BDAE@xmb-rtp-20b.amer.cisco.com> <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/20 23:10, Brian Rosen wrote: > This requires you to obtain information you will probably not be allowed to > know. Specifically, it requires transit carriers or federations to > advertise all of their peers to anyone. > > I don't think this is acceptable. It's done for IP transit/peering. Just have a look at the RIR's routing registries. e.g. have a look at what's public for MCI EMEA: http://www.ripe.net/fcgi-bin/whois?searchtext=AS702 > You MIGHT get the end domain to tell you all of the paths to them. I > suspect not, for all carriers, but maybe. What I don't think you will get > is a complete list of peers for a domain or a federation. On IP Layer3, you can. > I believe federations and transit networks are NOT going to advertise their > peers. That is competitive information, and it's not going to be public, or > even semi private (i.e. just because you are part of some federation which > has a route to X doesn't mean that you can be told all of the peers of a > federation your federation has a transit network connection to). Once again, that "competitive information" *is* public for the rather competitative IP transit market. > I'm not even sure they will allow a traceroute equivalent; they may hide > vias. I hope we don't get to that level. > > Also, if we are only looking at domains, an iterative search as you suggest > is not at all different from a referral mechanism I suggest, especially if > you allow multiple routes. Your mechanism would not work for TNs, while > mine would. You are searching from destination towards origination, and I'm > searching from origin towards destination. I'm using route aggregation > data, you are using direct route listings. It is a little simpler to use > direct route data if you can get it. However, it doesn't work if you DO > have to move to a dynamic routing engine. My solution would migrate to a > BGP like route engine. Yours would not. You're re-inventing TRIP. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 11:10:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1RA-0005ya-IG; Mon, 23 Oct 2006 11:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1R9-0005yV-5U for speermint@ietf.org; Mon, 23 Oct 2006 11:09:59 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1R7-0003vi-OY for speermint@ietf.org; Mon, 23 Oct 2006 11:09:59 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9NF9uxv000557; Mon, 23 Oct 2006 08:10:02 -0700 From: "Richard Shockey" To: "'Stastny Richard'" , "'Brian Rosen'" , "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 11:09:37 -0400 Message-ID: <03e901c6f6b5$429df740$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BB3@oefeg-s04.oefeg.loc> Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4AAbt38AADQf5rAI42edA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > >I don't LIKE that, but it's what is happening. Carriers don't put ANY > route > >data in the public DNS. > > I do not like it either. > So the IETF is taken over by the carriers? Hummm.. I thought that this was the Internet Telephony Engineering Task Force .. > We dump 20-30 years of development and start rebuilding > the PSTN on IP? > > I do not think that this is the charter of SPEERMINT, this may be > the task of 3GPP, ETSI TISPAN and ITU-T > > I also agree with Mike here: > > > I think that any middlemen that add no value will be > >disintermediated, sooner or later. > > Richard > > > > _______________________________________________ > 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 From speermint-bounces@ietf.org Mon Oct 23 11:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1l6-0002OR-Tj; Mon, 23 Oct 2006 11:30:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1l5-0002NX-DB for speermint@ietf.org; Mon, 23 Oct 2006 11:30:35 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1jl-0006tI-NL for speermint@ietf.org; Mon, 23 Oct 2006 11:29:15 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9NFT71g004181; Mon, 23 Oct 2006 08:29:13 -0700 From: "Richard Shockey" To: "'Stastny Richard'" , "'Brian Rosen'" , "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 11:28:44 -0400 Message-ID: <040001c6f6b7$eeaa63f0$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4BB2@oefeg-s04.oefeg.loc> Thread-Index: Acb0W7VyLBvA/Bz9TZKnxO10YOo3EAABDDngAAIUN+4Ak6NZ8A== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > >Note that the direct query really could be (private) ENUM. You query > with TN, you get a set of NAPTRs that resolve to your route choices, you then use normal SIP DNS/SRV mechanisms to get to the IP address where you send the > >call. We could make an equivalent DDDS application for the domain based > >route. > > And they basically use within their federation RFC3761 and RFC3263 for > routing, and the next hop is the destination, so no need for speermint at all. > > But they now detect that they also have to interconnect to others and > global interconnection can only be in the long range in the global DNS. So > sometimes they have to come out of their private playgrounds Not necessarily ..Not if they have access to a sufficient number of TN 2 URI mapping databases or gateways to those databases. Those databases may or may not be in the DNS public or private. You ASSUME there MUST be a global delegation model ... I don't think the carriers are completely ready to hold hands and declare peace on earth and good will to their customers. Lets not forget the boundaries set for SPEERMINT ... SPEERMINT is about everything that happens AFTER you have done a number translation to a URI. > > For I-ENUM to get market traction, speermint needs to deliver. > I don't think the problems of I-ENUM have anything to do with SPEERMINT, > they are only the issues of putting numbers in the public DNS. > > > > > And vice versa. > That is definitely wrong. Most of the federations use private enum or > equivalent. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 11:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1uR-0000sC-Di; Mon, 23 Oct 2006 11:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1uQ-0000s6-24 for speermint@ietf.org; Mon, 23 Oct 2006 11:40:14 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1uK-0001C1-50 for speermint@ietf.org; Mon, 23 Oct 2006 11:40:13 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6944E1A36D; Mon, 23 Oct 2006 17:40:06 +0200 (CEST) Date: Mon, 23 Oct 2006 17:40:06 +0200 From: Otmar Lendl To: Richard Shockey Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061023154006.GU19113@nic.at> Mail-Followup-To: Otmar Lendl , Richard Shockey , 'Klaus Darilion' , 'Nieminen Klaus' , speermint@ietf.org References: <453CCBF8.2010504@pernau.at> <03e501c6f6b4$92f5db50$75201f0a@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03e501c6f6b4$92f5db50$75201f0a@cis.neustar.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: speermint@ietf.org, 'Nieminen Klaus' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/23 17:10, Richard Shockey wrote: > > > There are several arguments why carriers will never put there TNs in > > public ENUM trees, e.g.: > > - "Carriers are afraid that others can query how many numbers(customers) > > they have." > > - "Carriers are afraid that other carriers can find out the current > > carrier-of-record of an enterprise and to poach this customer" > > Both of these arguments as you mention are completely specious.. We know. Klaus just quoted what we sometimes hear from carriers. You know, they don't always make sense. > > maybe others can tell us why carriers never will put there numbers into > > public infrastructure ENUM? > > > The real reason carriers will never put their numbers into any form of > public infrastructure ENUM is two fold. > > A. Only a mad man would put the location of critical VoIP ingress elements > edge or otherwise into a public DNS infrastructure. The potential for DDoS > alone is massive. Agreed. That's the reason we developed the domain policy DDDS proposal which can used to really de-couple the URI from the ingress elements. E.g. if the only things you can learn from the public DNS is that example.com is a member of federation X and Y, and uses fedx-ingress.example.com A 10.0.0.42 and fedy-ingress.example.com A 172.27.10.10 as the ingress elements on the respective shared L3 infrastructure then I don't see the DDoS potential here. > B. Infrastructure ENUM as it has been proposed almost guarantees national > regulatory delegation and oversight and most carriers are in favor of > DE-Regulation of telecom not RE-Regulation. Wait a second: you're now switching from the issue of a public tree to the question of whether that should be a NRA-approved one under ie164.arpa. If the regulator proves to be a burden in all this, then nothing stops an industry consortium to establish a tree under a different apex. (As the forest of trees out there shows.) > C. Some form of trusted registry of TN 2 URI mappings is absolutely > necessary to insure interoperability but I suspect it will be carriers them > selves that attempt to control the organization and distribution of such > data. Oh yes. Who argued against the carriers establishing a such a tree? IMHO the best case is if the regulators *and* the carries agree on someone who runs that trusted registry. Whether that will then be a private tree or a public one, is an independent question. Given the fact that the number of "carriers" is bound to increase and international resolution of TN->URI will be an issue, I doubt that it will be easy to establish a sensible, universal rule which describes who should have access to that private tree. Once the number of organizations which have access to a private tree exceeds as certain number, the security benefits you get from keeping it non-public are dwarfed by the complexities of maintaining access control rules. Or, as other events prove every now and then, the PSTN method of maintaining security ("trust all other carriers") is already breaking down right now. So why perpetuate that model? It's just case of security by obscurity. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 11:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc23J-0006E4-Bf; Mon, 23 Oct 2006 11:49:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc23I-0006Dz-Pj for speermint@ietf.org; Mon, 23 Oct 2006 11:49:24 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc23G-0002ee-Ak for speermint@ietf.org; Mon, 23 Oct 2006 11:49:24 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 93B8C21002A; Mon, 23 Oct 2006 17:49:13 +0200 (CEST) Message-ID: <453CE480.8060301@pernau.at> Date: Mon, 23 Oct 2006 17:49:20 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Speermint] TLS related requirements for speermint ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: speermint@ietf.org, vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Here Part 2 :-) Jean-Francois Mule wrote: > --- 5. SIP entities involved in the session establishment exchanges MUST > follow the following requirements: > + check certs : > "the client certificate MUST contain a DNS or URI choice type in the > subjectAltName which corresponds to the domain asserted in the host > production of the From header URI." (from Rohan's I-D) We MUST NOT enforce this check, as it does not work with retargeting and transit scenarios. > + check identity in cert per section 4 of > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? Does that mean that as soon as one of the identities in the certificate matches the hostname or SIP domain the validation is sucessful? By no means we may prevent the following example: - user has SIP URI user@user.com - user hosts the SIP service at itspA Thus, user's SRV points to itspA's ingress point: _sips._tcp SRV 10 10 5060 sip.itspA.com RFC3261 requires that itspA needs to present a certificate for user.com. But this is not scalable and not desirable - I won't give my private key to my ITSP, no, never. Thus, it should be sufficient that the hostname matches the identity inthe certificate. > + add details and pointers to the use of RFC 4474 > inter-domain. > > ==> open questions: > These are best current practices that should be followed. We can > either reference the work-in-progress IDs or paste some of the most > relevant text and then refer to the I-Ds. > > REFERENCEs: > - Rohan's direct peering draft > http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct-peering-0 > 0.txt, > - Vijay's > http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: draft which become RFC can be referenced. Drafts which will not become RFCs should be reused. > > --- 6. A session peering policy SHOULD include details on SIP session > establishment over TLS (see above, to be briefly summarized1111). > > > --- Open questions: > - should we re-iterate the requirement of RFC 4474 that self-signed > certs should not be trusted unless prior key exchange has occurred? IMO self-signed certificates are not different to certificates signed by 3rd parties - you have to trust the CA. Thus, usually self-signed certificates are not signed by the certificate owner, but by the peer which authenticates. > Given the goals of speermint, should there be more guidance on the use > of self-signed certs? IMO yes, because this confuses people a lot. > - should there be a minimum set of ciphersuites to recommend or leave it > open? IMO I would leave it open. Are there similar requirements for https ....? AFAIK not, but it works. > > > Is this on the right track and what folks had in mind? Yes, this is the right track. thanks klaus > > Comments and input are appreciated. > Jean-Francois. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 11:56:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2AJ-0003US-Um; Mon, 23 Oct 2006 11:56:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2AI-0003UN-KI for speermint@ietf.org; Mon, 23 Oct 2006 11:56:38 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2AD-0003ra-SY for speermint@ietf.org; Mon, 23 Oct 2006 11:56:38 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 90438; Mon, 23 Oct 2006 16:56:32 +0100 In-Reply-To: <20061023150910.GT19113@nic.at> References: <072C5B76F7CEAB488172C6F64B30B5E30218BDAE@xmb-rtp-20b.amer.cisco.com> <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> <20061023150910.GT19113@nic.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98F1192D-377F-44E7-A885-14414B1897E2@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Date: Mon, 23 Oct 2006 16:56:32 +0100 To: Otmar Lendl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: speermint@ietf.org Subject: [Speermint] Public SIP Peering databases X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 23, 2006, at 16:09, Otmar Lendl wrote: > It's done for IP transit/peering. Just have a look at the RIR's > routing > registries. e.g. have a look at what's public for MCI EMEA: Er, what's in the RIR databases for routing entries doesn't necessarily reflect how ISPs actually route packets and do peering in reality. Whether any discrepancies are due to lack of clue, insufficient engineering resources, laziness, incompetence or security through obscurity is for others to decide. [And before anyone from MCI takes offence, I'm not implying that the public routing data they publish in the RIPE NCC database is inaccurate.] BTW, RIPE53 had an interesting talk on the accuracy of peering info in the RIPE NCC database. It's at: http://www.ripe.net/ripe/meetings/ripe-53/presentations/ irr_analysis_services.pdf I suspect you'd get the same types of discrepancies if the RIRs (or any comparable "neutral" organisation) maintained a (voluntary?) database of SIP peering arrangements. Some SIP providers would get it 100% right, others less so. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Dy-00089O-6Q; Mon, 23 Oct 2006 12:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Dx-00089G-6W for speermint@ietf.org; Mon, 23 Oct 2006 12:00:25 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2Du-0004Ux-UA for speermint@ietf.org; Mon, 23 Oct 2006 12:00:25 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id E1F8C21002A; Mon, 23 Oct 2006 18:00:18 +0200 (CEST) Message-ID: <453CE719.5040001@pernau.at> Date: Mon, 23 Oct 2006 18:00:25 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Reinaldo Penno Subject: Re: [Speermint] TLS related requirements for speermint ID References: <9BD5D7887235424FA97DFC223CAE3C2805EDCE71@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805EDCE71@proton.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: speermint@ietf.org, vkg@bell-labs.com X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reinaldo Penno wrote: > Hello Jean, > > For TLS specifically, isn't it better just to say peers should follow > RFC4346 (or 2246) it they want implement TLS? Is there a need to say > that peers need to agree on a port?! This is a built-in requirement for > DNS/ENUM, SIP, and any layer 4 protocol out there. Do not take it the > wrong way but it seems stating the obvious. IMO it makes sense to define a TLS port overruling the default (rfc3263) port - e.g. if you need to present different certificates to different peers you need different sockets. Using "portoverride" allows it to redirect certain peers to certain ports. > As for the more security related things, TLS already have built-in > capabilities for cipher negotiation and mutual-challenge. If something > fails they will get an error saying "negoiation failed", "cipher suite > invalid", or something like it. Specifying the minimum set of cipher > suites is a slippery slope (remember the minimum codec thread...). > > It _seems_ to me we are compensating the general lack of TLS > understanding by trying to summarize the most basic TLS requirements. > IMHO we should only mention those things that somebody after reading the > RFCs and/or going through a basic server-server configuration process > cannot figure out. TLS guidelines are very important because the standards are not enough (as drafts like draft-gurbani-sip-domain-certs proove). > > A "list of trusted root CAs" is something less obvious and specific to > peering. I'm sure there are others. I thought these are the settings for dedicated peering policies - e.g. bilateral or federation peering. Then IMO it makes sense to tell the peers that they should agree on a CA. regards klaus > > Regards, > > Reinaldo > >>> --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed >>> upon as part of session peering policies: >>> + The version of TLS (TLSv1, TLSv1.1) >>> + The SIP TLS port (default 5061) >>> + The server-side session timeout (default 300 seconds) >>> + The list of supported or recommended ciphersuite >>> + list of trusted root CAs > >> -----Original Message----- >> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] >> Sent: Thursday, October 19, 2006 8:37 AM >> To: Michael Hammer (mhammer); speermint@ietf.org >> Cc: vkg@bell-labs.com >> Subject: RE: [Speermint] TLS related requirements for speermint ID >> >> Mike, >> >> Thanks for the comments. >> >> Mike wrote: >>> This looks to be a good start. >>> >>> Re: self-signed certs >>> >>> If bi-lateral, possible manual setups are considered, you >> might also >>> look at the possibility that the two parties simply >> cross-certify each >>> other. >>> >>> A signs a certificate for B and >>> B signs a certificate for A >> Do we consider these as part of best current practices or >> even something worth logging in a requirement doc? >> I originally wondered whether we should mention this. Folks >> will do this anyway and it keeps re-inforcing the small >> clubs/federation models with limited scale as opposed to >> open, flexible and dynamic peering. >> >> That said, I'm open to adding a sentence to mention this case >> if folks believe it should be explicitly captured as a possibility. >> >>> The end result would then just be a much shorter >> certificate path to >>> follow, while leaving the general process for validation the same. >> Jean-Francois. >> >>> Mike >>> >>> >>> >>>> -----Original Message----- >>>> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] >>>> Sent: Tuesday, October 17, 2006 11:38 AM >>>> To: speermint@ietf.org >>>> Cc: vkg@bell-labs.com >>>> Subject: [Speermint] TLS related requirements for speermint ID >>>> >>>> All, >>>> >>>> --- pre-amble >>>> At the interim meeting, we had a consensus that the goal of the >>>> requirement document is not to mandate the use of any protocol >>>> mechanisms, but when those mechanisms are in use, we >> should describe >>>> what's required to guarantee some levels of interoperability. >>>> While the focus of this msg is TLS, it was also noted that other >>>> mechanisms intended to secure the lower layers of session peering >>>> like IPSec or L2/L3VPNs may exist or co-exist with L5 session >>>> security based on the threat models, keying exchange capabilities >>>> and trust relationships... FFS based on threat model. >>>> (just wanted to note upfront this so that the thread does not >>> deviate) >>>> --- TLS: >>>> At the wg's interim meeting, folks thought it would be >> good to add >>>> more details on what's required for 2 VSP/ASPs to "turn >> on" or use >>>> TLS (if/when it is enabled). The comment was that the >>>> BCP/requirement draft should go a level deeper than just saying >>>> "MUST support TLS". >>>> >>>> Here is some very first text to propose some directions. >> This is for >>>> review based on the SIP and SIPPING work on Identity, use of TLS, >>>> and the 2 I-Ds from Rohan and Vijay referenced below. >>>> >>>> The intent here is to capture what 2 VSPs/ASPs should discuss and >>>> agree on in order to establish a TLS connection for sip session >>>> peering (pending the threat analysis document). >>>> >>>> >>>> --- 1. Peers SHOULD mutually trust each other's root CAs >>>> - Motivations: >>>> A VSP/ASP should have control over which root CA it >> trusts; this may >>>> imply creating a certificate trust list to include the >> peer's CA for >>>> each authorized domain. >>>> This requirement allows for the initiating side to verify >> that the >>>> server cert is rooted in a well-known CA. >>>> - Derivative requirement: >>>> SIP servers SHOULD allow the configuration of certificate trust >>>> lists in order to allow a VSP/ASP to control which peer's CAs are >>>> trusted for TLS connections. >>>> >>>> --- 2. Peers SHOULD indicate whether their domain >> policies require >>>> proxy servers to inspect and verify the identity provided in SIP >>>> requests per RFC 4474. >>>> >>>> --- 3. When TLS is used between peers, SIP servers >> involved in the >>>> session establishment MUST have valid X.509 certificates >> and MUST be >>>> able to receive a TLS connection. >>>> >>>> Motivations: >>>> If TLS is supported for session peering, SIP servers must >> have valid >>>> X.509 certificates and they should listen on the SIP TLS port for >>>> incoming connections. >>>> >>>> --- 4. The following TLS/SIP Protocol parameters SHOULD be agreed >>>> upon as part of session peering policies: >>>> + The version of TLS (TLSv1, TLSv1.1) >>>> + The SIP TLS port (default 5061) >>>> + The server-side session timeout (default 300 seconds) >>>> + The list of supported or recommended ciphersuite >>>> + list of trusted root CAs >>>> >>>> >>>> --- 5. SIP entities involved in the session establishment >> exchanges >>>> MUST follow the following requirements: >>>> + check certs : >>>> "the client certificate MUST contain a DNS or URI choice >> type in the >>>> subjectAltName which corresponds to the domain asserted >> in the host >>>> production of the From header URI." >>>> (from Rohan's I-D) >>>> + check identity in cert per section 4 of >>>> >> http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt? >>>> + add details and pointers to the use of RFC >>>> 4474 inter-domain. >>>> >>>> ==> open questions: >>>> These are best current practices that should be followed. >>>> We can either reference the work-in-progress IDs or paste some of >>>> the most relevant text and then refer to the I-Ds. >>>> >>>> REFERENCEs: >>>> - Rohan's direct peering draft >>>> http://tools.ietf.org/wg/speermint/draft-mahy-speermint-direct >>>> -peering-0 >>>> 0.txt, >>>> - Vijay's >>>> >> http://tools.ietf.org/wg/sip/draft-gurbani-sip-domain-certs-03.txt: >>>> --- 6. A session peering policy SHOULD include details on SIP >>>> session establishment over TLS (see above, to be briefly >>>> summarized1111). >>>> >>>> >>>> --- Open questions: >>>> - should we re-iterate the requirement of RFC 4474 that >> self-signed >>>> certs should not be trusted unless prior key exchange has >> occurred? >>>> Given the goals of speermint, should there be more >> guidance on the >>>> use of self-signed certs? >>>> - should there be a minimum set of ciphersuites to recommend or >>>> leave it open? >>>> >>>> >>>> Is this on the right track and what folks had in mind? >>>> >>>> Comments and input are appreciated. >>>> Jean-Francois. >>>> >>>> >>>> _______________________________________________ >>>> 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 -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Ei-0008Md-Ft; Mon, 23 Oct 2006 12:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Eh-0008MQ-IS for speermint@ietf.org; Mon, 23 Oct 2006 12:01:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2Ee-0004b7-FH for speermint@ietf.org; Mon, 23 Oct 2006 12:01:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Oct 2006 09:01:07 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NG18LA021818; Mon, 23 Oct 2006 12:01:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NG17DO004295; Mon, 23 Oct 2006 12:01:07 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 12:01:07 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 12:01:06 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C0A3@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQ From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 23 Oct 2006 16:01:07.0567 (UTC) FILETIME=[7351E7F0:01C6F6BC] DKIM-Signature: a=rsa-sha1; q=dns; l=4728; t=1161619268; x=1162483268; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Otmar=20Lendl=22=20, =20=22Richard=20Shockey=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=LHkvqXHE4MnPm//WbsKeEGDRMg1WmQtv+LLhBOTNh8Mi7CnLTihq81sDng0/VDKbxSYlq+Qm EYCMdzcp6yAvv233ZmnXSjabdZCtA6h5LtOvYKlFm6ycVI70mE+unNyT; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Concerning de-regulation: If a group were to try to keep the system closed and certain call routing information private, whether intentionally or unintentionally to raise barriers to competition; I think the regulators would feel compelled to step in and make such call routing information publicly available. So, if you want to keep the regulators idle, design the system so that any VSP that can reliably authenticate themselves can take the sequence of steps that leads them to the ingress points and allows them to deliver calls to another VSP. The key is having secure controls versus having static clubs. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Monday, October 23, 2006 11:40 AM > To: Richard Shockey > Cc: speermint@ietf.org; 'Nieminen Klaus' > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On 2006/10/23 17:10, Richard Shockey wrote: > >=20 > > > There are several arguments why carriers will never put=20 > there TNs in=20 > > > public ENUM trees, e.g.: > > > - "Carriers are afraid that others can query how many=20 > > > numbers(customers) they have." > > > - "Carriers are afraid that other carriers can find out=20 > the current=20 > > > carrier-of-record of an enterprise and to poach this customer" > >=20 > > Both of these arguments as you mention are completely specious..=20 >=20 > We know. Klaus just quoted what we sometimes hear from carriers.=20 > You know, they don't always make sense. >=20 > > > maybe others can tell us why carriers never will put=20 > there numbers=20 > > > into public infrastructure ENUM? > >=20 > >=20 > > The real reason carriers will never put their numbers into=20 > any form of=20 > > public infrastructure ENUM is two fold. > >=20 > > A. Only a mad man would put the location of critical VoIP ingress=20 > > elements edge or otherwise into a public DNS infrastructure. The=20 > > potential for DDoS alone is massive. >=20 > Agreed. That's the reason we developed the domain policy DDDS=20 > proposal which can used to really de-couple the URI from the=20 > ingress elements.=20 > E.g. if the only things you can learn from the public DNS is=20 > that example.com is a member of federation X and Y, and uses=20 >=20 > fedx-ingress.example.com A 10.0.0.42 >=20 > and >=20 > fedy-ingress.example.com A 172.27.10.10 >=20 > as the ingress elements on the respective shared L3=20 > infrastructure then I don't see the DDoS potential here. >=20 > > B. Infrastructure ENUM as it has been proposed almost guarantees=20 > > national regulatory delegation and oversight and most=20 > carriers are in=20 > > favor of DE-Regulation of telecom not RE-Regulation. >=20 > Wait a second: you're now switching from the issue of a=20 > public tree to the question of whether that should be a=20 > NRA-approved one under ie164.arpa. >=20 > If the regulator proves to be a burden in all this, then=20 > nothing stops an industry consortium to establish a tree=20 > under a different apex. (As the forest of trees out there shows.) >=20 > > C. Some form of trusted registry of TN 2 URI mappings is absolutely=20 > > necessary to insure interoperability but I suspect it will=20 > be carriers=20 > > them selves that attempt to control the organization and=20 > distribution=20 > > of such data. >=20 > Oh yes. Who argued against the carriers establishing a such a tree? >=20 > IMHO the best case is if the regulators *and* the carries=20 > agree on someone who runs that trusted registry. Whether that=20 > will then be a private tree or a public one, is an=20 > independent question. >=20 > Given the fact that the number of "carriers" is bound to=20 > increase and international resolution of TN->URI will be an=20 > issue, I doubt that it will be easy to establish a sensible,=20 > universal rule which describes who should have access to that=20 > private tree. >=20 > Once the number of organizations which have access to a=20 > private tree exceeds as certain number, the security benefits=20 > you get from keeping it non-public are dwarfed by the=20 > complexities of maintaining access control rules. >=20 > Or, as other events prove every now and then, the PSTN method=20 > of maintaining security ("trust all other carriers") is=20 > already breaking down right now. So why perpetuate that model? >=20 > It's just case of security by obscurity. >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Tm-0005ev-5o; Mon, 23 Oct 2006 12:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Tk-0005ep-Tk for speermint@ietf.org; Mon, 23 Oct 2006 12:16:44 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2Ti-0007GK-Du for speermint@ietf.org; Mon, 23 Oct 2006 12:16:44 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 1747D1A379; Mon, 23 Oct 2006 18:16:41 +0200 (CEST) Date: Mon, 23 Oct 2006 18:16:40 +0200 From: Otmar Lendl To: Jim Reid Subject: Re: [Speermint] Public SIP Peering databases Message-ID: <20061023161640.GV19113@nic.at> Mail-Followup-To: Otmar Lendl , Jim Reid , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E30218BDAE@xmb-rtp-20b.amer.cisco.com> <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> <20061023150910.GT19113@nic.at> <98F1192D-377F-44E7-A885-14414B1897E2@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98F1192D-377F-44E7-A885-14414B1897E2@rfc1035.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/10/23 17:10, Jim Reid wrote: > On Oct 23, 2006, at 16:09, Otmar Lendl wrote: > > >It's done for IP transit/peering. Just have a look at the RIR's > >routing > >registries. e.g. have a look at what's public for MCI EMEA: > > Er, what's in the RIR databases for routing entries doesn't > necessarily reflect how ISPs actually route packets and do peering in > reality. Yes, it isn't an operational database, though some people use (or at least used) the data contained therein as the input to AS path / prefix filters. Nevertheless I think the RIR databases show that the network does not break down if the peering/upstream information is public. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:19:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Wg-0006Aq-Rg; Mon, 23 Oct 2006 12:19:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Wg-0006Al-2I for speermint@ietf.org; Mon, 23 Oct 2006 12:19:46 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2WM-0007fM-TI for speermint@ietf.org; Mon, 23 Oct 2006 12:19:46 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9NGJREm015474; Mon, 23 Oct 2006 09:19:34 -0700 From: "Richard Shockey" To: "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 12:19:11 -0400 Message-ID: <044301c6f6be$fae182a0$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C0A3@xmb-rtp-20b.amer.cisco.com> Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAADsAtA= X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 12:01 PM > To: Otmar Lendl; Richard Shockey > Cc: speermint@ietf.org; Nieminen Klaus > Subject: RE: [Speermint] Basic Peering Requirements > > Concerning de-regulation: > > If a group were to try to keep the system closed and certain call > routing information private, whether intentionally or unintentionally to > raise barriers to competition; I think the regulators would feel > compelled to step in and make such call routing information publicly > available. Now you are really waist deep in it ... what country are you living in :-) ? Obviously you do not live in the proximity of US 495 aka the "Beltway". > > So, if you want to keep the regulators idle, design the system so that > any VSP that can reliably authenticate themselves can take the sequence > of steps that leads them to the ingress points and allows them to > deliver calls to another VSP. The key is having secure controls versus > having static clubs. > > Mike > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2np-0002nR-Tk; Mon, 23 Oct 2006 12:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2nm-0002kC-C8 for speermint@ietf.org; Mon, 23 Oct 2006 12:37:26 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2g7-0000Jk-Ss for speermint@ietf.org; Mon, 23 Oct 2006 12:29:33 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 8C54E2100D2; Mon, 23 Oct 2006 18:29:27 +0200 (CEST) Message-ID: <453CEDEE.1060204@pernau.at> Date: Mon, 23 Oct 2006 18:29:34 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" Subject: Re: [Speermint] Basic Peering Requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Dwight, Timothy M (Tim) wrote: > Finally this issue is raised... > >> Of course, the fundamental problem remains you assume you >> know the termination domain. I don't think you can figure >> that out when you start with a TN unless all TNs are in a >> public database. > > I too wonder how this can be done on a global basis. The mapping from TN to domain, and domain to ingress point are 2 different, orthogonal tasks. And there are different solution for both of them. e.g. for TN->domain there is user ENUM, infrastructure ENUM, private ENUM trees, lookup tables, number portability databases, ... for domain->ingress points there is RFC 3263, federation defined lookup rules, lookup tables, lookup in private DNS trees (e.g. 3GPP GRX), ... of course both steps can be performed in a blackbox operated by a 3rd party - but as this are 2 separated problem there should be 2 separated solutions. -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2q1-0004Oi-OH; Mon, 23 Oct 2006 12:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2q0-0004N4-B4 for speermint@ietf.org; Mon, 23 Oct 2006 12:39:44 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2py-0002Ai-UB for speermint@ietf.org; Mon, 23 Oct 2006 12:39:44 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9NGdYiL019613; Mon, 23 Oct 2006 09:39:40 -0700 From: "Richard Shockey" To: "'Otmar Lendl'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 12:39:21 -0400 Message-ID: <045901c6f6c1$cbd08800$75201f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <20061023154006.GU19113@nic.at> Thread-Index: Acb2uY/iHLKMuw55QDmfYLg4NhEEkQABW0HA X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: speermint@ietf.org, 'Nieminen Klaus' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > B. Infrastructure ENUM as it has been proposed almost guarantees > national regulatory delegation and oversight and most carriers are in favor of DE-Regulation of telecom not RE-Regulation. > > Wait a second: you're now switching from the issue of a public tree > to the question of whether that should be a NRA-approved one under > ie164.arpa. I'd much prefer to look at the whole problem statements as query vs cache using trusted registries. Trees imply distributed databases. I'm not sure that is how this all might play out. I only become clairvoyant after the 2nd beer. I suggest we may have internal cached databases that are fed via out of band mechanisms by trusted registries. If there is a public tree under ie164.arpa you can guarantee it will be NRA approved and regulated as is e164.arpa. Of course a mutually agreed private tree or domain would not have that problem. Here I'm taking a very US Canadian centric view but I do wonder if TN to URI mappings are essentially no different from the classic PSTN merger of trusted registries we have in the US. TN routing = NPAC + LERG cached into SCP's. What then would be the difference between TN routing = NPAC + LERG + TN2URI cached into IP-SCP's ( aka big fat cached DNS servers). There are products on the market that do this stuff I'm told. > > If the regulator proves to be a burden in all this, then nothing > stops an industry consortium to establish a tree under a different > apex. (As the forest of trees out there shows.) True ..public or private. Which BTW argues for multiple trees or databases being the likely short term outcome for TN 2 URI translations. > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > necessary to insure interoperability but I suspect it will be carriers > them> > selves that attempt to control the organization and distribution of such data. > > Oh yes. Who argued against the carriers establishing a such a tree? > > IMHO the best case is if the regulators *and* the carries agree on someone > who runs that trusted registry. Whether that will then be a private > tree or a public one, is an independent question. We're in violent agreement Remember .. once you have accepted that a trusted registry ( IMHO probably nationally based ) that is the key component then how the data is distributed is a secondary. Hence the heretical statement, "Is ENUM Irrelevant?" In that case simply deliver cached copies of the registries's database to the carrier's internal "Service Control Database" and you are done. Data for number ranges outside the scope of the cached database can be handled by ancillary routing databases (Global Title Translation? Humm). > > Given the fact that the number of "carriers" is bound to increase and > international resolution of TN->URI will be an issue, I doubt that > it will be easy to establish a sensible, universal rule which > describes who should have access to that private tree. If there is a tree at all. > Once the number of organizations which have access to a private tree > exceeds as certain number, the security benefits you get from > keeping it non-public are dwarfed by the complexities of maintaining > access control rules. > > Or, as other events prove every now and then, the PSTN method of > maintaining security ("trust all other carriers") is already breaking > down right now. So why perpetuate that model? > > It's just case of security by obscurity. Better than no security at all I might add. > > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 12:55:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc34R-0008Pa-2n; Mon, 23 Oct 2006 12:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc34P-0008PS-NF for speermint@ietf.org; Mon, 23 Oct 2006 12:54:37 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc34O-0004nv-Bl for speermint@ietf.org; Mon, 23 Oct 2006 12:54:37 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 90450; Mon, 23 Oct 2006 17:54:35 +0100 In-Reply-To: <20061023161640.GV19113@nic.at> References: <072C5B76F7CEAB488172C6F64B30B5E30218BDAE@xmb-rtp-20b.amer.cisco.com> <017101c6f48b$f6804230$640fa8c0@cis.neustar.com> <20061023150910.GT19113@nic.at> <98F1192D-377F-44E7-A885-14414B1897E2@rfc1035.com> <20061023161640.GV19113@nic.at> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Speermint] Public SIP Peering databases Date: Mon, 23 Oct 2006 17:54:34 +0100 To: Otmar Lendl X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 23, 2006, at 17:16, Otmar Lendl wrote: > Nevertheless I think the RIR databases show that the network does > not break down if the peering/upstream information is public. True, but this is a false analogy Otmar. The internet has traditionally always been open about operational data: IP addresses, domain names, AS numbers, routing objects, etc. Telephony hasn't. Simply telling telcos and other SIP providers that the sky won't fall in if they publish their SIP peering policies isn't going to convince them to do that. Some of their concerns are justified IMO -- eg potential for DDoS attacks on ingress points. Others are layer-9 problems that should probably be out of scope for the IETF. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 13:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3Hx-0005mU-1s; Mon, 23 Oct 2006 13:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3Hw-0005mP-Gh for speermint@ietf.org; Mon, 23 Oct 2006 13:08:36 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc3Hr-0007IY-Eh for speermint@ietf.org; Mon, 23 Oct 2006 13:08:36 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J7L00085MA5D6@firewall.mci.com> for speermint@ietf.org; Mon, 23 Oct 2006 17:08:30 +0000 (GMT) Received: from dgismtp05.wcomnet.com ([127.0.0.1]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0J7L00BHHMA6VU@dgismtp05.mcilink.com> for speermint@ietf.org; Mon, 23 Oct 2006 17:08:30 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([153.39.68.165]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0J7L00B1XMA6Y3@dgismtp05.mcilink.com> for speermint@ietf.org; Mon, 23 Oct 2006 17:08:30 +0000 (GMT) Received: from ASHEVS010.mcilink.com ([153.39.69.135]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 17:08:29 +0000 Date: Mon, 23 Oct 2006 17:07:44 +0000 From: "Dwight, Timothy M (Tim)" Subject: RE: [Speermint] Basic Peering Requirements In-reply-to: <453CEDEE.1060204@pernau.at> To: Klaus Darilion Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Speermint] Basic Peering Requirements Thread-index: Acb2wHLpfICefsfoRL63qvNbjzQKHQAAdieA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 Oct 2006 17:08:29.0851 (UTC) FILETIME=[DCB57EB0:01C6F6C5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Klaus,=20 > Dwight, Timothy M (Tim) wrote: > > Finally this issue is raised...=20 > >=20 > >> Of course, the fundamental problem remains you assume you know the=20 > >> termination domain. I don't think you can figure that out when you > >> start with a TN unless all TNs are in a public database. > >=20 > > I too wonder how this can be done on a global basis. >=20 > The mapping from TN to domain, and domain to ingress point=20 > are 2 different, orthogonal tasks. And there are different=20 > solution for both of them. >=20 > e.g. for TN->domain there is user ENUM, infrastructure ENUM,=20 > private ENUM trees, lookup tables, number portability databases, ... I agree that the act of mapping a TN to a domain is straight-forward. The problem I worry about is doing this on a global scale. As Brian notes, a theoretical solution is for all TNs (and the identify of the SPs providing services to them) to be in a public database. That would solve the routing problem but raises other concerns (e.g., administrative, regulatory, privacy). =20 Obviously there are a couple of approaches in play. One assumes that such a public database will emerge. The other assumes that it will not, or will not soon, and attempts to stitch together some functional equivalent out of a set of private databases.=20 The gist of my comment is that solutions to the second problem, while interesting to contemplate, are not implementable without a real solution to the first problem. =20 tim _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 13:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3re-00087d-8Q; Mon, 23 Oct 2006 13:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3rc-00083G-HF for speermint@ietf.org; Mon, 23 Oct 2006 13:45:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc3rX-0003ch-Gc for speermint@ietf.org; Mon, 23 Oct 2006 13:45:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gc3rF-0005bV-DX; Mon, 23 Oct 2006 12:45:05 -0500 From: "Brian Rosen" To: "'Klaus Darilion'" , "'Dwight, Timothy M \(Tim\)'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 13:45:04 -0400 Message-ID: <07cb01c6f6ca$fd922d40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2wGcR5FyJxifGRKW0i3q7ITnvmQACdv+g In-Reply-To: <453CEDEE.1060204@pernau.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > The mapping from TN to domain, and domain to ingress point are 2 > different, orthogonal tasks. And there are different solution for both > of them. > > e.g. for TN->domain there is user ENUM, infrastructure ENUM, private > ENUM trees, lookup tables, number portability databases, ... > Klaus, that is rewriting history. ENUM is TN to URI, not domain. It was intended that the URI be the place the call was sent to, period. If we were to get a domain, then it wouldn't be a NAPTR, right? The ingress point thing is an add-on. You are suggestion that we rewrite the ENUM documents to describe what you get out of ENUM as a domain, and then there is another step you want to add that is domain to URI. Furthermore, you really want 3 steps, right? TN to domain, domain to federation, federation to ingress point. You have to do that; ingress point is definitely dependent on origination side, and thus both the peer and the federation who is sending the destination the call. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 14:35:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4dP-0002Vv-9r; Mon, 23 Oct 2006 14:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4dM-0002Vb-JR for speermint@ietf.org; Mon, 23 Oct 2006 14:34:48 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc4cz-00014I-LU for speermint@ietf.org; Mon, 23 Oct 2006 14:34:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gc4cm-0007fZ-3M; Mon, 23 Oct 2006 13:34:12 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 14:34:16 -0400 Message-ID: <07da01c6f6d1$da543fb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C0A3@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Well, here in the U.S., the stated reluctance of the regulator to permit TNs in a public database is due to the fact that people's telephone numbers would be in a public database. They are concerned with the privacy aspects of the problem. So, they actually WANT private databases where people's telephone numbers are concerned. And this concern started in User ENUM, not just infrastructure ENUM. I understand there are other regulators who have this concern. I do think there is some validity to your concern about one carrier, or a group of carriers, restricting access to their customers for termination from other carriers, and I agree the regulators would probably not allow it. Making routing data public has not yet been, and I don't think will be, the remedy. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 12:01 PM > To: Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Concerning de-regulation: > > If a group were to try to keep the system closed and certain call > routing information private, whether intentionally or unintentionally to > raise barriers to competition; I think the regulators would feel > compelled to step in and make such call routing information publicly > available. > > So, if you want to keep the regulators idle, design the system so that > any VSP that can reliably authenticate themselves can take the sequence > of steps that leads them to the ingress points and allows them to > deliver calls to another VSP. The key is having secure controls versus > having static clubs. > > Mike > > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Monday, October 23, 2006 11:40 AM > > To: Richard Shockey > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > Subject: Re: [Speermint] Basic Peering Requirements > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > There are several arguments why carriers will never put > > there TNs in > > > > public ENUM trees, e.g.: > > > > - "Carriers are afraid that others can query how many > > > > numbers(customers) they have." > > > > - "Carriers are afraid that other carriers can find out > > the current > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > Both of these arguments as you mention are completely specious.. > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > You know, they don't always make sense. > > > > > > maybe others can tell us why carriers never will put > > there numbers > > > > into public infrastructure ENUM? > > > > > > > > > The real reason carriers will never put their numbers into > > any form of > > > public infrastructure ENUM is two fold. > > > > > > A. Only a mad man would put the location of critical VoIP ingress > > > elements edge or otherwise into a public DNS infrastructure. The > > > potential for DDoS alone is massive. > > > > Agreed. That's the reason we developed the domain policy DDDS > > proposal which can used to really de-couple the URI from the > > ingress elements. > > E.g. if the only things you can learn from the public DNS is > > that example.com is a member of federation X and Y, and uses > > > > fedx-ingress.example.com A 10.0.0.42 > > > > and > > > > fedy-ingress.example.com A 172.27.10.10 > > > > as the ingress elements on the respective shared L3 > > infrastructure then I don't see the DDoS potential here. > > > > > B. Infrastructure ENUM as it has been proposed almost guarantees > > > national regulatory delegation and oversight and most > > carriers are in > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > Wait a second: you're now switching from the issue of a > > public tree to the question of whether that should be a > > NRA-approved one under ie164.arpa. > > > > If the regulator proves to be a burden in all this, then > > nothing stops an industry consortium to establish a tree > > under a different apex. (As the forest of trees out there shows.) > > > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > > necessary to insure interoperability but I suspect it will > > be carriers > > > them selves that attempt to control the organization and > > distribution > > > of such data. > > > > Oh yes. Who argued against the carriers establishing a such a tree? > > > > IMHO the best case is if the regulators *and* the carries > > agree on someone who runs that trusted registry. Whether that > > will then be a private tree or a public one, is an > > independent question. > > > > Given the fact that the number of "carriers" is bound to > > increase and international resolution of TN->URI will be an > > issue, I doubt that it will be easy to establish a sensible, > > universal rule which describes who should have access to that > > private tree. > > > > Once the number of organizations which have access to a > > private tree exceeds as certain number, the security benefits > > you get from keeping it non-public are dwarfed by the > > complexities of maintaining access control rules. > > > > Or, as other events prove every now and then, the PSTN method > > of maintaining security ("trust all other carriers") is > > already breaking down right now. So why perpetuate that model? > > > > It's just case of security by obscurity. > > > > /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 From speermint-bounces@ietf.org Mon Oct 23 14:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4nN-0003o1-Hr; Mon, 23 Oct 2006 14:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc4nL-0003nv-On for speermint@ietf.org; Mon, 23 Oct 2006 14:45:07 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc4mw-00026E-JF for speermint@ietf.org; Mon, 23 Oct 2006 14:45:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gc4mj-00047F-VL; Mon, 23 Oct 2006 13:44:30 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 14:44:34 -0400 Message-ID: <07e301c6f6d3$4ab66e80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZLdcF47ouqeRIWSWcYYVBK7KAAGFZDA In-Reply-To: <20061023154006.GU19113@nic.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org As I said many times before, I deal with reality. The Internet grew up in an open environment, where addressing data was public. As it matures, the commercial aspects, coupled with some legitimate security concerns, have driven some address information less public. I am not a believer in security by obscurity, but I'm a realist that addressing data is increasingly NOT public. Addressing data in the phone networks have never been public. There is little incentive to make them completely public, but because there are a larger number of "carriers" of different sorts springing up, it's less private than it used to be, and merging Internet and PSTN technologies has lead to more information being public. However, the evidence I see says that the carriers want addressing data private. I think that means that what you are proposing is likely to be unacceptable. It doesn't matter if I think it ought to be acceptable, I just don't think it is. There are a lot of ways to prevent access to an IP address, even if you know that address. Making an address public is not equivalent to providing public access to that address. You can put the actual data in a public database, but restrict access to only those entities you want to have access. What I see happening is both security by obscurity of (all of) the addressing data, AND filtering, VPNs, and private address space that prohibit access even if you gained access to the private data. Brian > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Monday, October 23, 2006 11:40 AM > To: Richard Shockey > Cc: speermint@ietf.org; 'Nieminen Klaus' > Subject: Re: [Speermint] Basic Peering Requirements > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > There are several arguments why carriers will never put there TNs in > > > public ENUM trees, e.g.: > > > - "Carriers are afraid that others can query how many > numbers(customers) > > > they have." > > > - "Carriers are afraid that other carriers can find out the current > > > carrier-of-record of an enterprise and to poach this customer" > > > > Both of these arguments as you mention are completely specious.. > > We know. Klaus just quoted what we sometimes hear from carriers. > You know, they don't always make sense. > > > > maybe others can tell us why carriers never will put there numbers > into > > > public infrastructure ENUM? > > > > > > The real reason carriers will never put their numbers into any form of > > public infrastructure ENUM is two fold. > > > > A. Only a mad man would put the location of critical VoIP ingress > elements > > edge or otherwise into a public DNS infrastructure. The potential for > DDoS > > alone is massive. > > Agreed. That's the reason we developed the domain policy DDDS proposal > which can used to really de-couple the URI from the ingress elements. > E.g. if the only things you can learn from the public DNS is that > example.com is a member of federation X and Y, and uses > > fedx-ingress.example.com A 10.0.0.42 > > and > > fedy-ingress.example.com A 172.27.10.10 > > as the ingress elements on the respective shared L3 infrastructure then > I don't see the DDoS potential here. > > > B. Infrastructure ENUM as it has been proposed almost guarantees > national > > regulatory delegation and oversight and most carriers are in favor of > > DE-Regulation of telecom not RE-Regulation. > > Wait a second: you're now switching from the issue of a public tree > to the question of whether that should be a NRA-approved one under > ie164.arpa. > > If the regulator proves to be a burden in all this, then nothing > stops an industry consortium to establish a tree under a different > apex. (As the forest of trees out there shows.) > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > necessary to insure interoperability but I suspect it will be carriers > them > > selves that attempt to control the organization and distribution of such > > data. > > Oh yes. Who argued against the carriers establishing a such a tree? > > IMHO the best case is if the regulators *and* the carries agree on someone > who runs that trusted registry. Whether that will then be a private > tree or a public one, is an independent question. > > Given the fact that the number of "carriers" is bound to increase and > international resolution of TN->URI will be an issue, I doubt that > it will be easy to establish a sensible, universal rule which > describes who should have access to that private tree. > > Once the number of organizations which have access to a private tree > exceeds as certain number, the security benefits you get from > keeping it non-public are dwarfed by the complexities of maintaining > access control rules. > > Or, as other events prove every now and then, the PSTN method of > maintaining security ("trust all other carriers") is already breaking > down right now. So why perpetuate that model? > > It's just case of security by obscurity. > > /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 From speermint-bounces@ietf.org Mon Oct 23 15:07:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc588-0002qt-7e; Mon, 23 Oct 2006 15:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc586-0002q9-Q7 for speermint@ietf.org; Mon, 23 Oct 2006 15:06:34 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc580-00047h-67 for speermint@ietf.org; Mon, 23 Oct 2006 15:06:34 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1161630332!10151766!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 18841 invoked from network); 23 Oct 2006 19:05:32 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-9.tower-121.messagelabs.com with SMTP; 23 Oct 2006 19:05:32 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NJ5PKE027619 for ; Mon, 23 Oct 2006 15:05:32 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NIoU7H008520 for ; Mon, 23 Oct 2006 14:51:02 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C3300121372; Mon, 23 Oct 2006 14:51:00 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 14:50:58 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DEDCCEE@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <07da01c6f6d1$da543fb0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUA== From: "Pfautz, Penn L, GBLAM" To: "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org We can continue to beat this topic to death (and I'm sure we will) but I want to make one point. We need to distinguish between peering for voluntary exchange of traffic (not currently regulated at least in the US) and Peering as a replacement for legally required interconnection in the current PSTN.=20 For the former carriers (and anyone else) can and will do what they want. The latter is likely to eventually be subject to some rules. But consider also that where interconnection is mandated it comes with rules and is not open to all parties. You want to interconnect with the PSTN in the US you need to be certified; otherwise you buy end user services. BTW If you put all allocated (including unassigned) numbers in the DNS then you provide no more info than can be obtained by war dialing every legitimate sequence. =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, October 23, 2006 2:34 PM To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' Cc: 'Nieminen Klaus'; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements Well, here in the U.S., the stated reluctance of the regulator to permit TNs in a public database is due to the fact that people's telephone numbers would be in a public database. They are concerned with the privacy aspects of the problem. So, they actually WANT private databases where people's telephone numbers are concerned. And this concern started in User ENUM, not just infrastructure ENUM. I understand there are other regulators who have this concern. I do think there is some validity to your concern about one carrier, or a group of carriers, restricting access to their customers for termination from other carriers, and I agree the regulators would probably not allow it. Making routing data public has not yet been, and I don't think will be, the remedy. =20 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 12:01 PM > To: Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Concerning de-regulation: >=20 > If a group were to try to keep the system closed and certain call > routing information private, whether intentionally or unintentionally to > raise barriers to competition; I think the regulators would feel > compelled to step in and make such call routing information publicly > available. >=20 > So, if you want to keep the regulators idle, design the system so that > any VSP that can reliably authenticate themselves can take the sequence > of steps that leads them to the ingress points and allows them to > deliver calls to another VSP. The key is having secure controls versus > having static clubs. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Monday, October 23, 2006 11:40 AM > > To: Richard Shockey > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > Subject: Re: [Speermint] Basic Peering Requirements > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > There are several arguments why carriers will never put > > there TNs in > > > > public ENUM trees, e.g.: > > > > - "Carriers are afraid that others can query how many > > > > numbers(customers) they have." > > > > - "Carriers are afraid that other carriers can find out > > the current > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > Both of these arguments as you mention are completely specious.. > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > You know, they don't always make sense. > > > > > > maybe others can tell us why carriers never will put > > there numbers > > > > into public infrastructure ENUM? > > > > > > > > > The real reason carriers will never put their numbers into > > any form of > > > public infrastructure ENUM is two fold. > > > > > > A. Only a mad man would put the location of critical VoIP ingress > > > elements edge or otherwise into a public DNS infrastructure. The > > > potential for DDoS alone is massive. > > > > Agreed. That's the reason we developed the domain policy DDDS > > proposal which can used to really de-couple the URI from the > > ingress elements. > > E.g. if the only things you can learn from the public DNS is > > that example.com is a member of federation X and Y, and uses > > > > fedx-ingress.example.com A 10.0.0.42 > > > > and > > > > fedy-ingress.example.com A 172.27.10.10 > > > > as the ingress elements on the respective shared L3 > > infrastructure then I don't see the DDoS potential here. > > > > > B. Infrastructure ENUM as it has been proposed almost guarantees > > > national regulatory delegation and oversight and most > > carriers are in > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > Wait a second: you're now switching from the issue of a > > public tree to the question of whether that should be a > > NRA-approved one under ie164.arpa. > > > > If the regulator proves to be a burden in all this, then > > nothing stops an industry consortium to establish a tree > > under a different apex. (As the forest of trees out there shows.) > > > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > > necessary to insure interoperability but I suspect it will > > be carriers > > > them selves that attempt to control the organization and > > distribution > > > of such data. > > > > Oh yes. Who argued against the carriers establishing a such a tree? > > > > IMHO the best case is if the regulators *and* the carries > > agree on someone who runs that trusted registry. Whether that > > will then be a private tree or a public one, is an > > independent question. > > > > Given the fact that the number of "carriers" is bound to > > increase and international resolution of TN->URI will be an > > issue, I doubt that it will be easy to establish a sensible, > > universal rule which describes who should have access to that > > private tree. > > > > Once the number of organizations which have access to a > > private tree exceeds as certain number, the security benefits > > you get from keeping it non-public are dwarfed by the > > complexities of maintaining access control rules. > > > > Or, as other events prove every now and then, the PSTN method > > of maintaining security ("trust all other carriers") is > > already breaking down right now. So why perpetuate that model? > > > > It's just case of security by obscurity. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Mon Oct 23 15:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5o8-0000I3-Qm; Mon, 23 Oct 2006 15:50:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc5o7-00009a-B1 for speermint@ietf.org; Mon, 23 Oct 2006 15:49:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc5nj-0002BH-DD for speermint@ietf.org; Mon, 23 Oct 2006 15:49:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Oct 2006 12:48:37 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NJmap2019377; Mon, 23 Oct 2006 15:48:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9NJmZYJ006022; Mon, 23 Oct 2006 15:48:35 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 15:48:35 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 15:48:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C231@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAADsAtAAB1KVQA== From: "Michael Hammer \(mhammer\)" To: , "Otmar Lendl" X-OriginalArrivalTime: 23 Oct 2006 19:48:35.0829 (UTC) FILETIME=[3A516A50:01C6F6DC] DKIM-Signature: a=rsa-sha1; q=dns; l=1730; t=1161632916; x=1162496916; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:,=20=22Otmar=20Lendl=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=O5kuF8BIs/2UGXyMwo2gYAw9MduDuelsQ2hZPKIeYxs8v492iHQCqUY6jHkM0r2e1mdU0q7L aNllNXjwIA16yg/3V4S++5xUXe5mvH9dm1Iga3cXOfIDO2Ad59D80ov7; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org And yet Number Portability lives! Umm, I live about 7 miles from that beltway and my Congressman knows me by name and sight. And not all of them think the same way. Mike > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Monday, October 23, 2006 12:19 PM > To: Michael Hammer (mhammer); 'Otmar Lendl' > Cc: speermint@ietf.org; 'Nieminen Klaus' > Subject: RE: [Speermint] Basic Peering Requirements >=20 >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, October 23, 2006 12:01 PM > > To: Otmar Lendl; Richard Shockey > > Cc: speermint@ietf.org; Nieminen Klaus > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Concerning de-regulation: > >=20 > > If a group were to try to keep the system closed and certain call=20 > > routing information private, whether intentionally or=20 > unintentionally=20 > > to raise barriers to competition; I think the regulators would feel=20 > > compelled to step in and make such call routing information=20 > publicly=20 > > available. >=20 > Now you are really waist deep in it ... what country are you=20 > living in :-) ? >=20 >=20 > Obviously you do not live in the proximity of US 495 aka the=20 > "Beltway". >=20 >=20 >=20 > >=20 > > So, if you want to keep the regulators idle, design the=20 > system so that=20 > > any VSP that can reliably authenticate themselves can take the=20 > > sequence of steps that leads them to the ingress points and allows=20 > > them to deliver calls to another VSP. The key is having secure=20 > > controls versus having static clubs. > >=20 > > Mike > >=20 > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc654-00062n-WA; Mon, 23 Oct 2006 16:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc653-00062P-Ii for speermint@ietf.org; Mon, 23 Oct 2006 16:07:29 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc64Y-0004Yc-B0 for speermint@ietf.org; Mon, 23 Oct 2006 16:07:29 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Mon, 23 Oct 2006 13:06:47 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9NK6wIY004818; Mon, 23 Oct 2006 13:07:03 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k9NK6SeS022290; Mon, 23 Oct 2006 13:06:39 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 13:06:29 -0700 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] Public SIP Peering databases Date: Mon, 23 Oct 2006 13:02:30 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2214124C@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Public SIP Peering databases Thread-Index: Acb2xCqtJFtUixCPQ1eEwLL2WD88yAAGbWPA From: "Henry Sinnreich" To: "Jim Reid" , "Otmar Lendl" X-OriginalArrivalTime: 23 Oct 2006 20:06:29.0740 (UTC) FILETIME=[BA6B3AC0:01C6F6DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Reliving the past (using phone numbers and their regulations) is quite a trip! Henry -----Original Message----- _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc67l-00073j-AP; Mon, 23 Oct 2006 16:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc67k-00073W-G7 for speermint@ietf.org; Mon, 23 Oct 2006 16:10:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc67Q-00055C-HO for speermint@ietf.org; Mon, 23 Oct 2006 16:10:16 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 23 Oct 2006 13:09:47 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NK9kZm028205; Mon, 23 Oct 2006 13:09:46 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9NK9jbF008925; Mon, 23 Oct 2006 13:09:45 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 16:09:44 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:09:43 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C258@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABO62MA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 23 Oct 2006 20:09:44.0866 (UTC) FILETIME=[2EB91820:01C6F6DF] DKIM-Signature: a=rsa-sha1; q=dns; l=7059; t=1161634186; x=1162498186; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=OtdT3liaFeeGSRYYPxOhoGrf+BzVWbdrvSHKelLbacDyDIf1sp87QgfAMbSmr/9x3caz3Bz2 KZjLpiair+Moj82zFuXi6DiO/h1iU1c0JE3DP9WxE4DQl8mpjG7ULnrc; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, You confuse associating a TN to an ingress point used to route the call, with associating a TN to a particular end-user. The former can be accomplished without doing the latter. You conflate the two. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, October 23, 2006 2:34 PM > To: Michael Hammer (mhammer); 'Otmar Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Well, here in the U.S., the stated reluctance of the=20 > regulator to permit TNs in a public database is due to the=20 > fact that people's telephone numbers would be in a public=20 > database. They are concerned with the privacy aspects of the=20 > problem. So, they actually WANT private databases where=20 > people's telephone numbers are concerned. And this concern=20 > started in User ENUM, not just infrastructure ENUM. I=20 > understand there are other regulators who have this concern. >=20 > I do think there is some validity to your concern about one=20 > carrier, or a group of carriers, restricting access to their=20 > customers for termination from other carriers, and I agree=20 > the regulators would probably not allow it. > Making routing data public has not yet been, and I don't=20 > think will be, the remedy. =20 >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, October 23, 2006 12:01 PM > > To: Otmar Lendl; Richard Shockey > > Cc: Nieminen Klaus; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Concerning de-regulation: > >=20 > > If a group were to try to keep the system closed and certain call=20 > > routing information private, whether intentionally or=20 > unintentionally=20 > > to raise barriers to competition; I think the regulators would feel=20 > > compelled to step in and make such call routing information=20 > publicly=20 > > available. > >=20 > > So, if you want to keep the regulators idle, design the=20 > system so that=20 > > any VSP that can reliably authenticate themselves can take the=20 > > sequence of steps that leads them to the ingress points and allows=20 > > them to deliver calls to another VSP. The key is having secure=20 > > controls versus having static clubs. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Monday, October 23, 2006 11:40 AM > > > To: Richard Shockey > > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > > > There are several arguments why carriers will never put > > > there TNs in > > > > > public ENUM trees, e.g.: > > > > > - "Carriers are afraid that others can query how many > > > > > numbers(customers) they have." > > > > > - "Carriers are afraid that other carriers can find out > > > the current > > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > > > Both of these arguments as you mention are completely specious.. > > > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > > You know, they don't always make sense. > > > > > > > > maybe others can tell us why carriers never will put > > > there numbers > > > > > into public infrastructure ENUM? > > > > > > > > > > > > The real reason carriers will never put their numbers into > > > any form of > > > > public infrastructure ENUM is two fold. > > > > > > > > A. Only a mad man would put the location of critical=20 > VoIP ingress=20 > > > > elements edge or otherwise into a public DNS=20 > infrastructure. The=20 > > > > potential for DDoS alone is massive. > > > > > > Agreed. That's the reason we developed the domain policy DDDS=20 > > > proposal which can used to really de-couple the URI from=20 > the ingress=20 > > > elements. > > > E.g. if the only things you can learn from the public DNS is that=20 > > > example.com is a member of federation X and Y, and uses > > > > > > fedx-ingress.example.com A 10.0.0.42 > > > > > > and > > > > > > fedy-ingress.example.com A 172.27.10.10 > > > > > > as the ingress elements on the respective shared L3=20 > infrastructure=20 > > > then I don't see the DDoS potential here. > > > > > > > B. Infrastructure ENUM as it has been proposed almost=20 > guarantees=20 > > > > national regulatory delegation and oversight and most > > > carriers are in > > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > > > Wait a second: you're now switching from the issue of a=20 > public tree=20 > > > to the question of whether that should be a NRA-approved=20 > one under=20 > > > ie164.arpa. > > > > > > If the regulator proves to be a burden in all this, then nothing=20 > > > stops an industry consortium to establish a tree under a=20 > different=20 > > > apex. (As the forest of trees out there shows.) > > > > > > > C. Some form of trusted registry of TN 2 URI mappings is=20 > > > > absolutely necessary to insure interoperability but I=20 > suspect it=20 > > > > will > > > be carriers > > > > them selves that attempt to control the organization and > > > distribution > > > > of such data. > > > > > > Oh yes. Who argued against the carriers establishing a=20 > such a tree? > > > > > > IMHO the best case is if the regulators *and* the carries=20 > agree on=20 > > > someone who runs that trusted registry. Whether that will=20 > then be a=20 > > > private tree or a public one, is an independent question. > > > > > > Given the fact that the number of "carriers" is bound to increase=20 > > > and international resolution of TN->URI will be an issue, I doubt=20 > > > that it will be easy to establish a sensible, universal=20 > rule which=20 > > > describes who should have access to that private tree. > > > > > > Once the number of organizations which have access to a=20 > private tree=20 > > > exceeds as certain number, the security benefits you get from=20 > > > keeping it non-public are dwarfed by the complexities of=20 > maintaining=20 > > > access control rules. > > > > > > Or, as other events prove every now and then, the PSTN method of=20 > > > maintaining security ("trust all other carriers") is already=20 > > > breaking down right now. So why perpetuate that model? > > > > > > It's just case of security by obscurity. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:10:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc67z-0007IU-J4; Mon, 23 Oct 2006 16:10:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc67y-0007I0-Fa for speermint@ietf.org; Mon, 23 Oct 2006 16:10:30 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc67e-0005BW-CX for speermint@ietf.org; Mon, 23 Oct 2006 16:10:30 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 23 Oct 2006 13:07:33 -0700 X-IronPort-AV: i="4.09,343,1157353200"; d="scan'208"; a="606407028:sNHT58584108" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:10:08 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28040ACB25@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9w== References: <07da01c6f6d1$da543fb0$640fa8c0@cis.neustar.com> From: "Reinaldo Penno" To: "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I must be missing something here.=20 =20 Telephone numbers are already public in the US (they have to be). To be = de-listed you have to pay extra but law enforcement in the US are still = notified of such unlisted phones. I can get a paper telephone directory = and lookup any telephone number. I can go to Verizon's or ATT's (in the = US) home page and perform a reverse lookup and find the telephone number = associated with a name (and vice-versa). =20 So, it seems what we are talking here is not if they are public or not, = but how easy is to get them. Putting them on a database like DNS would = just make it easier (and more hackable) since they would be officially = hook up in the Internet infrastructure.=20 =20 It seems people that do not want their telephone numbers on a paper = directory, could opt out in a public database as well. =20 Since many of our speermint friends here are from Austria I tried the = same thing and after one google search and three clicks I found this = page =20 http://www.herold.at/, clicked at Telefonbuch (buch is book in english) = and presto.=20 =20 regards, =20 Reinaldo=20 =20 =20 =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Mon 10/23/2006 11:34 AM To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' Cc: 'Nieminen Klaus'; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements Well, here in the U.S., the stated reluctance of the regulator to permit = TNs in a public database is due to the fact that people's telephone numbers would be in a public database. They are concerned with the privacy = aspects of the problem. So, they actually WANT private databases where people's telephone numbers are concerned. And this concern started in User ENUM, = not just infrastructure ENUM. I understand there are other regulators who = have this concern. I do think there is some validity to your concern about one carrier, or = a group of carriers, restricting access to their customers for termination from other carriers, and I agree the regulators would probably not allow = it. Making routing data public has not yet been, and I don't think will be, = the remedy.=20 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 12:01 PM > To: Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Concerning de-regulation: > > If a group were to try to keep the system closed and certain call > routing information private, whether intentionally or unintentionally = to > raise barriers to competition; I think the regulators would feel > compelled to step in and make such call routing information publicly > available. > > So, if you want to keep the regulators idle, design the system so that > any VSP that can reliably authenticate themselves can take the = sequence > of steps that leads them to the ingress points and allows them to > deliver calls to another VSP. The key is having secure controls = versus > having static clubs. > > Mike > > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Monday, October 23, 2006 11:40 AM > > To: Richard Shockey > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > Subject: Re: [Speermint] Basic Peering Requirements > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > There are several arguments why carriers will never put > > there TNs in > > > > public ENUM trees, e.g.: > > > > - "Carriers are afraid that others can query how many > > > > numbers(customers) they have." > > > > - "Carriers are afraid that other carriers can find out > > the current > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > Both of these arguments as you mention are completely specious.. > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > You know, they don't always make sense. > > > > > > maybe others can tell us why carriers never will put > > there numbers > > > > into public infrastructure ENUM? > > > > > > > > > The real reason carriers will never put their numbers into > > any form of > > > public infrastructure ENUM is two fold. > > > > > > A. Only a mad man would put the location of critical VoIP ingress > > > elements edge or otherwise into a public DNS infrastructure. The > > > potential for DDoS alone is massive. > > > > Agreed. That's the reason we developed the domain policy DDDS > > proposal which can used to really de-couple the URI from the > > ingress elements. > > E.g. if the only things you can learn from the public DNS is > > that example.com is a member of federation X and Y, and uses > > > > fedx-ingress.example.com A 10.0.0.42 > > > > and > > > > fedy-ingress.example.com A 172.27.10.10 > > > > as the ingress elements on the respective shared L3 > > infrastructure then I don't see the DDoS potential here. > > > > > B. Infrastructure ENUM as it has been proposed almost guarantees > > > national regulatory delegation and oversight and most > > carriers are in > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > Wait a second: you're now switching from the issue of a > > public tree to the question of whether that should be a > > NRA-approved one under ie164.arpa. > > > > If the regulator proves to be a burden in all this, then > > nothing stops an industry consortium to establish a tree > > under a different apex. (As the forest of trees out there shows.) > > > > > C. Some form of trusted registry of TN 2 URI mappings is = absolutely > > > necessary to insure interoperability but I suspect it will > > be carriers > > > them selves that attempt to control the organization and > > distribution > > > of such data. > > > > Oh yes. Who argued against the carriers establishing a such a tree? > > > > IMHO the best case is if the regulators *and* the carries > > agree on someone who runs that trusted registry. Whether that > > will then be a private tree or a public one, is an > > independent question. > > > > Given the fact that the number of "carriers" is bound to > > increase and international resolution of TN->URI will be an > > issue, I doubt that it will be easy to establish a sensible, > > universal rule which describes who should have access to that > > private tree. > > > > Once the number of organizations which have access to a > > private tree exceeds as certain number, the security benefits > > you get from keeping it non-public are dwarfed by the > > complexities of maintaining access control rules. > > > > Or, as other events prove every now and then, the PSTN method > > of maintaining security ("trust all other carriers") is > > already breaking down right now. So why perpetuate that model? > > > > It's just case of security by obscurity. > > > > /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 From speermint-bounces@ietf.org Mon Oct 23 16:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc68P-0007dG-2M; Mon, 23 Oct 2006 16:10:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc68N-0007bN-EF for speermint@ietf.org; Mon, 23 Oct 2006 16:10:55 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc683-0005Fe-Ju for speermint@ietf.org; Mon, 23 Oct 2006 16:10:55 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gc67K-00058s-S6; Mon, 23 Oct 2006 15:09:51 -0500 From: "Brian Rosen" To: "'Pfautz, Penn L, GBLAM'" , "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:09:55 -0400 Message-ID: <08af01c6f6df$370d5b80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictw In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0DEDCCEE@ACCLUST02EVS1.ugd.att.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > We need to distinguish between peering for voluntary exchange of traffic > (not currently regulated at least in the US) and > Peering as a replacement for legally required interconnection in the > current PSTN. > For the former carriers (and anyone else) can and will do what they > want. The latter is likely to eventually be subject to some rules. But > consider also that where interconnection is mandated it comes with rules > and is not open to all parties. > You want to interconnect with the PSTN in the US you need to be > certified; otherwise you buy end user services. In the U.S., and I suspect in other countries, if anyone, including a less regulated (can't really say unregulated) carrier were to put its numbers in a public database, I am quite certain there would be an uproar, and I'm pretty sure the regulator would act. That kind of thing is just too sensitive these days. Since there were some objections even to OPT-IN scenarios, I think the whole area is fraught with difficulty. YMMV. > > BTW If you put all allocated (including unassigned) numbers in the DNS > then you provide no more info than can be obtained by war dialing every > legitimate sequence. And I repeat, I am firmly in the camp that believes security by obscurity is not real security. However, we deal with perceptions as well as truths and since we're looking for practical answers to real world problems here, I think we need solutions for all routing data not in public databases. If the world ran the way I, personally, wanted, we'd peer on the Internet, and we wouldn't need federations. The reality is quite different. I'd like to not waste my time in this WG working on solutions that don't get widespread adoption. Been there, done that. If you assume ANY public routing data, it's my opinion you have a solution that will not be widely implemented. If you have a solution that works with all private databases, we have a chance. That means the word "DNS", at least a public DNS, can't appear in the answer. I don't like that situation. I'd like to eventually change the perceptions that make that situation arise, but in the mean time, I'd like to get VoIP to VoIP traffic off the PSTN please. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:12:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc69j-0008Ce-9f; Mon, 23 Oct 2006 16:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc69i-0008CZ-T7 for speermint@ietf.org; Mon, 23 Oct 2006 16:12:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc69R-0005Uc-NC for speermint@ietf.org; Mon, 23 Oct 2006 16:12:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Oct 2006 13:11:01 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NKB1Vi029112; Mon, 23 Oct 2006 16:11:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NKB0DM018680; Mon, 23 Oct 2006 16:11:00 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 16:11:00 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:10:59 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C25C@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAADGjHA From: "Michael Hammer \(mhammer\)" To: "Pfautz, Penn L, GBLAM" , "Brian Rosen" , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 23 Oct 2006 20:11:00.0398 (UTC) FILETIME=[5BBE5CE0:01C6F6DF] DKIM-Signature: a=rsa-sha1; q=dns; l=8260; t=1161634261; x=1162498261; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Pfautz, =20Penn=20L, =20GBLAM=22=20, =0A=20=20=20=20=20 =20=20=20=22Brian=20Rosen=22=20, =20=22Otmar=20Lendl=22=2 0, =0A=20=20=20=20=20=20=20=20=22Richard=20Shockey=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=lNZaru+8xqOiFfxWWeeyO1KkBqTlMHsLcE6hDncijpnQRlpw5M0DdQu5E9xHH7S2haS/HfaR 08NFP1cS6muK+AG5zZzvS5rbNRkJY1ssSytJ3jTpBE9bCEl509t/y0RZ; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Penn, Well stated. Mike =20 > -----Original Message----- > From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]=20 > Sent: Monday, October 23, 2006 2:51 PM > To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl;=20 > Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > We can continue to beat this topic to death (and I'm sure we=20 > will) but I want to make one point. >=20 > We need to distinguish between peering for voluntary exchange=20 > of traffic (not currently regulated at least in the US) and=20 > Peering as a replacement for legally required interconnection=20 > in the current PSTN.=20 > For the former carriers (and anyone else) can and will do=20 > what they want. The latter is likely to eventually be subject=20 > to some rules. But consider also that where interconnection=20 > is mandated it comes with rules and is not open to all parties. > You want to interconnect with the PSTN in the US you need to=20 > be certified; otherwise you buy end user services. >=20 > BTW If you put all allocated (including unassigned) numbers=20 > in the DNS then you provide no more info than can be obtained=20 > by war dialing every legitimate sequence. =20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, October 23, 2006 2:34 PM > To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Well, here in the U.S., the stated reluctance of the=20 > regulator to permit TNs in a public database is due to the=20 > fact that people's telephone numbers would be in a public=20 > database. They are concerned with the privacy aspects of the=20 > problem. So, they actually WANT private databases where=20 > people's telephone numbers are concerned. And this concern=20 > started in User ENUM, not just infrastructure ENUM. I=20 > understand there are other regulators who have this concern. >=20 > I do think there is some validity to your concern about one=20 > carrier, or a group of carriers, restricting access to their=20 > customers for termination from other carriers, and I agree=20 > the regulators would probably not allow it. > Making routing data public has not yet been, and I don't=20 > think will be, the remedy. =20 >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, October 23, 2006 12:01 PM > > To: Otmar Lendl; Richard Shockey > > Cc: Nieminen Klaus; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Concerning de-regulation: > >=20 > > If a group were to try to keep the system closed and certain call=20 > > routing information private, whether intentionally or=20 > unintentionally > to > > raise barriers to competition; I think the regulators would feel=20 > > compelled to step in and make such call routing information=20 > publicly=20 > > available. > >=20 > > So, if you want to keep the regulators idle, design the=20 > system so that=20 > > any VSP that can reliably authenticate themselves can take the > sequence > > of steps that leads them to the ingress points and allows them to=20 > > deliver calls to another VSP. The key is having secure controls > versus > > having static clubs. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Monday, October 23, 2006 11:40 AM > > > To: Richard Shockey > > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > > > There are several arguments why carriers will never put > > > there TNs in > > > > > public ENUM trees, e.g.: > > > > > - "Carriers are afraid that others can query how many > > > > > numbers(customers) they have." > > > > > - "Carriers are afraid that other carriers can find out > > > the current > > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > > > Both of these arguments as you mention are completely specious.. > > > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > > You know, they don't always make sense. > > > > > > > > maybe others can tell us why carriers never will put > > > there numbers > > > > > into public infrastructure ENUM? > > > > > > > > > > > > The real reason carriers will never put their numbers into > > > any form of > > > > public infrastructure ENUM is two fold. > > > > > > > > A. Only a mad man would put the location of critical=20 > VoIP ingress=20 > > > > elements edge or otherwise into a public DNS=20 > infrastructure. The=20 > > > > potential for DDoS alone is massive. > > > > > > Agreed. That's the reason we developed the domain policy DDDS=20 > > > proposal which can used to really de-couple the URI from=20 > the ingress=20 > > > elements. > > > E.g. if the only things you can learn from the public DNS is that=20 > > > example.com is a member of federation X and Y, and uses > > > > > > fedx-ingress.example.com A 10.0.0.42 > > > > > > and > > > > > > fedy-ingress.example.com A 172.27.10.10 > > > > > > as the ingress elements on the respective shared L3=20 > infrastructure=20 > > > then I don't see the DDoS potential here. > > > > > > > B. Infrastructure ENUM as it has been proposed almost=20 > guarantees=20 > > > > national regulatory delegation and oversight and most > > > carriers are in > > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > > > Wait a second: you're now switching from the issue of a=20 > public tree=20 > > > to the question of whether that should be a NRA-approved=20 > one under=20 > > > ie164.arpa. > > > > > > If the regulator proves to be a burden in all this, then nothing=20 > > > stops an industry consortium to establish a tree under a=20 > different=20 > > > apex. (As the forest of trees out there shows.) > > > > > > > C. Some form of trusted registry of TN 2 URI mappings is > absolutely > > > > necessary to insure interoperability but I suspect it will > > > be carriers > > > > them selves that attempt to control the organization and > > > distribution > > > > of such data. > > > > > > Oh yes. Who argued against the carriers establishing a=20 > such a tree? > > > > > > IMHO the best case is if the regulators *and* the carries=20 > agree on=20 > > > someone who runs that trusted registry. Whether that will=20 > then be a=20 > > > private tree or a public one, is an independent question. > > > > > > Given the fact that the number of "carriers" is bound to increase=20 > > > and international resolution of TN->URI will be an issue, I doubt=20 > > > that it will be easy to establish a sensible, universal=20 > rule which=20 > > > describes who should have access to that private tree. > > > > > > Once the number of organizations which have access to a=20 > private tree=20 > > > exceeds as certain number, the security benefits you get from=20 > > > keeping it non-public are dwarfed by the complexities of=20 > maintaining=20 > > > access control rules. > > > > > > Or, as other events prove every now and then, the PSTN method of=20 > > > maintaining security ("trust all other carriers") is already=20 > > > breaking down right now. So why perpetuate that model? > > > > > > It's just case of security by obscurity. > > > > > > /ol > > > -- > > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Mn-0000fd-Kz; Mon, 23 Oct 2006 16:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Mm-0000Sr-E6 for speermint@ietf.org; Mon, 23 Oct 2006 16:25:48 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6Ma-0000Ch-FW for speermint@ietf.org; Mon, 23 Oct 2006 16:25:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gc6MI-0003YD-8U; Mon, 23 Oct 2006 15:25:19 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:25:22 -0400 Message-ID: <08c601c6f6e1$5fef9890$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABO62MAAAi8hg In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C258@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I don't think I do. User ENUM does not have user identifiable information in it, although if you have a number of service providers, you could learn some information about the set of URIs in the database. Nothing we are doing has direct user identity information in it. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 4:10 PM > To: Brian Rosen; Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Brian, > > You confuse associating a TN to an ingress point used to route the call, > with associating a TN to a particular end-user. The former can be > accomplished without doing the latter. You conflate the two. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, October 23, 2006 2:34 PM > > To: Michael Hammer (mhammer); 'Otmar Lendl'; 'Richard Shockey' > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > Well, here in the U.S., the stated reluctance of the > > regulator to permit TNs in a public database is due to the > > fact that people's telephone numbers would be in a public > > database. They are concerned with the privacy aspects of the > > problem. So, they actually WANT private databases where > > people's telephone numbers are concerned. And this concern > > started in User ENUM, not just infrastructure ENUM. I > > understand there are other regulators who have this concern. > > > > I do think there is some validity to your concern about one > > carrier, or a group of carriers, restricting access to their > > customers for termination from other carriers, and I agree > > the regulators would probably not allow it. > > Making routing data public has not yet been, and I don't > > think will be, the remedy. > > > > Brian > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Monday, October 23, 2006 12:01 PM > > > To: Otmar Lendl; Richard Shockey > > > Cc: Nieminen Klaus; speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Concerning de-regulation: > > > > > > If a group were to try to keep the system closed and certain call > > > routing information private, whether intentionally or > > unintentionally > > > to raise barriers to competition; I think the regulators would feel > > > compelled to step in and make such call routing information > > publicly > > > available. > > > > > > So, if you want to keep the regulators idle, design the > > system so that > > > any VSP that can reliably authenticate themselves can take the > > > sequence of steps that leads them to the ingress points and allows > > > them to deliver calls to another VSP. The key is having secure > > > controls versus having static clubs. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > > Sent: Monday, October 23, 2006 11:40 AM > > > > To: Richard Shockey > > > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > > > > > There are several arguments why carriers will never put > > > > there TNs in > > > > > > public ENUM trees, e.g.: > > > > > > - "Carriers are afraid that others can query how many > > > > > > numbers(customers) they have." > > > > > > - "Carriers are afraid that other carriers can find out > > > > the current > > > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > > > > > Both of these arguments as you mention are completely specious.. > > > > > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > > > You know, they don't always make sense. > > > > > > > > > > maybe others can tell us why carriers never will put > > > > there numbers > > > > > > into public infrastructure ENUM? > > > > > > > > > > > > > > > The real reason carriers will never put their numbers into > > > > any form of > > > > > public infrastructure ENUM is two fold. > > > > > > > > > > A. Only a mad man would put the location of critical > > VoIP ingress > > > > > elements edge or otherwise into a public DNS > > infrastructure. The > > > > > potential for DDoS alone is massive. > > > > > > > > Agreed. That's the reason we developed the domain policy DDDS > > > > proposal which can used to really de-couple the URI from > > the ingress > > > > elements. > > > > E.g. if the only things you can learn from the public DNS is that > > > > example.com is a member of federation X and Y, and uses > > > > > > > > fedx-ingress.example.com A 10.0.0.42 > > > > > > > > and > > > > > > > > fedy-ingress.example.com A 172.27.10.10 > > > > > > > > as the ingress elements on the respective shared L3 > > infrastructure > > > > then I don't see the DDoS potential here. > > > > > > > > > B. Infrastructure ENUM as it has been proposed almost > > guarantees > > > > > national regulatory delegation and oversight and most > > > > carriers are in > > > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > > > > > Wait a second: you're now switching from the issue of a > > public tree > > > > to the question of whether that should be a NRA-approved > > one under > > > > ie164.arpa. > > > > > > > > If the regulator proves to be a burden in all this, then nothing > > > > stops an industry consortium to establish a tree under a > > different > > > > apex. (As the forest of trees out there shows.) > > > > > > > > > C. Some form of trusted registry of TN 2 URI mappings is > > > > > absolutely necessary to insure interoperability but I > > suspect it > > > > > will > > > > be carriers > > > > > them selves that attempt to control the organization and > > > > distribution > > > > > of such data. > > > > > > > > Oh yes. Who argued against the carriers establishing a > > such a tree? > > > > > > > > IMHO the best case is if the regulators *and* the carries > > agree on > > > > someone who runs that trusted registry. Whether that will > > then be a > > > > private tree or a public one, is an independent question. > > > > > > > > Given the fact that the number of "carriers" is bound to increase > > > > and international resolution of TN->URI will be an issue, I doubt > > > > that it will be easy to establish a sensible, universal > > rule which > > > > describes who should have access to that private tree. > > > > > > > > Once the number of organizations which have access to a > > private tree > > > > exceeds as certain number, the security benefits you get from > > > > keeping it non-public are dwarfed by the complexities of > > maintaining > > > > access control rules. > > > > > > > > Or, as other events prove every now and then, the PSTN method of > > > > maintaining security ("trust all other carriers") is already > > > > breaking down right now. So why perpetuate that model? > > > > > > > > It's just case of security by obscurity. > > > > > > > > /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 From speermint-bounces@ietf.org Mon Oct 23 16:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Mt-0001g3-91; Mon, 23 Oct 2006 16:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Mr-0001Ki-2F for speermint@ietf.org; Mon, 23 Oct 2006 16:25:53 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc6Mb-0000CO-27 for speermint@ietf.org; Mon, 23 Oct 2006 16:25:53 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1161635133!6553075!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 20305 invoked from network); 23 Oct 2006 20:25:33 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 23 Oct 2006 20:25:33 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NKPXQN012964 for ; Mon, 23 Oct 2006 16:25:33 -0400 (EDT) Received: from attrh2i.attrh.att.com (attrh2i.attrh.att.com [135.37.94.56]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id k9NKOZcH012490 for ; Mon, 23 Oct 2006 16:25:29 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by attrh2i.attrh.att.com (7.2.052) id 45325C3300125966; Mon, 23 Oct 2006 16:25:23 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:25:22 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0DEDCE97@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28040ACB25@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9wABK4nw From: "Pfautz, Penn L, GBLAM" To: "Reinaldo Penno" , "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 1.8 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Well, you can't opt out of carrier enum so it needs to be implemented in a way that does not support data mining of unlisted numbers. I would hope that the approach would be to put in everything allocated, but maybe carriers will be required to keep access restricted. We'll see.=20 I wouldn't count on routing data necessarily being public even if TNs are. =20 -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net]=20 Sent: Monday, October 23, 2006 4:10 PM To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; Richard Shockey Cc: Nieminen Klaus; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements I must be missing something here.=20 =20 Telephone numbers are already public in the US (they have to be). To be de-listed you have to pay extra but law enforcement in the US are still notified of such unlisted phones. I can get a paper telephone directory and lookup any telephone number. I can go to Verizon's or ATT's (in the US) home page and perform a reverse lookup and find the telephone number associated with a name (and vice-versa). =20 So, it seems what we are talking here is not if they are public or not, but how easy is to get them. Putting them on a database like DNS would just make it easier (and more hackable) since they would be officially hook up in the Internet infrastructure.=20 =20 It seems people that do not want their telephone numbers on a paper directory, could opt out in a public database as well. =20 Since many of our speermint friends here are from Austria I tried the same thing and after one google search and three clicks I found this page =20 http://www.herold.at/, clicked at Telefonbuch (buch is book in english) and presto.=20 =20 regards, =20 Reinaldo=20 =20 =20 =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Mon 10/23/2006 11:34 AM To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' Cc: 'Nieminen Klaus'; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements Well, here in the U.S., the stated reluctance of the regulator to permit TNs in a public database is due to the fact that people's telephone numbers would be in a public database. They are concerned with the privacy aspects of the problem. So, they actually WANT private databases where people's telephone numbers are concerned. And this concern started in User ENUM, not just infrastructure ENUM. I understand there are other regulators who have this concern. I do think there is some validity to your concern about one carrier, or a group of carriers, restricting access to their customers for termination from other carriers, and I agree the regulators would probably not allow it. Making routing data public has not yet been, and I don't think will be, the remedy.=20 Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 12:01 PM > To: Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Concerning de-regulation: > > If a group were to try to keep the system closed and certain call > routing information private, whether intentionally or unintentionally to > raise barriers to competition; I think the regulators would feel > compelled to step in and make such call routing information publicly > available. > > So, if you want to keep the regulators idle, design the system so that > any VSP that can reliably authenticate themselves can take the sequence > of steps that leads them to the ingress points and allows them to > deliver calls to another VSP. The key is having secure controls versus > having static clubs. > > Mike > > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Monday, October 23, 2006 11:40 AM > > To: Richard Shockey > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > Subject: Re: [Speermint] Basic Peering Requirements > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > There are several arguments why carriers will never put > > there TNs in > > > > public ENUM trees, e.g.: > > > > - "Carriers are afraid that others can query how many > > > > numbers(customers) they have." > > > > - "Carriers are afraid that other carriers can find out > > the current > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > Both of these arguments as you mention are completely specious.. > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > You know, they don't always make sense. > > > > > > maybe others can tell us why carriers never will put > > there numbers > > > > into public infrastructure ENUM? > > > > > > > > > The real reason carriers will never put their numbers into > > any form of > > > public infrastructure ENUM is two fold. > > > > > > A. Only a mad man would put the location of critical VoIP ingress > > > elements edge or otherwise into a public DNS infrastructure. The > > > potential for DDoS alone is massive. > > > > Agreed. That's the reason we developed the domain policy DDDS > > proposal which can used to really de-couple the URI from the > > ingress elements. > > E.g. if the only things you can learn from the public DNS is > > that example.com is a member of federation X and Y, and uses > > > > fedx-ingress.example.com A 10.0.0.42 > > > > and > > > > fedy-ingress.example.com A 172.27.10.10 > > > > as the ingress elements on the respective shared L3 > > infrastructure then I don't see the DDoS potential here. > > > > > B. Infrastructure ENUM as it has been proposed almost guarantees > > > national regulatory delegation and oversight and most > > carriers are in > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > Wait a second: you're now switching from the issue of a > > public tree to the question of whether that should be a > > NRA-approved one under ie164.arpa. > > > > If the regulator proves to be a burden in all this, then > > nothing stops an industry consortium to establish a tree > > under a different apex. (As the forest of trees out there shows.) > > > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > > necessary to insure interoperability but I suspect it will > > be carriers > > > them selves that attempt to control the organization and > > distribution > > > of such data. > > > > Oh yes. Who argued against the carriers establishing a such a tree? > > > > IMHO the best case is if the regulators *and* the carries > > agree on someone who runs that trusted registry. Whether that > > will then be a private tree or a public one, is an > > independent question. > > > > Given the fact that the number of "carriers" is bound to > > increase and international resolution of TN->URI will be an > > issue, I doubt that it will be easy to establish a sensible, > > universal rule which describes who should have access to that > > private tree. > > > > Once the number of organizations which have access to a > > private tree exceeds as certain number, the security benefits > > you get from keeping it non-public are dwarfed by the > > complexities of maintaining access control rules. > > > > Or, as other events prove every now and then, the PSTN method > > of maintaining security ("trust all other carriers") is > > already breaking down right now. So why perpetuate that model? > > > > It's just case of security by obscurity. > > > > /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 From speermint-bounces@ietf.org Mon Oct 23 16:34:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Ub-0002dF-Jc; Mon, 23 Oct 2006 16:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6Ua-0002d5-HK for speermint@ietf.org; Mon, 23 Oct 2006 16:33:52 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6UR-0001wV-Vv for speermint@ietf.org; Mon, 23 Oct 2006 16:33:52 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 23 Oct 2006 13:30:39 -0700 X-IronPort-AV: i="4.09,343,1157353200"; d="scan'208"; a="598191594:sNHT75895203504" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:31:06 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28040ACB26@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9wABK4nwAABdOis= References: <34DA635B184A644DA4588E260EC0A25A0DEDCE97@ACCLUST02EVS1.ugd.att.com> From: "Reinaldo Penno" To: "Pfautz, Penn L, GBLAM" , "Brian Rosen" , "Michael Hammer \(mhammer\)" , "Otmar Lendl" , "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 ________________________________ From: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com] Sent: Mon 10/23/2006 1:25 PM To: Reinaldo Penno; Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; = Richard Shockey Cc: Nieminen Klaus; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements Well, you can't opt out of carrier enum so it needs to be implemented in a way that does not support data mining of unlisted numbers.=20 [Reinaldo] Of course, since it would become easier, more safeguards would be = needed. Possibly using user entered patterns or others. I would hope that the approach would be to put in everything allocated, but maybe carriers will be required to keep access restricted. We'll see. I wouldn't count on routing data necessarily being public even if TNs are.=20 [Reinaldo] Agree. -----Original Message----- From: Reinaldo Penno [mailto:rpenno@juniper.net = ] Sent: Monday, October 23, 2006 4:10 PM To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; Richard Shockey Cc: Nieminen Klaus; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements I must be missing something here. Telephone numbers are already public in the US (they have to be). To be de-listed you have to pay extra but law enforcement in the US are still notified of such unlisted phones. I can get a paper telephone directory and lookup any telephone number. I can go to Verizon's or ATT's (in the US) home page and perform a reverse lookup and find the telephone number associated with a name (and vice-versa). So, it seems what we are talking here is not if they are public or not, but how easy is to get them. Putting them on a database like DNS would just make it easier (and more hackable) since they would be officially hook up in the Internet infrastructure. It seems people that do not want their telephone numbers on a paper directory, could opt out in a public database as well. Since many of our speermint friends here are from Austria I tried the same thing and after one google search and three clicks I found this page http://www.herold.at/ , clicked at Telefonbuch = (buch is book in english) and presto. regards, Reinaldo ________________________________ From: Brian Rosen [mailto:br@brianrosen.net ] Sent: Mon 10/23/2006 11:34 AM To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' Cc: 'Nieminen Klaus'; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements Well, here in the U.S., the stated reluctance of the regulator to permit TNs in a public database is due to the fact that people's telephone numbers would be in a public database. They are concerned with the privacy aspects of the problem. So, they actually WANT private databases where people's telephone numbers are concerned. And this concern started in User ENUM, not just infrastructure ENUM. I understand there are other regulators who have this concern. I do think there is some validity to your concern about one carrier, or a group of carriers, restricting access to their customers for termination from other carriers, and I agree the regulators would probably not allow it. Making routing data public has not yet been, and I don't think will be, the remedy. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com = ] > Sent: Monday, October 23, 2006 12:01 PM > To: Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Concerning de-regulation: > > If a group were to try to keep the system closed and certain call > routing information private, whether intentionally or unintentionally to > raise barriers to competition; I think the regulators would feel > compelled to step in and make such call routing information publicly > available. > > So, if you want to keep the regulators idle, design the system so that > any VSP that can reliably authenticate themselves can take the sequence > of steps that leads them to the ingress points and allows them to > deliver calls to another VSP. The key is having secure controls versus > having static clubs. > > Mike > > > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at ] > > Sent: Monday, October 23, 2006 11:40 AM > > To: Richard Shockey > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > Subject: Re: [Speermint] Basic Peering Requirements > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > There are several arguments why carriers will never put > > there TNs in > > > > public ENUM trees, e.g.: > > > > - "Carriers are afraid that others can query how many > > > > numbers(customers) they have." > > > > - "Carriers are afraid that other carriers can find out > > the current > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > Both of these arguments as you mention are completely specious.. > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > You know, they don't always make sense. > > > > > > maybe others can tell us why carriers never will put > > there numbers > > > > into public infrastructure ENUM? > > > > > > > > > The real reason carriers will never put their numbers into > > any form of > > > public infrastructure ENUM is two fold. > > > > > > A. Only a mad man would put the location of critical VoIP ingress > > > elements edge or otherwise into a public DNS infrastructure. The > > > potential for DDoS alone is massive. > > > > Agreed. That's the reason we developed the domain policy DDDS > > proposal which can used to really de-couple the URI from the > > ingress elements. > > E.g. if the only things you can learn from the public DNS is > > that example.com is a member of federation X and Y, and uses > > > > fedx-ingress.example.com A 10.0.0.42 > > > > and > > > > fedy-ingress.example.com A 172.27.10.10 > > > > as the ingress elements on the respective shared L3 > > infrastructure then I don't see the DDoS potential here. > > > > > B. Infrastructure ENUM as it has been proposed almost guarantees > > > national regulatory delegation and oversight and most > > carriers are in > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > Wait a second: you're now switching from the issue of a > > public tree to the question of whether that should be a > > NRA-approved one under ie164.arpa. > > > > If the regulator proves to be a burden in all this, then > > nothing stops an industry consortium to establish a tree > > under a different apex. (As the forest of trees out there shows.) > > > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > > necessary to insure interoperability but I suspect it will > > be carriers > > > them selves that attempt to control the organization and > > distribution > > > of such data. > > > > Oh yes. Who argued against the carriers establishing a such a tree? > > > > IMHO the best case is if the regulators *and* the carries > > agree on someone who runs that trusted registry. Whether that > > will then be a private tree or a public one, is an > > independent question. > > > > Given the fact that the number of "carriers" is bound to > > increase and international resolution of TN->URI will be an > > issue, I doubt that it will be easy to establish a sensible, > > universal rule which describes who should have access to that > > private tree. > > > > Once the number of organizations which have access to a > > private tree exceeds as certain number, the security benefits > > you get from keeping it non-public are dwarfed by the > > complexities of maintaining access control rules. > > > > Or, as other events prove every now and then, the PSTN method > > of maintaining security ("trust all other carriers") is > > already breaking down right now. So why perpetuate that model? > > > > It's just case of security by obscurity. > > > > /ol > > -- > > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint = =20 > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint = =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint = =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint = =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6WZ-0004RM-WA; Mon, 23 Oct 2006 16:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6WY-0004RA-Ba for speermint@ietf.org; Mon, 23 Oct 2006 16:35:54 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6WW-0002Ii-PS for speermint@ietf.org; Mon, 23 Oct 2006 16:35:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gc6WG-000757-RR; Mon, 23 Oct 2006 15:35:37 -0500 From: "Brian Rosen" To: "'Reinaldo Penno'" , "'Michael Hammer \(mhammer\)'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:35:41 -0400 Message-ID: <08cd01c6f6e2$d09dc480$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9wABWkGA In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28040ACB25@proton.jnpr.net> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I know all of that. There are web databases which, for any listed number, will tell you the name (reverse lookup) from the number. Of course, we need solutions that work for unlisted numbers, one of the many problems public databases have, war dialing every valid number notwithstanding. However, the U.S. regulator, and the "Commerce Department", the branch of executive government that deals with consumer affairs, have grave reservations about ENUM in the public DNS. Maybe Penn's folks can get them over the problem, but right now it's not happening. I understand there are other countries whose governments are also worried. In the mean time, we need solutions we CAN implement. I don't think this is one of those cases where the IETF holds up its nose and states that the U.S. government, some carriers (and others) is just wrong, or silly, or misinformed, and goes ahead and engineers solutions that are ignored. We've done that before, and we'll do it again. I'd prefer in this case that we just hold our indignation in check and build something that works. Brian > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Monday, October 23, 2006 4:10 PM > To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > I must be missing something here. > > Telephone numbers are already public in the US (they have to be). To be > de-listed you have to pay extra but law enforcement in the US are still > notified of such unlisted phones. I can get a paper telephone directory > and lookup any telephone number. I can go to Verizon's or ATT's (in the > US) home page and perform a reverse lookup and find the telephone number > associated with a name (and vice-versa). > > So, it seems what we are talking here is not if they are public or not, > but how easy is to get them. Putting them on a database like DNS would > just make it easier (and more hackable) since they would be officially > hook up in the Internet infrastructure. > > It seems people that do not want their telephone numbers on a paper > directory, could opt out in a public database as well. > > Since many of our speermint friends here are from Austria I tried the same > thing and after one google search and three clicks I found this page > > http://www.herold.at/, clicked at Telefonbuch (buch is book in english) > and presto. > > regards, > > Reinaldo > > > > > ________________________________ > > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Mon 10/23/2006 11:34 AM > To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > > > Well, here in the U.S., the stated reluctance of the regulator to permit > TNs > in a public database is due to the fact that people's telephone numbers > would be in a public database. They are concerned with the privacy > aspects > of the problem. So, they actually WANT private databases where people's > telephone numbers are concerned. And this concern started in User ENUM, > not > just infrastructure ENUM. I understand there are other regulators who > have > this concern. > > I do think there is some validity to your concern about one carrier, or a > group of carriers, restricting access to their customers for termination > from other carriers, and I agree the regulators would probably not allow > it. > Making routing data public has not yet been, and I don't think will be, > the > remedy. > > Brian > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, October 23, 2006 12:01 PM > > To: Otmar Lendl; Richard Shockey > > Cc: Nieminen Klaus; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > Concerning de-regulation: > > > > If a group were to try to keep the system closed and certain call > > routing information private, whether intentionally or unintentionally to > > raise barriers to competition; I think the regulators would feel > > compelled to step in and make such call routing information publicly > > available. > > > > So, if you want to keep the regulators idle, design the system so that > > any VSP that can reliably authenticate themselves can take the sequence > > of steps that leads them to the ingress points and allows them to > > deliver calls to another VSP. The key is having secure controls versus > > having static clubs. > > > > Mike > > > > > > > -----Original Message----- > > > From: Otmar Lendl [mailto:lendl@nic.at] > > > Sent: Monday, October 23, 2006 11:40 AM > > > To: Richard Shockey > > > Cc: speermint@ietf.org; 'Nieminen Klaus' > > > Subject: Re: [Speermint] Basic Peering Requirements > > > > > > On 2006/10/23 17:10, Richard Shockey wrote: > > > > > > > > > There are several arguments why carriers will never put > > > there TNs in > > > > > public ENUM trees, e.g.: > > > > > - "Carriers are afraid that others can query how many > > > > > numbers(customers) they have." > > > > > - "Carriers are afraid that other carriers can find out > > > the current > > > > > carrier-of-record of an enterprise and to poach this customer" > > > > > > > > Both of these arguments as you mention are completely specious.. > > > > > > We know. Klaus just quoted what we sometimes hear from carriers. > > > You know, they don't always make sense. > > > > > > > > maybe others can tell us why carriers never will put > > > there numbers > > > > > into public infrastructure ENUM? > > > > > > > > > > > > The real reason carriers will never put their numbers into > > > any form of > > > > public infrastructure ENUM is two fold. > > > > > > > > A. Only a mad man would put the location of critical VoIP ingress > > > > elements edge or otherwise into a public DNS infrastructure. The > > > > potential for DDoS alone is massive. > > > > > > Agreed. That's the reason we developed the domain policy DDDS > > > proposal which can used to really de-couple the URI from the > > > ingress elements. > > > E.g. if the only things you can learn from the public DNS is > > > that example.com is a member of federation X and Y, and uses > > > > > > fedx-ingress.example.com A 10.0.0.42 > > > > > > and > > > > > > fedy-ingress.example.com A 172.27.10.10 > > > > > > as the ingress elements on the respective shared L3 > > > infrastructure then I don't see the DDoS potential here. > > > > > > > B. Infrastructure ENUM as it has been proposed almost guarantees > > > > national regulatory delegation and oversight and most > > > carriers are in > > > > favor of DE-Regulation of telecom not RE-Regulation. > > > > > > Wait a second: you're now switching from the issue of a > > > public tree to the question of whether that should be a > > > NRA-approved one under ie164.arpa. > > > > > > If the regulator proves to be a burden in all this, then > > > nothing stops an industry consortium to establish a tree > > > under a different apex. (As the forest of trees out there shows.) > > > > > > > C. Some form of trusted registry of TN 2 URI mappings is absolutely > > > > necessary to insure interoperability but I suspect it will > > > be carriers > > > > them selves that attempt to control the organization and > > > distribution > > > > of such data. > > > > > > Oh yes. Who argued against the carriers establishing a such a tree? > > > > > > IMHO the best case is if the regulators *and* the carries > > > agree on someone who runs that trusted registry. Whether that > > > will then be a private tree or a public one, is an > > > independent question. > > > > > > Given the fact that the number of "carriers" is bound to > > > increase and international resolution of TN->URI will be an > > > issue, I doubt that it will be easy to establish a sensible, > > > universal rule which describes who should have access to that > > > private tree. > > > > > > Once the number of organizations which have access to a > > > private tree exceeds as certain number, the security benefits > > > you get from keeping it non-public are dwarfed by the > > > complexities of maintaining access control rules. > > > > > > Or, as other events prove every now and then, the PSTN method > > > of maintaining security ("trust all other carriers") is > > > already breaking down right now. So why perpetuate that model? > > > > > > It's just case of security by obscurity. > > > > > > /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 From speermint-bounces@ietf.org Mon Oct 23 16:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6YR-0004wf-6p; Mon, 23 Oct 2006 16:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6YP-0004vY-K1 for speermint@ietf.org; Mon, 23 Oct 2006 16:37:49 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6YO-0002Xe-7q for speermint@ietf.org; Mon, 23 Oct 2006 16:37:49 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 90484; Mon, 23 Oct 2006 21:37:47 +0100 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28040ACB25@proton.jnpr.net> References: <07da01c6f6d1$da543fb0$640fa8c0@cis.neustar.com> <9BD5D7887235424FA97DFC223CAE3C28040ACB25@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <055D8EBC-A448-4E7A-8320-D264FD4CFDDF@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 21:37:45 +0100 To: Reinaldo Penno X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Otmar Lendl , Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 23, 2006, at 21:10, Reinaldo Penno wrote: > I must be missing something here. True. :-) > Telephone numbers are already public in the US (they have to be). > To be de-listed you have to pay extra but law enforcement in the US > are still notified of such unlisted phones. I can get a paper > telephone directory and lookup any telephone number. I can go to > Verizon's or ATT's (in the US) home page and perform a reverse > lookup and find the telephone number associated with a name (and > vice-versa). Although phone numbers are sort of public, other things related to telephony service are not. [Or at least not easily determined by the general public.] These include stuff like which company provides service for a given number, which number(s) in a company's "allocation block" have been ported or are not in use, where the telco's interconnect points are, what type of hardware they use, etc, etc. With SIP peering, the analogues of these things could become visible to everyone: eg the name and addresses of the company's SIP servers that act as their internet/PSTN gateways. Telcos tend to consider this kind of thing to be sensitive data. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 16:53:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6mh-0007o4-3d; Mon, 23 Oct 2006 16:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6dH-0002cD-Fd for speermint@ietf.org; Mon, 23 Oct 2006 16:42:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6dE-00041I-PZ for speermint@ietf.org; Mon, 23 Oct 2006 16:42:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Oct 2006 16:42:49 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NKgmwS001313; Mon, 23 Oct 2006 16:42:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9NKgmYJ022285; Mon, 23 Oct 2006 16:42:48 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 16:42:48 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:42:47 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C283@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbA= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 23 Oct 2006 20:42:48.0209 (UTC) FILETIME=[CCE33810:01C6F6E3] DKIM-Signature: a=rsa-sha1; q=dns; l=3497; t=1161636168; x=1162500168; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Pfautz, =20Penn=20L, =20GBLAM=22=20, =0A=20=20=20=20=20=20=20 =20=22Otmar=20Lendl=22=20, =20=22Richard=20Shockey=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=pRRYoFUJRZu3VBeuwrNnBg6xKSMKhxA/tgkoV8qC7ibwdRKVVodh5qAuomJkX8IIN652rq+H HbBBRGG1vK9X9kY//NI14xmb9qGAYxFYdiyKiYAAIi8fIRbrwbl18sKf; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, You don't want to talk about federation, yet that is just an expression for a type of peering. So, you want to do Speermint, you just don't want to do peering??? You want to skip dealing with domains, which is the host part of a SIP URI and remain focused on routing based on TNs. So, I presume we just use tel:URIs? Today, DNS is how you end up with an IP address which is routing data that allows you to put a data packet into the network. But, you don't want any of that to be "public", but rather shared among a closed group. Sounds like you already have the ideal solution. It's called the PSTN. You seem to be arguing against doing anything new. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, October 23, 2006 4:10 PM > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar=20 > Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > > We need to distinguish between peering for voluntary exchange of=20 > > traffic (not currently regulated at least in the US) and=20 > Peering as a=20 > > replacement for legally required interconnection in the=20 > current PSTN. > > For the former carriers (and anyone else) can and will do what they=20 > > want. The latter is likely to eventually be subject to some=20 > rules. But=20 > > consider also that where interconnection is mandated it comes with=20 > > rules and is not open to all parties. > > You want to interconnect with the PSTN in the US you need to be=20 > > certified; otherwise you buy end user services. > In the U.S., and I suspect in other countries, if anyone,=20 > including a less regulated (can't really say unregulated)=20 > carrier were to put its numbers in a public database, I am=20 > quite certain there would be an uproar, and I'm pretty sure=20 > the regulator would act. That kind of thing is just too=20 > sensitive these days. >=20 > Since there were some objections even to OPT-IN scenarios, I=20 > think the whole area is fraught with difficulty. YMMV.=20 >=20 >=20 > >=20 > > BTW If you put all allocated (including unassigned) numbers=20 > in the DNS=20 > > then you provide no more info than can be obtained by war dialing=20 > > every legitimate sequence. > And I repeat, I am firmly in the camp that believes security=20 > by obscurity is not real security. However, we deal with=20 > perceptions as well as truths and since we're looking for=20 > practical answers to real world problems here, I think we=20 > need solutions for all routing data not in public databases. >=20 > If the world ran the way I, personally, wanted, we'd peer on=20 > the Internet, and we wouldn't need federations. The reality=20 > is quite different. I'd like to not waste my time in this WG=20 > working on solutions that don't get widespread adoption. =20 > Been there, done that. >=20 > If you assume ANY public routing data, it's my opinion you=20 > have a solution that will not be widely implemented. If you=20 > have a solution that works with all private databases, we=20 > have a chance. That means the word "DNS", at least a public=20 > DNS, can't appear in the answer. I don't like that=20 > situation. I'd like to eventually change the perceptions=20 > that make that situation arise, but in the mean time, I'd=20 > like to get VoIP to VoIP traffic off the PSTN please.=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 17:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7J7-0003Uv-4C; Mon, 23 Oct 2006 17:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6k4-0004I0-1I for speermint@ietf.org; Mon, 23 Oct 2006 16:49:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6jk-0005uA-Fh for speermint@ietf.org; Mon, 23 Oct 2006 16:49:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Oct 2006 13:49:33 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NKnWHH004567; Mon, 23 Oct 2006 16:49:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NKnVDO029198; Mon, 23 Oct 2006 16:49:32 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 16:49:31 -0400 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 16:49:30 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C291@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb24x1CNTCJqvwPSYmadR/kaweSTgAASwzg From: "Michael Hammer \(mhammer\)" To: "Jim Reid" , "Reinaldo Penno" X-OriginalArrivalTime: 23 Oct 2006 20:49:31.0606 (UTC) FILETIME=[BD54B760:01C6F6E4] DKIM-Signature: a=rsa-sha1; q=dns; l=1840; t=1161636572; x=1162500572; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Jim=20Reid=22=20, =20=22Reinaldo=20Penno=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=jOv4ffgpNx7zadQoaxwUMtgB9Rh1c11mDC4Nvtrh2/E3ELhlaY4csmJsdkEDeGewf7SfylLI X/TXYz/s1k7XnE/epkQSbtB5AT251/sagt/FxEJAbXylcMHTGRMNdM2R; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: speermint@ietf.org, Nieminen Klaus , Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org What is visible depends on how you set things up. If the public aspect points you to the next hoop through which you need to authenticate and get authorized to pass, then very little has been revealed. Mike =20 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com]=20 > Sent: Monday, October 23, 2006 4:38 PM > To: Reinaldo Penno > Cc: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl;=20 > Richard Shockey; Nieminen Klaus; speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On Oct 23, 2006, at 21:10, Reinaldo Penno wrote: >=20 > > I must be missing something here. >=20 > True. :-) >=20 > > Telephone numbers are already public in the US (they have to be). =20 > > To be de-listed you have to pay extra but law enforcement in the US=20 > > are still notified of such unlisted phones. I can get a paper=20 > > telephone directory and lookup any telephone number. I can go to=20 > > Verizon's or ATT's (in the US) home page and perform a=20 > reverse lookup=20 > > and find the telephone number associated with a name (and=20 > vice-versa). >=20 > Although phone numbers are sort of public, other things=20 > related to telephony service are not. [Or at least not easily=20 > determined by the general public.] These include stuff like=20 > which company provides service for a given number, which=20 > number(s) in a company's "allocation block" have been ported=20 > or are not in use, where the telco's interconnect points are,=20 > what type of hardware they use, etc, etc. With SIP peering,=20 > the analogues of these things could become visible to=20 > everyone: eg the name and addresses of the company's SIP=20 > servers that act as their internet/PSTN gateways. Telcos tend=20 > to consider this kind of thing to be sensitive data. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 17:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7Lw-00051K-G3; Mon, 23 Oct 2006 17:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7Lv-00050d-RG for speermint@ietf.org; Mon, 23 Oct 2006 17:28:59 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc7Lu-0000oR-Hd for speermint@ietf.org; Mon, 23 Oct 2006 17:28:59 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 23 Oct 2006 14:26:22 -0700 X-IronPort-AV: i="4.09,343,1157353200"; d="scan'208"; a="606445364:sNHT34890332" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 17:28:54 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805EDD456@proton.jnpr.net> In-Reply-To: <055D8EBC-A448-4E7A-8320-D264FD4CFDDF@rfc1035.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-index: Acb24ywAWQBTH/kuTHK0HYP9+txO8QABfnWQ From: "Reinaldo Penno" To: "Jim Reid" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Otmar Lendl , Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay, let's go by parts here. I responded to the "privacy issues" related to users. You answered my statement by saying that there are others things that a user cannot find out. Well, that's another set of issues. So, I guess I'm not missing anything, we are just talking about different things. Now, your argument is that there are other stuff and it is not accessible. Some are related to peering, some are related number portability and others. I'm sure you can a enum tree that mirrors what you have today in a directory.=20 Now, you said it is difficult to find out "which company provides service for a given number" Well, I go o Verizon's webpage (which is _not_ my provider and put my telephone number), it tells me "Phone Details Line Type: Land Line Provider: Pacific Bell" I tried with my cell phone, it even told me that. Can it be easier than that? Thanks, Reinaldo > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com]=20 > Sent: Monday, October 23, 2006 1:38 PM > To: Reinaldo Penno > Cc: Brian Rosen; Michael Hammer ((mhammer)); Otmar Lendl;=20 > Richard Shockey; Nieminen Klaus; speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On Oct 23, 2006, at 21:10, Reinaldo Penno wrote: >=20 > > I must be missing something here. >=20 > True. :-) >=20 > > Telephone numbers are already public in the US (they have to be). =20 > > To be de-listed you have to pay extra but law enforcement in the US=20 > > are still notified of such unlisted phones. I can get a paper=20 > > telephone directory and lookup any telephone number. I can go to=20 > > Verizon's or ATT's (in the US) home page and perform a=20 > reverse lookup=20 > > and find the telephone number associated with a name (and=20 > vice-versa). >=20 > Although phone numbers are sort of public, other things=20 > related to telephony service are not. [Or at least not easily=20 > determined by the general public.] These include stuff like=20 > which company provides service for a given number, which=20 > number(s) in a company's "allocation block" have been ported=20 > or are not in use, where the telco's interconnect points are,=20 > what type of hardware they use, etc, etc. With SIP peering,=20 > the analogues of these things could become visible to=20 > everyone: eg the name and addresses of the company's SIP=20 > servers that act as their internet/PSTN gateways. Telcos tend=20 > to consider this kind of thing to be sensitive data. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 17:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7Xc-0002UT-8F; Mon, 23 Oct 2006 17:41:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7Xa-0002Sl-CX for speermint@ietf.org; Mon, 23 Oct 2006 17:41:02 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc7XT-0003W7-59 for speermint@ietf.org; Mon, 23 Oct 2006 17:41:02 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 90494; Mon, 23 Oct 2006 22:40:54 +0100 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2805EDD456@proton.jnpr.net> References: <9BD5D7887235424FA97DFC223CAE3C2805EDD456@proton.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51C7BE1E-8A5C-4778-A8E6-79FA2BA4A5EF@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 22:40:53 +0100 To: Reinaldo Penno X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Otmar Lendl , Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 23, 2006, at 22:28, Reinaldo Penno wrote: > Okay, let's go by parts here. I responded to the "privacy issues" > related to users. You answered my statement by saying that there are > others things that a user cannot find out. Well, that's another set of > issues. So, I guess I'm not missing anything, we are just talking > about > different things. Quite probably. Your example of how to find the provider of telephone service does not disprove the point I made. So a US web site can tell someone which telco provides service for a US telephone number. Big Deal. Perhaps you could tell me who provides telco service for say the BBC in London. [You even get to pick the number.] Or for bonus marks, tell me how and where Verizon and PacBell (say) interconnect with each other. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 17:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7fb-0002Qu-LW; Mon, 23 Oct 2006 17:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7fa-0002L7-EH for speermint@ietf.org; Mon, 23 Oct 2006 17:49:18 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc7fY-0005F9-4W for speermint@ietf.org; Mon, 23 Oct 2006 17:49:18 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 23 Oct 2006 14:46:25 -0700 X-IronPort-AV: i="4.09,343,1157353200"; d="scan'208"; a="598224682:sNHT39306690864" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 17:49:01 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2805EDD460@proton.jnpr.net> In-Reply-To: <51C7BE1E-8A5C-4778-A8E6-79FA2BA4A5EF@rfc1035.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-index: Acb27ASNAwA31RkPTsCIwTh0zDGavAAAJnIg From: "Reinaldo Penno" To: "Jim Reid" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Otmar Lendl , Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com]=20 > Sent: Monday, October 23, 2006 2:41 PM > To: Reinaldo Penno > Cc: Brian Rosen; Michael Hammer; Otmar Lendl; Richard=20 > Shockey; Nieminen Klaus; speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On Oct 23, 2006, at 22:28, Reinaldo Penno wrote: >=20 > > Okay, let's go by parts here. I responded to the "privacy issues" > > related to users. You answered my statement by saying that=20 > there are=20 > > others things that a user cannot find out. Well, that's=20 > another set of=20 > > issues. So, I guess I'm not missing anything, we are just talking=20 > > about different things. >=20 > Quite probably. >=20 > Your example of how to find the provider of telephone service=20 > does not disprove the point I made. So a US web site can tell=20 > someone which telco provides service for a US telephone=20 > number. Big Deal. =20 "Bid Deal" is what you thought it was. You used it in an argument to prove it was difficult. Then I showed it wasn't a "Big Deal" and actually quite easy. > Perhaps you could tell me who provides telco service for say=20 > the BBC in London. [You even get to pick the number.] Or for=20 > bonus marks, tell me how and where Verizon and PacBell (say)=20 > interconnect with each other. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 17:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7gY-0003M1-5S; Mon, 23 Oct 2006 17:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7gX-0003LM-ME for speermint@ietf.org; Mon, 23 Oct 2006 17:50:17 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc7gW-0005WM-Cf for speermint@ietf.org; Mon, 23 Oct 2006 17:50:17 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9NLoCcx023977; Mon, 23 Oct 2006 15:50:12 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Basic Peering Requirements Date: Mon, 23 Oct 2006 15:50:11 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb24yucTalc8DyTRNGswOH8YF+lLgAB5iqg From: "Jean-Francois Mule" To: "Jim Reid" , "Reinaldo Penno" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Nieminen Klaus , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, Just counting how many messages will keep going with the same subject thread. Jim wrote: > etc. With SIP peering, the analogues of these things could become > visible to everyone: eg the name and addresses of the company's SIP > servers that act as their internet/PSTN gateways. Telcos tend to > consider this kind of thing to be sensitive data. True but email is the model to replicate here, not the PSTN.=20 As I'm sure you know, if you do a packet sniffer trace on a few VoIP or IM services today, you will find out the ingress and egress SBEs. Google apps provides you with SRVs for IMs within a domain - nothing to hide. =20 And as Mike says, it may not reveal much more than the next hop providing an authentication service (in the RFC4474 sense). Providers should not rely on the fact that the address resolution of SBEs is secure because it is (thought to be) hidden. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 23 18:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc89e-0001JK-9u; Mon, 23 Oct 2006 18:20:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc89c-0001JE-T9 for speermint@ietf.org; Mon, 23 Oct 2006 18:20:20 -0400 Received: from shaun.rfc1035.com ([195.54.233.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc89b-0003YG-I4 for speermint@ietf.org; Mon, 23 Oct 2006 18:20:20 -0400 Received: from [195.54.233.69] (HELO [195.54.233.69]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 90501; Mon, 23 Oct 2006 23:20:18 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <214378D4-68A4-4B66-A646-F2E0BB56954C@rfc1035.com> Content-Transfer-Encoding: 7bit From: Jim Reid Subject: Re: [Speermint] Basic Peering Requirements Date: Mon, 23 Oct 2006 23:20:17 +0100 To: "Jean-Francois Mule" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Nieminen Klaus , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Oct 23, 2006, at 22:50, Jean-Francois Mule wrote: > True but email is the model to replicate here, not the PSTN. Try convincing a long-established telco that's the case. :-) > As I'm sure you know, if you do a packet sniffer trace on a few > VoIP or > IM services today, you will find out the ingress and egress SBEs. > Google > apps provides you with SRVs for IMs within a domain - nothing to hide. True. Then again, google is not a telco. At least not an incumbent. For some definition of telco or incumbent. :-) _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 03:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGcl-0004mp-GI; Tue, 24 Oct 2006 03:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGci-0004i5-G2 for speermint@ietf.org; Tue, 24 Oct 2006 03:22:56 -0400 Received: from mail.ficora.fi ([194.100.96.25] helo=portti1.ficora.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcGcd-0005Ej-S8 for speermint@ietf.org; Tue, 24 Oct 2006 03:22:56 -0400 Received: from POSTI.laru.local ([10.1.0.10]) by portti1.ficora.fi with InterScan Messaging Security Suite; Tue, 24 Oct 2006 10:22:50 +0300 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] Basic Peering Requirements Date: Tue, 24 Oct 2006 10:22:49 +0300 Message-ID: <07BC6C0D40216E44A34BE6701694FE86038B4A54@POSTI.laru.local> In-Reply-To: <08cd01c6f6e2$d09dc480$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9wABWkGAABaOpDA= From: "Nieminen Klaus" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, Jim and all, I think we should distinguish privacy from discovering some "routing" information (e.g. the operator providing services for a given number/URI). I don't know what was the main problem in US, but I suspect that publishing just the provider may not be the one that caused such reservations. I'm I wrong? Some people don't want to publish the connectivity between their number and other personal information (e.g. name and address) and they have legal right to prevent that. However, we want to publish the operator providing services for a given number and the reason behind this is charging. A caller should be able (well in practise this is more likely just in theory) to know the cost of making a call to a given number beforehand. For example in Finland this has been implemented as a web-page (http://www.siirretytnumerot.fi/) where you input the number and get the operator as a response. I don't know in how many other countries this information is easily publicly available, but I don't see publishing it as a big problem... of course this could reveal, what numbers are used and what are not if that makes difference. In addition, one comment because of Richard's question: > Hence the heretical statement, "Is ENUM Irrelevant?" What kind of ENUM do you mean? What I have understood, the "routing DB" may not be public, but what I have heard at least most use ENUM technology. That's at least what we have been planning in Finland. regards, - Klaus -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 23. lokakuuta 2006 23:36 To: 'Reinaldo Penno'; 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey' Cc: Nieminen Klaus; speermint@ietf.org Subject: RE: [Speermint] Basic Peering Requirements I know all of that. There are web databases which, for any listed number, will tell you the name (reverse lookup) from the number. Of course, we need solutions that work for unlisted numbers, one of the many problems public databases have, war dialing every valid number notwithstanding. However, the U.S. regulator, and the "Commerce Department", the branch of executive government that deals with consumer affairs, have grave reservations about ENUM in the public DNS. Maybe Penn's folks can get them over the problem, but right now it's not happening. I understand there are other countries whose governments are also worried. In the mean time, we need solutions we CAN implement. =20 I don't think this is one of those cases where the IETF holds up its nose and states that the U.S. government, some carriers (and others) is just wrong, or silly, or misinformed, and goes ahead and engineers solutions that are ignored. We've done that before, and we'll do it again. I'd prefer in this case that we just hold our indignation in check and build something that works. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 03:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGua-0005r1-2m; Tue, 24 Oct 2006 03:41:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGuY-0005qu-Lk for speermint@ietf.org; Tue, 24 Oct 2006 03:41:22 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcGuX-0001U6-3H for speermint@ietf.org; Tue, 24 Oct 2006 03:41:22 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id E52C8210098; Tue, 24 Oct 2006 09:41:16 +0200 (CEST) Message-ID: <453DC39C.9080300@pernau.at> Date: Tue, 24 Oct 2006 09:41:16 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <07da01c6f6d1$da543fb0$640fa8c0@cis.neustar.com> In-Reply-To: <07da01c6f6d1$da543fb0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: 'Nieminen Klaus' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > Well, here in the U.S., the stated reluctance of the regulator to permit TNs > in a public database is due to the fact that people's telephone numbers > would be in a public database. They are concerned with the privacy aspects > of the problem. So, they actually WANT private databases where people's Then I suggest some education for your regulators instead of accepting their concerns. Yes, publishing phone numbers in ENUM makes them public - but publishing in ENUM does not reveal privacy data. > telephone numbers are concerned. And this concern started in User ENUM, not I do not understand why regulators have privacy concerns with user ENUM. The user decides if it wants to publish its number it it should not be overruled by a regulator. regards klaus > just infrastructure ENUM. I understand there are other regulators who have > this concern. > I do think there is some validity to your concern about one carrier, or a > group of carriers, restricting access to their customers for termination > from other carriers, and I agree the regulators would probably not allow it. > Making routing data public has not yet been, and I don't think will be, the > remedy. > > Brian > >> -----Original Message----- >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >> Sent: Monday, October 23, 2006 12:01 PM >> To: Otmar Lendl; Richard Shockey >> Cc: Nieminen Klaus; speermint@ietf.org >> Subject: RE: [Speermint] Basic Peering Requirements >> >> Concerning de-regulation: >> >> If a group were to try to keep the system closed and certain call >> routing information private, whether intentionally or unintentionally to >> raise barriers to competition; I think the regulators would feel >> compelled to step in and make such call routing information publicly >> available. >> >> So, if you want to keep the regulators idle, design the system so that >> any VSP that can reliably authenticate themselves can take the sequence >> of steps that leads them to the ingress points and allows them to >> deliver calls to another VSP. The key is having secure controls versus >> having static clubs. >> >> Mike >> >> >>> -----Original Message----- >>> From: Otmar Lendl [mailto:lendl@nic.at] >>> Sent: Monday, October 23, 2006 11:40 AM >>> To: Richard Shockey >>> Cc: speermint@ietf.org; 'Nieminen Klaus' >>> Subject: Re: [Speermint] Basic Peering Requirements >>> >>> On 2006/10/23 17:10, Richard Shockey wrote: >>>>> There are several arguments why carriers will never put >>> there TNs in >>>>> public ENUM trees, e.g.: >>>>> - "Carriers are afraid that others can query how many >>>>> numbers(customers) they have." >>>>> - "Carriers are afraid that other carriers can find out >>> the current >>>>> carrier-of-record of an enterprise and to poach this customer" >>>> Both of these arguments as you mention are completely specious.. >>> We know. Klaus just quoted what we sometimes hear from carriers. >>> You know, they don't always make sense. >>> >>>>> maybe others can tell us why carriers never will put >>> there numbers >>>>> into public infrastructure ENUM? >>>> >>>> The real reason carriers will never put their numbers into >>> any form of >>>> public infrastructure ENUM is two fold. >>>> >>>> A. Only a mad man would put the location of critical VoIP ingress >>>> elements edge or otherwise into a public DNS infrastructure. The >>>> potential for DDoS alone is massive. >>> Agreed. That's the reason we developed the domain policy DDDS >>> proposal which can used to really de-couple the URI from the >>> ingress elements. >>> E.g. if the only things you can learn from the public DNS is >>> that example.com is a member of federation X and Y, and uses >>> >>> fedx-ingress.example.com A 10.0.0.42 >>> >>> and >>> >>> fedy-ingress.example.com A 172.27.10.10 >>> >>> as the ingress elements on the respective shared L3 >>> infrastructure then I don't see the DDoS potential here. >>> >>>> B. Infrastructure ENUM as it has been proposed almost guarantees >>>> national regulatory delegation and oversight and most >>> carriers are in >>>> favor of DE-Regulation of telecom not RE-Regulation. >>> Wait a second: you're now switching from the issue of a >>> public tree to the question of whether that should be a >>> NRA-approved one under ie164.arpa. >>> >>> If the regulator proves to be a burden in all this, then >>> nothing stops an industry consortium to establish a tree >>> under a different apex. (As the forest of trees out there shows.) >>> >>>> C. Some form of trusted registry of TN 2 URI mappings is absolutely >>>> necessary to insure interoperability but I suspect it will >>> be carriers >>>> them selves that attempt to control the organization and >>> distribution >>>> of such data. >>> Oh yes. Who argued against the carriers establishing a such a tree? >>> >>> IMHO the best case is if the regulators *and* the carries >>> agree on someone who runs that trusted registry. Whether that >>> will then be a private tree or a public one, is an >>> independent question. >>> >>> Given the fact that the number of "carriers" is bound to >>> increase and international resolution of TN->URI will be an >>> issue, I doubt that it will be easy to establish a sensible, >>> universal rule which describes who should have access to that >>> private tree. >>> >>> Once the number of organizations which have access to a >>> private tree exceeds as certain number, the security benefits >>> you get from keeping it non-public are dwarfed by the >>> complexities of maintaining access control rules. >>> >>> Or, as other events prove every now and then, the PSTN method >>> of maintaining security ("trust all other carriers") is >>> already breaking down right now. So why perpetuate that model? >>> >>> It's just case of security by obscurity. >>> >>> /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 -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 03:49:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcH2C-0003MD-6c; Tue, 24 Oct 2006 03:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcH2B-0003M8-61 for speermint@ietf.org; Tue, 24 Oct 2006 03:49:15 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcH26-0003K9-Nj for speermint@ietf.org; Tue, 24 Oct 2006 03:49:15 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id C0D972100E5; Tue, 24 Oct 2006 09:49:00 +0200 (CEST) Message-ID: <453DC56C.8090006@pernau.at> Date: Tue, 24 Oct 2006 09:49:00 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <08af01c6f6df$370d5b80$640fa8c0@cis.neustar.com> In-Reply-To: <08af01c6f6df$370d5b80$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'Otmar Lendl' , 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: > In the U.S., and I suspect in other countries, if anyone, including a less > regulated (can't really say unregulated) carrier were to put its numbers in > a public database, I am quite certain there would be an uproar, and I'm > pretty sure the regulator would act. That kind of thing is just too > sensitive these days. Just to prove that not every regulator shares your opinion: Here is the list of all assigned Austrian numbers/blocks, published by the REGULATOR itself. http://www.rtr.at/WWW/RFNr.nsf/lookuid/9581010CA79E0631C125720D0044718F/$file/www_dienste_csv.zip have fun klaus > > Since there were some objections even to OPT-IN scenarios, I think the whole > area is fraught with difficulty. YMMV. > > >> BTW If you put all allocated (including unassigned) numbers in the DNS >> then you provide no more info than can be obtained by war dialing every >> legitimate sequence. > And I repeat, I am firmly in the camp that believes security by obscurity is > not real security. However, we deal with perceptions as well as truths and > since we're looking for practical answers to real world problems here, I > think we need solutions for all routing data not in public databases. > > If the world ran the way I, personally, wanted, we'd peer on the Internet, > and we wouldn't need federations. The reality is quite different. I'd like > to not waste my time in this WG working on solutions that don't get > widespread adoption. Been there, done that. > > If you assume ANY public routing data, it's my opinion you have a solution > that will not be widely implemented. If you have a solution that works with > all private databases, we have a chance. That means the word "DNS", at > least a public DNS, can't appear in the answer. I don't like that > situation. I'd like to eventually change the perceptions that make that > situation arise, but in the mean time, I'd like to get VoIP to VoIP traffic > off the PSTN please. > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 06:02:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJ64-0007du-4D; Tue, 24 Oct 2006 06:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJ63-0007dp-AH for speermint@ietf.org; Tue, 24 Oct 2006 06:01:23 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcJ62-0001EP-1C for speermint@ietf.org; Tue, 24 Oct 2006 06:01:23 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id 7518F210092; Tue, 24 Oct 2006 12:01:00 +0200 (CEST) Message-ID: <453DE45C.5010801@pernau.at> Date: Tue, 24 Oct 2006 12:01:00 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Pfautz, Penn L, GBLAM" Subject: Re: [Speermint] Basic Peering Requirements References: <34DA635B184A644DA4588E260EC0A25A0DEDCE97@ACCLUST02EVS1.ugd.att.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0DEDCE97@ACCLUST02EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Otmar Lendl , Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Pfautz, Penn L, GBLAM wrote: > I wouldn't count on routing data necessarily being public even if TNs > are. Publishing a phone number in ENUM does not imply that routing information/ingress point is public. This is what Otmar's domainpolicy and federation drafts describes, and what is already implemented in the openser domainpolicy module: A short description: 1. ENUM entry for +43 123 3.2.1.3.4 NAPTR 100 10 "u" "e2u+SiP" "!^.*$!sip:123@mydom.foo!" . This reveals an identifier to mydom.foo. 2. Now, as defined in draft-lendl-domain-policy-ddds find out the peering policy of mydom.foo by looking up NAPTRs of mydom.foo. mydom.foo. NAPTR 10 50 ("U" "D2P+SIP:fed" "!^.*$!http://xyconnect.foo/!" . ) mydom.foo. NAPTR 20 50 ("U" "D2P+SIP:fed" "!^.*$!http://crossconnect.foo/!" . ) In this example mydom can be contacted via the xyconnect.foo federation and the crossonnect.foo federation. The final step - how to come from the URI sip:123@mydom.foo to the ingress point (IP address, port, transport protocol) - is a matter of the federation policy. This may be public or private - a federation policy. Thus, ENUM does not imply that routing data is public. -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 07:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcK7L-0001zy-K9; Tue, 24 Oct 2006 07:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcK7J-0001zt-DC for speermint@ietf.org; Tue, 24 Oct 2006 07:06:45 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcK7E-0001Ax-7u for speermint@ietf.org; Tue, 24 Oct 2006 07:06:45 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GcK70-0001bq-Vo; Tue, 24 Oct 2006 06:06:28 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Pfautz, Penn L, GBLAM'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Tue, 24 Oct 2006 07:06:26 -0400 Message-ID: <0baf01c6f75c$7624c150$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4A== In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C283@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Mike I think federations are a useful exercise for a long time. I want to do SPEERMINT, with federations, with private data. Although I can deal with TN to domain, and domain to ingress point, that is not ENUM, and it's not particularly efficient. I'm willing to define it two step, and then allow optimization if it makes people feel better. I want to focus on routing by TN because the folks who are all worked up about private routing data only use TNs. I'm not opposed to having federation solutions involving domains, but I'd prefer they were explicitly domains and not URIs. Whatever we base routing on, I really want to work with the basic Internet routing scheme of reachability advertisements. I can, and prefer, to do this in a very simplistic way now. I don't want to deal with BGP like issues for a long time. I do think we have to deal with number porting with several minute updates. I think we have to deal with complex, multihop routes, especially for international routes. I think we have to deal with federations who compete, and transit providers who compete, and carriers who compete at multiple levels. I want to do something new. I have no interest in re-inventing the PSTN. I just have to deal with carriers who grew up with the PSTN and think a certain way. We can move them a great deal, but we can't get them to give up on a few ideas yet, like how public the routing data is. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Monday, October 23, 2006 4:43 PM > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Brian, > > You don't want to talk about federation, yet that is just an expression > for a type of peering. So, you want to do Speermint, you just don't > want to do peering??? > > You want to skip dealing with domains, which is the host part of a SIP > URI and remain focused on routing based on TNs. So, I presume we just > use tel:URIs? > > Today, DNS is how you end up with an IP address which is routing data > that allows you to put a data packet into the network. But, you don't > want any of that to be "public", but rather shared among a closed group. > > Sounds like you already have the ideal solution. It's called the PSTN. > You seem to be arguing against doing anything new. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, October 23, 2006 4:10 PM > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar > > Lendl'; 'Richard Shockey' > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > We need to distinguish between peering for voluntary exchange of > > > traffic (not currently regulated at least in the US) and > > Peering as a > > > replacement for legally required interconnection in the > > current PSTN. > > > For the former carriers (and anyone else) can and will do what they > > > want. The latter is likely to eventually be subject to some > > rules. But > > > consider also that where interconnection is mandated it comes with > > > rules and is not open to all parties. > > > You want to interconnect with the PSTN in the US you need to be > > > certified; otherwise you buy end user services. > > In the U.S., and I suspect in other countries, if anyone, > > including a less regulated (can't really say unregulated) > > carrier were to put its numbers in a public database, I am > > quite certain there would be an uproar, and I'm pretty sure > > the regulator would act. That kind of thing is just too > > sensitive these days. > > > > Since there were some objections even to OPT-IN scenarios, I > > think the whole area is fraught with difficulty. YMMV. > > > > > > > > > > BTW If you put all allocated (including unassigned) numbers > > in the DNS > > > then you provide no more info than can be obtained by war dialing > > > every legitimate sequence. > > And I repeat, I am firmly in the camp that believes security > > by obscurity is not real security. However, we deal with > > perceptions as well as truths and since we're looking for > > practical answers to real world problems here, I think we > > need solutions for all routing data not in public databases. > > > > If the world ran the way I, personally, wanted, we'd peer on > > the Internet, and we wouldn't need federations. The reality > > is quite different. I'd like to not waste my time in this WG > > working on solutions that don't get widespread adoption. > > Been there, done that. > > > > If you assume ANY public routing data, it's my opinion you > > have a solution that will not be widely implemented. If you > > have a solution that works with all private databases, we > > have a chance. That means the word "DNS", at least a public > > DNS, can't appear in the answer. I don't like that > > situation. I'd like to eventually change the perceptions > > that make that situation arise, but in the mean time, I'd > > like to get VoIP to VoIP traffic off the PSTN please. > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 07:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcKHH-0002KK-01; Tue, 24 Oct 2006 07:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcKHF-0002JT-Qc for speermint@ietf.org; Tue, 24 Oct 2006 07:17:01 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcKH8-0002SG-OD for speermint@ietf.org; Tue, 24 Oct 2006 07:17:01 -0400 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 Date: Tue, 24 Oct 2006 13:16:41 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550160626E@isr-jlm-mail.Kayote.com> In-Reply-To: <0baf01c6f75c$7624c150$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use Case draft Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfw From: "David Schwartz" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: "Livingood, Jason" Subject: [Speermint] Use Case draft X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org While I missed the deadline for submission I felt there was value in sharing this with the community so I am posting a link where the draft can be found. http://www.kayote.com/web/docs/Drafts/draft-schwartz-speermint-use-cases -federations-00.txt=20 Please feel free to comment. David _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 08:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLSP-0004T3-Sp; Tue, 24 Oct 2006 08:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLSO-0004Sx-VX for speermint@ietf.org; Tue, 24 Oct 2006 08:32:36 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcLSN-0007cO-Lf for speermint@ietf.org; Tue, 24 Oct 2006 08:32:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GcLSI-0003JI-8I; Tue, 24 Oct 2006 07:32:30 -0500 From: "Brian Rosen" To: "'Nieminen Klaus'" , Subject: RE: [Speermint] Basic Peering Requirements Date: Tue, 24 Oct 2006 08:32:31 -0400 Message-ID: <0bc901c6f768$7b2af4b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9wABWkGAABaOpDAACvOcEA== In-Reply-To: <07BC6C0D40216E44A34BE6701694FE86038B4A54@POSTI.laru.local> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I think we should distinguish privacy from discovering some "routing" > information (e.g. the operator providing services for a given > number/URI). I don't know what was the main problem in US, but I suspect > that publishing just the provider may not be the one that caused such > reservations. I'm I wrong? Yes, you are wrong. There is great reluctance to have a public database which lists the carrier of record for a given TN. > > Some people don't want to publish the connectivity between their number > and other personal information (e.g. name and address) and they have > legal right to prevent that. Yes, that is even more sensitive, but we are agreeing that is not the subject here > > However, we want to publish the operator providing services for a given > number and the reason behind this is charging. A caller should be able > (well in practise this is more likely just in theory) to know the cost > of making a call to a given number beforehand. Determining charging is not dependent on a public database of TN to providers > > For example in Finland this has been implemented as a web-page > (http://www.siirretytnumerot.fi/) where you input the number and get the > operator as a response. I don't know in how many other countries this > information is easily publicly available, but I don't see publishing it > as a big problem... of course this could reveal, what numbers are used > and what are not if that makes difference. This IS part of the problem: revealing which numbers are active numbers. > > In addition, one comment because of Richard's question: > > > Hence the heretical statement, "Is ENUM Irrelevant?" > > What kind of ENUM do you mean? What I have understood, the "routing DB" > may not be public, but what I have heard at least most use ENUM > technology. That's at least what we have been planning in Finland. Yeah, that is happening (private ENUM). It's not the only way, but it's a standardized way. You can also get a plain SIP redirect. Brian _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 09:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLyQ-0004ij-GP; Tue, 24 Oct 2006 09:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLyP-0004ie-7Q for speermint@ietf.org; Tue, 24 Oct 2006 09:05:41 -0400 Received: from pb94.dyndns.org ([213.239.207.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcLyK-0006dO-TN for speermint@ietf.org; Tue, 24 Oct 2006 09:05:41 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by pb94.dyndns.org (Postfix) with ESMTP id EE364210098; Tue, 24 Oct 2006 15:05:32 +0200 (CEST) Message-ID: <453E0F9C.5020600@pernau.at> Date: Tue, 24 Oct 2006 15:05:32 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Speermint] Basic Peering Requirements References: <07cb01c6f6ca$fd922d40$640fa8c0@cis.neustar.com> In-Reply-To: <07cb01c6f6ca$fd922d40$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'Stastny Richard' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian Rosen wrote: >> The mapping from TN to domain, and domain to ingress point are 2 >> different, orthogonal tasks. And there are different solution for both >> of them. >> >> e.g. for TN->domain there is user ENUM, infrastructure ENUM, private >> ENUM trees, lookup tables, number portability databases, ... >> > Klaus, that is rewriting history. ENUM is TN to URI, not domain. It was Uups. Sorry. Of course I meant TN->URI > intended that the URI be the place the call was sent to, period. If we were > to get a domain, then it wouldn't be a NAPTR, right? > > The ingress point thing is an add-on. You are suggestion that we rewrite > the ENUM documents to describe what you get out of ENUM as a domain, and > then there is another step you want to add that is domain to URI. No, as stated above. I do not want a new mapping, I just meant TN->URI > Furthermore, you really want 3 steps, right? TN to domain, domain to IMO 3 steps are not a problem. If it is DNS based, the first call will have little higher call setup delay, but all subsequent calls will be cached and answered fast. regards klaus > federation, federation to ingress point. You have to do that; ingress point > is definitely dependent on origination side, and thus both the peer and the > federation who is sending the destination the call. > > Brian > -- Klaus Darilion nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 09:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcM4w-0001IS-4l; Tue, 24 Oct 2006 09:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcM4u-0001IN-Ue for speermint@ietf.org; Tue, 24 Oct 2006 09:12:24 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcM4u-0007rT-FF for speermint@ietf.org; Tue, 24 Oct 2006 09:12:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GcM4c-0000Cy-80; Tue, 24 Oct 2006 08:12:06 -0500 From: "Brian Rosen" To: "'Klaus Darilion'" Subject: RE: [Speermint] Basic Peering Requirements Date: Tue, 24 Oct 2006 09:12:04 -0400 Message-ID: <0bd401c6f76e$03935bd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb3P9N/zAMiyWeoRrq9V5p2JiVj2AAKPEfQ In-Reply-To: <453DC39C.9080300@pernau.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: 'Nieminen Klaus' , speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Klaus No matter how wrong you think they are, that is the state of affairs here. Let's take a small example, not at all the only problem: unlisted numbers. If you have a public database of all active numbers and you have access to a directory ("white pages"), then you can determine the set of unlisted numbers by walking through the two databases. The regulator currently WILL NOT ALLOW a public list of active telephone numbers. I think in the time frame of version 1 of SPEERMINT, this will not change. We can declare them to be stupid, engineer a solution that won't work in the U.S., and be done, or we can just deal with it. I suspect that in countries that allow local number portability, the same concerns arise. I suspect that where there are blocks of numbers assigned to a carrier, and the specific numbers don't exist in a public database, that they are more willing to make that public. Here in the U.S., the "Pooling Administrator" does publish the assignment of 1000s blocks. That is insufficient, since we do support LNP. The "NPAC", which is the porting database is definitely NOT public. Brian > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Tuesday, October 24, 2006 3:41 AM > To: Brian Rosen > Cc: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey'; > 'Nieminen Klaus'; speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements > > Brian Rosen wrote: > > Well, here in the U.S., the stated reluctance of the regulator to permit > TNs > > in a public database is due to the fact that people's telephone numbers > > would be in a public database. They are concerned with the privacy > aspects > > of the problem. So, they actually WANT private databases where people's > > Then I suggest some education for your regulators instead of accepting > their concerns. > > Yes, publishing phone numbers in ENUM makes them public - but publishing > in ENUM does not reveal privacy data. > > > telephone numbers are concerned. And this concern started in User ENUM, > not > > I do not understand why regulators have privacy concerns with user ENUM. > The user decides if it wants to publish its number it it should not be > overruled by a regulator. > > regards > klaus > > > > just infrastructure ENUM. I understand there are other regulators who > have > > this concern. > > > > I do think there is some validity to your concern about one carrier, or > a > > group of carriers, restricting access to their customers for termination > > from other carriers, and I agree the regulators would probably not allow > it. > > Making routing data public has not yet been, and I don't think will be, > the > > remedy. > > > > Brian > > > >> -----Original Message----- > >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > >> Sent: Monday, October 23, 2006 12:01 PM > >> To: Otmar Lendl; Richard Shockey > >> Cc: Nieminen Klaus; speermint@ietf.org > >> Subject: RE: [Speermint] Basic Peering Requirements > >> > >> Concerning de-regulation: > >> > >> If a group were to try to keep the system closed and certain call > >> routing information private, whether intentionally or unintentionally > to > >> raise barriers to competition; I think the regulators would feel > >> compelled to step in and make such call routing information publicly > >> available. > >> > >> So, if you want to keep the regulators idle, design the system so that > >> any VSP that can reliably authenticate themselves can take the sequence > >> of steps that leads them to the ingress points and allows them to > >> deliver calls to another VSP. The key is having secure controls versus > >> having static clubs. > >> > >> Mike > >> > >> > >>> -----Original Message----- > >>> From: Otmar Lendl [mailto:lendl@nic.at] > >>> Sent: Monday, October 23, 2006 11:40 AM > >>> To: Richard Shockey > >>> Cc: speermint@ietf.org; 'Nieminen Klaus' > >>> Subject: Re: [Speermint] Basic Peering Requirements > >>> > >>> On 2006/10/23 17:10, Richard Shockey wrote: > >>>>> There are several arguments why carriers will never put > >>> there TNs in > >>>>> public ENUM trees, e.g.: > >>>>> - "Carriers are afraid that others can query how many > >>>>> numbers(customers) they have." > >>>>> - "Carriers are afraid that other carriers can find out > >>> the current > >>>>> carrier-of-record of an enterprise and to poach this customer" > >>>> Both of these arguments as you mention are completely specious.. > >>> We know. Klaus just quoted what we sometimes hear from carriers. > >>> You know, they don't always make sense. > >>> > >>>>> maybe others can tell us why carriers never will put > >>> there numbers > >>>>> into public infrastructure ENUM? > >>>> > >>>> The real reason carriers will never put their numbers into > >>> any form of > >>>> public infrastructure ENUM is two fold. > >>>> > >>>> A. Only a mad man would put the location of critical VoIP ingress > >>>> elements edge or otherwise into a public DNS infrastructure. The > >>>> potential for DDoS alone is massive. > >>> Agreed. That's the reason we developed the domain policy DDDS > >>> proposal which can used to really de-couple the URI from the > >>> ingress elements. > >>> E.g. if the only things you can learn from the public DNS is > >>> that example.com is a member of federation X and Y, and uses > >>> > >>> fedx-ingress.example.com A 10.0.0.42 > >>> > >>> and > >>> > >>> fedy-ingress.example.com A 172.27.10.10 > >>> > >>> as the ingress elements on the respective shared L3 > >>> infrastructure then I don't see the DDoS potential here. > >>> > >>>> B. Infrastructure ENUM as it has been proposed almost guarantees > >>>> national regulatory delegation and oversight and most > >>> carriers are in > >>>> favor of DE-Regulation of telecom not RE-Regulation. > >>> Wait a second: you're now switching from the issue of a > >>> public tree to the question of whether that should be a > >>> NRA-approved one under ie164.arpa. > >>> > >>> If the regulator proves to be a burden in all this, then > >>> nothing stops an industry consortium to establish a tree > >>> under a different apex. (As the forest of trees out there shows.) > >>> > >>>> C. Some form of trusted registry of TN 2 URI mappings is absolutely > >>>> necessary to insure interoperability but I suspect it will > >>> be carriers > >>>> them selves that attempt to control the organization and > >>> distribution > >>>> of such data. > >>> Oh yes. Who argued against the carriers establishing a such a tree? > >>> > >>> IMHO the best case is if the regulators *and* the carries > >>> agree on someone who runs that trusted registry. Whether that > >>> will then be a private tree or a public one, is an > >>> independent question. > >>> > >>> Given the fact that the number of "carriers" is bound to > >>> increase and international resolution of TN->URI will be an > >>> issue, I doubt that it will be easy to establish a sensible, > >>> universal rule which describes who should have access to that > >>> private tree. > >>> > >>> Once the number of organizations which have access to a > >>> private tree exceeds as certain number, the security benefits > >>> you get from keeping it non-public are dwarfed by the > >>> complexities of maintaining access control rules. > >>> > >>> Or, as other events prove every now and then, the PSTN method > >>> of maintaining security ("trust all other carriers") is > >>> already breaking down right now. So why perpetuate that model? > >>> > >>> It's just case of security by obscurity. > >>> > >>> /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 > > > -- > Klaus Darilion > nic.at _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 10:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNPR-0001OS-OK; Tue, 24 Oct 2006 10:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNPQ-0001MM-2N for speermint@ietf.org; Tue, 24 Oct 2006 10:37:40 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNPL-00024m-LH for speermint@ietf.org; Tue, 24 Oct 2006 10:37:40 -0400 Received: from RSHOCKEYLTXP (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9OEbQUG002161; Tue, 24 Oct 2006 07:37:33 -0700 From: "Richard Shockey" To: "'Nieminen Klaus'" , Subject: RE: [Speermint] Basic Peering Requirements Date: Tue, 24 Oct 2006 10:37:03 -0400 Message-ID: <005101c6f779$e33f0760$75201f0a@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: <07BC6C0D40216E44A34BE6701694FE86038B4A54@POSTI.laru.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAABDXK9wABWkGAABaOpDAAD4QJYA== X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > In addition, one comment because of Richard's question: > > > Hence the heretical statement, "Is ENUM Irrelevant?" > > What kind of ENUM do you mean? What I have understood, the "routing DB" > may not be public, but what I have heard at least most use ENUM > technology. Your observation about the use of "enum technology" is correct what I was getting at was the policies and procedures surrounding e164.arpa That's at least what we have been planning in Finland. > > regards, > > - Klaus > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 10:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNdD-000466-2Z; Tue, 24 Oct 2006 10:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNdB-00045i-3i for speermint@ietf.org; Tue, 24 Oct 2006 10:51:53 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNd9-0004em-LN for speermint@ietf.org; Tue, 24 Oct 2006 10:51:53 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 23F6350F8; Tue, 24 Oct 2006 10:51:11 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 10:51:10 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Speermint] Use Case draft Date: Tue, 24 Oct 2006 10:51:09 -0400 Message-ID: In-Reply-To: <1DDB0D3CC4E7F14FAE946361C0A606550160626E@isr-jlm-mail.Kayote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use Case draft Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfwAAd3ZEA= From: "Uzelac, Adam" To: "David Schwartz" , X-OriginalArrivalTime: 24 Oct 2006 14:51:10.0416 (UTC) FILETIME=[D8093D00:01C6F77B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David - excellent draft and thank you for compiling! One thing that I noticed and thought a bit odd was your definition of "Bi-Lateral or direct peering". You state - "For the purposes of this document, VSPs upload their numbers to an externally reachable location service denoted as D-PSP." - To me, this is not direct because the location function that you define is done outside of the originating-domain/terminating-domain relationship. =20 Per the speermint terminology draft: "Direct peering describes those cases in which two service providers interconnect without using an intervening layer 5 network." =20 -AU -----Original Message----- From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 Sent: Tuesday, October 24, 2006 7:17 AM To: speermint@ietf.org Cc: Livingood, Jason Subject: [Speermint] Use Case draft While I missed the deadline for submission I felt there was value in sharing this with the community so I am posting a link where the draft can be found. http://www.kayote.com/web/docs/Drafts/draft-schwartz-speermint-use-cases -federations-00.txt=20 Please feel free to comment. David _______________________________________________ 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 From speermint-bounces@ietf.org Tue Oct 24 11:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNl9-0000Ek-Da; Tue, 24 Oct 2006 11:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcNl7-0000EZ-My for speermint@ietf.org; Tue, 24 Oct 2006 11:00:05 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcNl2-0006bA-JL for speermint@ietf.org; Tue, 24 Oct 2006 11:00:05 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id ABB611A366; Tue, 24 Oct 2006 16:59:52 +0200 (CEST) Date: Tue, 24 Oct 2006 16:59:52 +0200 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20061024145952.GW19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [Speermint] Re: draft-rosen-speermint-peeringbcp-v1-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, here are some comments on draft-rosen-speermint-peeringbcp-v1-00.txt: That's a well-written draft which will be helpful for a productive discussion in San Diego. >2. Overview > > The SIP standard [RFC3261] models much of its protocol operations on > familiar Internet applications such as email and the web. For > example, SIP clients contact remote domains by resolving SIP URIs > which are, like email addresses, composed of a username and domain > name portion. As is the case with email, a client need not have any > pre-association with a remote domain in order to initiate a session > with a user in that domain. The security of SIP is designed to > counter the sorts of threats that arise on the Internet - threats > based on eavesdropping, packet spoofing, impersonation of identity, > and the like. Good points. > Endpoints must assume responsibility for most of these > security functions. Like email and the web, SIP assumes that the > Internet end-to-end model applies: that is, that entities using SIP > have unimpeded connectivity to one another. This doesn't follow. SIP works fine if the user endpoints have firewalls which restrict SIP communication (not RTP) to their respective proxy servers only. Just use Record-Route: and you're done. You won't win bonus points with the SIP purists, but it works fine. > There are however operational models in which the assumptions of > traditional Internet applications do not hold up. The end-to-end > reachability of user agents is commonly obstructed by network-layer > impediments like network address translators (NATs) or firewalls. > Many SIP user agents, and SIP deployments, utilize telephone numbers > rather than email-like SIP URIs, which introduces requirements for a > new resolution process in the routing of requests. Some SIP service > providers are also uncomfortable leaving the management of security > to user agents, for a variety of reasons. > > To a voice service provider that leverages SIP in a commercial > offering, these concerns are all basic issues of usability. Most SIP > user agents today have dial pads, and users are accustomed to the use > of telephone numbers of voice applications. Without a transparent > and automatic NAT traversal function such as ICE (which in turn > relies on STUN and TURN services), SIP calls on the public Internet > may face serious problems establishing media paths. Users similarly > cannot be burdened with understanding and supporting security > functions. Yes, sure. Then just firewall them and route all sip messages via the provider's proxy which handles the NAT and security requirements. > Solving these concerns also motivates voice service providers to > establish formal peering relationships with one another. The concerns listed above are an argument why SIP end-devices should not talk SIP directly to anybody on the Internet. These concerns are completely orthogonal on whether service providers should can run open SIP ingress points. The concerns below are more important: > Peering > represents an agreement between parties to permit the exchange of > traffic, generally in accordance with some pre-established policy. > Without agreement between two VSP domains, for example, on how > telephone numbers are resolved, it is impractical for users in > different domains to call one another. Security, and in particular > authorization, is perhaps the most fundamental reason for peering. > The email model, while quite successful, has a very widespread > problem with undesirable traffic (namely spam), and a comparable > problem for SIP could be quite harmful to commercial offerings. > Peering agreements would allow providers to trace accountable sources > of undesired traffic and to make appropriate authorization decisions > based on traffic sources. These are the real issues we face in speermint. IMHO and all that. > Peering at the session layer can occur on a bilateral basis or a > multilateral basis, where the latter generally takes the form of a > federation (typically in an "assisted" peering configuration). At (We need to clarify the use of the term "federation". I'm not 100% sure we're on the same page there. I'll expand that in a seperate mail.) > lower layers of the Internet architecture, there are also various > forms of bilateral and multilateral connections which are established > between Internet service providers; the more service providers > require interconnection, however, the less attractive bilateral > connections become, if only because the cost of constructing physical > links between networks becomes unwieldy. While it might seem that Why "physical links"? If you're just worried about SPIT, and thus want to accept incoming calls only from pre-screened peering partners, then TLS with appropriate certificates over the public Internet is just fine. There is no need to establish physical links just because you want to know whom you're talking to. > there is no similar difficulty with the establishment of bilateral > peering at the session layer, there are a number of reasons why voice > service providers might want to minimize the number of connections > they establish to peer networks: for example, to reduce load on > gateways (SBCs and IPSec gateways), or to simplify authorization or > routing decisions by delegating that responsibility to network > elements operated by the federation. Could be. > > Moreover, if there are media-based applications which need to be made > available to the federation as a whole, a point of lower layer > interconnection, such as a traditional layer 3 interexchange point, > is an ideal place to stage them. Any such applications like > transcoders and media relays would best be situated in a layer 3 > point of interconnection. Fine. > > The following sections detail some of the functions that might be > performed at a peering point and briefly explain how they benefit > from being deployed in a federation environment. > >2.1. Addressing and Routing > > Several forms of private directories are useful in a peering context. > Aside from the widely-attested need to translate telephone numbers > into an identifier that can be routed on the Internet (typically via > ENUM or an ENUM-like mechanisms), there is a further need in a > peering environment to manage points of egress and ingress on the > networks of peers. I'm not sure I get the correct meaning here: Do you mean ingress/egress point of one VSP towards other VSPs inside a shared federation, or do you mean the ingress point of the federation over which someone external to that federation can reach federation members? > While this can take the form of a conventional > DNS lookup, such a lookup could return IP addresses that are only > routable within a peering point, thereby restricting their access to > the federation. > >2.2. Connectivity >2.3. Security (Accountability) >2.4. Quality >2.5. Protocol Mediation Ok, fine. >2.6. Model >3. Responsibilities of Federations As mentioned above, I'd also accept more lightweight federations. Otherwise, that's a good list of things a federation can manage. >3.1.6. CODEC choices An open question here is whether such strict rules on the codecs are sensible. Perhaps yes, for established media types. We need to be careful that such federations won't become the bottlenecks when deploying new SIP - based applications. > >3.4. Routing > > The Federation MUST specify the mechanism by which peers discover > routing information for the exchange of traffic. Routing mechanisms > MUST permit any peer to discover how to route to any other peer's > subscribers (or, in the case of a transit peer, the indirect peer's > subscribers) based on the Address of Record. Where transit peers are Sorry, I have difficulties parsing that sentence. Is this routing based on SIP AoRs and thus domains? Could you please provide a definition of "transit peer"? > permitted, the Federation MUST either prohibit two or more transit > peers from providing access from the same indirect peer (requiring > the indirect peer to choose which transit peer represents it at the > Federation), or provide provide mechanisms allow an origination > network to choose from more than one transit peer who provides > transit to the indirect peer. > > For interoperability reason's, each Federation MUST support at least > a Federation supplied ENUM query interface where the Federation > supports TN based addressing. If the ENUM data is not in the public > DNS tree, the Federation MUST support a provisioning mechanism for a > peer to supply it's TNs for peering Shouldn't that better be formulated as If a Federation supports TN based addressing, then it MUST either refer to a public ENUM tree or a support a Federation supplied ENUM query interface. or do I misread the intentions? > The Federation SHOULD provide mechanisms for peers to change their > routing information dynamically. The change mechanism SHOULD have > reasonable ways to bound the time from the initiation of the change > to it's effectivity for all peers in the Federation /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 11:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOPN-0004I5-3A; Tue, 24 Oct 2006 11:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOPL-0004GN-UA for speermint@ietf.org; Tue, 24 Oct 2006 11:41:39 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcOKb-0004cG-23 for speermint@ietf.org; Tue, 24 Oct 2006 11:36:50 -0400 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] Use Case draft Date: Tue, 24 Oct 2006 17:36:42 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550160634D@isr-jlm-mail.Kayote.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use Case draft Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfwAAd3ZEAAANKpwA== From: "David Schwartz" To: "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Adam. Inline. > David - excellent draft and thank you for compiling! One thing that I > noticed and thought a bit odd was your definition of "Bi-Lateral or > direct peering". You state - "For the purposes of this document, VSPs > upload their numbers to an externally reachable location service denoted > as D-PSP." - To me, this is not direct because the location function > that you define is done outside of the > originating-domain/terminating-domain relationship. =20 DS: The point I am trying to make here is as follows. When 2 VSPs want to share their user information with each other they can: 1. Do the equivalent of a zone transfer of all their users to each other so that a local copy of this information is available to the O-VSP. 2. Have the O-VSP send an INVITE to the T-VSPs registrar and have T-VSP either proxy the INVITE or send a 3XX back 3. Same as 2 only use ENUM to query a private tree operated at T-VSP 4. Store this information in a mutually accessible location 4a. Possibly push/pull this information to a local copy at both O-VSP and T-VSP Options 1 will almost never happen. Why? Because in reality new users are constantly being added/removed not to mention porting in/out of numbers and since each VSP has many bilateral relationships each possibly of a different nature, this model will not scale as well as other options. Options 2/3 will also probably not happen since again there are multiple relationships and O-VSP will have to send many INVITES to different VSPs to get an answer. Forking in this case is a kludge and doesn't really help.=20 Option 4 (and 4a) is the only reasonable approach. This is the reason for the worldwide push for either ENUM or Infrastructure ENUM. To try to get all the location information into 1 place. Remember. The signaling and media are still traveling between VSPs and hence I still consider this Direct. Would you agree that public ENUM in this case fits the direct model? I think so. So just replace the public ENUM with a private ENUM that does nothing more than hold the data for all interested parties and you have the same thing. > Per the speermint terminology draft: > "Direct peering describes those cases in which two service providers > interconnect without using an intervening layer 5 network." =20 DS: I interpret this as intervening in terms of signaling or media NOT number lookup. Am I wrong? > -AU Thanks for your comments Adam. D. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 12:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPIl-0000GB-IB; Tue, 24 Oct 2006 12:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPIk-0000G6-8l for speermint@ietf.org; Tue, 24 Oct 2006 12:38:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPIg-0008Vt-Qx for speermint@ietf.org; Tue, 24 Oct 2006 12:38:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2006 12:38:51 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OGcobk002619; Tue, 24 Oct 2006 12:38:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9OGcnDM006551; Tue, 24 Oct 2006 12:38:49 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 12:38:49 -0400 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] Basic Peering Requirements Date: Tue, 24 Oct 2006 12:38:41 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C567@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAo3q+g From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 24 Oct 2006 16:38:49.0376 (UTC) FILETIME=[E1E05200:01C6F78A] DKIM-Signature: a=rsa-sha1; q=dns; l=6999; t=1161707930; x=1162571930; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Pfautz, =20Penn=20L, =20GBLAM=22=20, =0A=20=20=20=20=20=20=20 =20=22Otmar=20Lendl=22=20, =20=22Richard=20Shockey=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=BRNHMiW4EVKztzdByCizMVAXku3KqmkTAecHQQ3WUlF+TaI5ENTrliO04vtRmCqhwjFgyVVR BxGSb+xgJGoCvDtvwGSzVKD+YLX3EeWGRu47KgUojqGAUp7LRToHLHsE; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, We may not be so far apart as it might appear. I am not adverse to options that allow a choice of technology or privacy at each step, or to the possibility that several steps may be combined. But, we do need to define those steps and how policy is applied and security assured along the way. We can perhaps be sure that the role of domains and the information from knowing a domain can lead to is better understood. I also do not want to go the BGP-like route. The IP layer addresses that type of routing quite well. But, I do feel that complex, multi-SIP-hop routes is a sure sign that the process is sub-optimal, both technically and business-wise. The quality assurance measurement aspects probably won't keep up. And media path optimization will probably work better with fewer call segments involved. We'll see. Mike > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, October 24, 2006 7:06 AM > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar=20 > Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Mike >=20 > I think federations are a useful exercise for a long time. I=20 > want to do SPEERMINT, with federations, with private data. >=20 > Although I can deal with TN to domain, and domain to ingress=20 > point, that is not ENUM, and it's not particularly efficient.=20 > I'm willing to define it two step, and then allow=20 > optimization if it makes people feel better. >=20 > I want to focus on routing by TN because the folks who are=20 > all worked up about private routing data only use TNs. I'm=20 > not opposed to having federation solutions involving domains,=20 > but I'd prefer they were explicitly domains and not URIs. =20 > Whatever we base routing on, I really want to work with the=20 > basic Internet routing scheme of reachability advertisements.=20 > I can, and prefer, to do this in a very simplistic way now. =20 > I don't want to deal with BGP like issues for a long time. I=20 > do think we have to deal with number porting with several=20 > minute updates. I think we have to deal with complex,=20 > multihop routes, especially for international routes. I=20 > think we have to deal with federations who compete, and=20 > transit providers who compete, and carriers who compete at=20 > multiple levels. >=20 > I want to do something new. I have no interest in=20 > re-inventing the PSTN. I just have to deal with carriers who=20 > grew up with the PSTN and think a certain way. We can move=20 > them a great deal, but we can't get them to give up on a few=20 > ideas yet, like how public the routing data is. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Monday, October 23, 2006 4:43 PM > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > > Cc: Nieminen Klaus; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Brian, > >=20 > > You don't want to talk about federation, yet that is just an=20 > > expression for a type of peering. So, you want to do=20 > Speermint, you=20 > > just don't want to do peering??? > >=20 > > You want to skip dealing with domains, which is the host=20 > part of a SIP=20 > > URI and remain focused on routing based on TNs. So, I=20 > presume we just=20 > > use tel:URIs? > >=20 > > Today, DNS is how you end up with an IP address which is=20 > routing data=20 > > that allows you to put a data packet into the network. =20 > But, you don't=20 > > want any of that to be "public", but rather shared among a=20 > closed group. > >=20 > > Sounds like you already have the ideal solution. It's=20 > called the PSTN. > > You seem to be arguing against doing anything new. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, October 23, 2006 4:10 PM > > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar=20 > > > Lendl'; 'Richard Shockey' > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > We need to distinguish between peering for voluntary=20 > exchange of=20 > > > > traffic (not currently regulated at least in the US) and > > > Peering as a > > > > replacement for legally required interconnection in the > > > current PSTN. > > > > For the former carriers (and anyone else) can and will do what=20 > > > > they want. The latter is likely to eventually be subject to some > > > rules. But > > > > consider also that where interconnection is mandated it=20 > comes with=20 > > > > rules and is not open to all parties. > > > > You want to interconnect with the PSTN in the US you need to be=20 > > > > certified; otherwise you buy end user services. > > > In the U.S., and I suspect in other countries, if anyone,=20 > including=20 > > > a less regulated (can't really say unregulated) carrier=20 > were to put=20 > > > its numbers in a public database, I am quite certain=20 > there would be=20 > > > an uproar, and I'm pretty sure the regulator would act. =20 > That kind=20 > > > of thing is just too sensitive these days. > > > > > > Since there were some objections even to OPT-IN=20 > scenarios, I think=20 > > > the whole area is fraught with difficulty. YMMV. > > > > > > > > > > > > > > BTW If you put all allocated (including unassigned) numbers > > > in the DNS > > > > then you provide no more info than can be obtained by=20 > war dialing=20 > > > > every legitimate sequence. > > > And I repeat, I am firmly in the camp that believes security by=20 > > > obscurity is not real security. However, we deal with=20 > perceptions=20 > > > as well as truths and since we're looking for practical=20 > answers to=20 > > > real world problems here, I think we need solutions for=20 > all routing=20 > > > data not in public databases. > > > > > > If the world ran the way I, personally, wanted, we'd peer on the=20 > > > Internet, and we wouldn't need federations. The reality is quite=20 > > > different. I'd like to not waste my time in this WG working on=20 > > > solutions that don't get widespread adoption. > > > Been there, done that. > > > > > > If you assume ANY public routing data, it's my opinion you have a=20 > > > solution that will not be widely implemented. If you have a=20 > > > solution that works with all private databases, we have a=20 > chance. =20 > > > That means the word "DNS", at least a public DNS, can't appear in=20 > > > the answer. I don't like that situation. I'd like to eventually=20 > > > change the perceptions that make that situation arise, but in the=20 > > > mean time, I'd like to get VoIP to VoIP traffic off the=20 > PSTN please. > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 12:54:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPX5-0003dt-HE; Tue, 24 Oct 2006 12:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPX4-0003dj-SC for speermint@ietf.org; Tue, 24 Oct 2006 12:53:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPWu-00032q-Kq for speermint@ietf.org; Tue, 24 Oct 2006 12:53:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2006 12:53:33 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OGrWYK018843; Tue, 24 Oct 2006 12:53:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9OGrWYJ028165; Tue, 24 Oct 2006 12:53:32 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 12:53:32 -0400 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] Use Case draft Date: Tue, 24 Oct 2006 12:53:31 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C580@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use Case draft Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfwAAd3ZEAAANKpwAADop0w From: "Michael Hammer \(mhammer\)" To: "David Schwartz" , "Uzelac, Adam" , X-OriginalArrivalTime: 24 Oct 2006 16:53:32.0142 (UTC) FILETIME=[F00BB8E0:01C6F78C] DKIM-Signature: a=rsa-sha1; q=dns; l=3296; t=1161708812; x=1162572812; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Use=20Case=20draft |To:=22David=20Schwartz=22=20, =0A=20=20=20=20=20= 20=20=20=22Uzelac, =20Adam=22=20, =20; X=v=3Dcisco.com=3B=20h=3DQ8pCvDFLd2BQml4ghInW5XueqfQ=3D; b=sPLZRIMMCnU81IICB0Fdb47LoGBsno21bzS94+Y6ojjwgnFM+fR8mNCDLeUJQpXfeQIL4MWg CJ0EGeqkneQ/MOcHjp28C24eK933hQ3kx7+StXcGUeQScJRlCQTbGZbV; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org David, I had understood this the same way. That the direct or indirect referred to the SIP INVITE, not the ENUM lookups. Mike =20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com]=20 > Sent: Tuesday, October 24, 2006 11:37 AM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use Case draft >=20 > Hi Adam. >=20 > Inline. >=20 > > David - excellent draft and thank you for compiling! One=20 > thing that I=20 > > noticed and thought a bit odd was your definition of "Bi-Lateral or=20 > > direct peering". You state - "For the purposes of this=20 > document, VSPs=20 > > upload their numbers to an externally reachable location service > denoted > > as D-PSP." - To me, this is not direct because the location=20 > function=20 > > that you define is done outside of the=20 > > originating-domain/terminating-domain relationship. >=20 > DS: The point I am trying to make here is as follows. When 2=20 > VSPs want to share their user information with each other they can: >=20 > 1. Do the equivalent of a zone transfer of all their=20 > users to each other so that a local copy of this information=20 > is available to the O-VSP. > 2. Have the O-VSP send an INVITE to the T-VSPs registrar=20 > and have T-VSP either proxy the INVITE or send a 3XX back > 3. Same as 2 only use ENUM to query a private tree=20 > operated at T-VSP > 4. Store this information in a mutually accessible location > 4a. Possibly push/pull this information to a local=20 > copy at both O-VSP and T-VSP >=20 > Options 1 will almost never happen. Why? Because in reality=20 > new users are constantly being added/removed not to mention=20 > porting in/out of numbers and since each VSP has many=20 > bilateral relationships each possibly of a different nature,=20 > this model will not scale as well as other options. >=20 > Options 2/3 will also probably not happen since again there=20 > are multiple relationships and O-VSP will have to send many=20 > INVITES to different VSPs to get an answer. Forking in this=20 > case is a kludge and doesn't really help.=20 >=20 > Option 4 (and 4a) is the only reasonable approach. This is=20 > the reason for the worldwide push for either ENUM or=20 > Infrastructure ENUM. To try to get all the location=20 > information into 1 place. Remember. The signaling and media=20 > are still traveling between VSPs and hence I still consider=20 > this Direct. Would you agree that public ENUM in this case=20 > fits the direct model? I think so. So just replace the public=20 > ENUM with a private ENUM that does nothing more than hold the=20 > data for all interested parties and you have the same thing. >=20 > > Per the speermint terminology draft: > > "Direct peering describes those cases in which two service=20 > providers=20 > > interconnect without using an intervening layer 5 network." >=20 > DS: I interpret this as intervening in terms of signaling or=20 > media NOT number lookup. Am I wrong? >=20 > > -AU >=20 > Thanks for your comments Adam. >=20 > D. >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 12:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPYX-0004CQ-Bv; Tue, 24 Oct 2006 12:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPYW-0004CD-Ph for speermint@ietf.org; Tue, 24 Oct 2006 12:55:12 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPYK-0003Pi-90 for speermint@ietf.org; Tue, 24 Oct 2006 12:55:12 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GcPXo-0001uT-QL; Tue, 24 Oct 2006 11:54:29 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Pfautz, Penn L, GBLAM'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Tue, 24 Oct 2006 12:54:31 -0400 Message-ID: <0c5401c6f78d$155cf1e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAo3q+gAADi+VA= In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C567@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I'm sure we can converge. Any public database can be made private and vice versa, if the parties agree. One of the things that IS hard to do is to make assumptions that the origination network can find out things about the termination network. I think if you insist on that, we would have problems. If you ask information about next hop to entities you have a relationship with, then it works. You can cascade that out to the termination network, but you may have some restrictions on what can be revealed backwards. Unless you have some evidence that carriers are a lot more friendly than they seem to be now, I think the notion of simple routes is doomed. I know there are carriers who THINK they will arrange transit to all "interesting" networks and all "interesting" federations, but I don't see an environment where that will actually happen any time soon. I think we will need to have 3-8 hop routing. I don't see a problem with that. I don't even see a real problem with 10-20 as long as the media doesn't have to go that way. That IS an argument that media might not want to transit some active element in a federation. We might want to give some thoughts to how we can provide transitive trust to SBCs so that we can cut out the middleman in the media path. I'm sure each carrier will want an SBC between it and the rest of the world. Right now, I think we're headed down restrictions that media can only come from federation partners. If we stay with that, the MEDIA will go through all those hops. That would be a mistake I think. I do understand the QoS issues, but I think we can work them out for inter federation traffic. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, October 24, 2006 12:39 PM > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > Brian, > > We may not be so far apart as it might appear. I am not adverse to > options that allow a choice of technology or privacy at each step, or to > the possibility that several steps may be combined. But, we do need to > define those steps and how policy is applied and security assured along > the way. > > We can perhaps be sure that the role of domains and the information from > knowing a domain can lead to is better understood. > > I also do not want to go the BGP-like route. The IP layer addresses > that type of routing quite well. > > But, I do feel that complex, multi-SIP-hop routes is a sure sign that > the process is sub-optimal, both technically and business-wise. The > quality assurance measurement aspects probably won't keep up. And media > path optimization will probably work better with fewer call segments > involved. We'll see. > > Mike > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, October 24, 2006 7:06 AM > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar > > Lendl'; 'Richard Shockey' > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > Mike > > > > I think federations are a useful exercise for a long time. I > > want to do SPEERMINT, with federations, with private data. > > > > Although I can deal with TN to domain, and domain to ingress > > point, that is not ENUM, and it's not particularly efficient. > > I'm willing to define it two step, and then allow > > optimization if it makes people feel better. > > > > I want to focus on routing by TN because the folks who are > > all worked up about private routing data only use TNs. I'm > > not opposed to having federation solutions involving domains, > > but I'd prefer they were explicitly domains and not URIs. > > Whatever we base routing on, I really want to work with the > > basic Internet routing scheme of reachability advertisements. > > I can, and prefer, to do this in a very simplistic way now. > > I don't want to deal with BGP like issues for a long time. I > > do think we have to deal with number porting with several > > minute updates. I think we have to deal with complex, > > multihop routes, especially for international routes. I > > think we have to deal with federations who compete, and > > transit providers who compete, and carriers who compete at > > multiple levels. > > > > I want to do something new. I have no interest in > > re-inventing the PSTN. I just have to deal with carriers who > > grew up with the PSTN and think a certain way. We can move > > them a great deal, but we can't get them to give up on a few > > ideas yet, like how public the routing data is. > > > > Brian > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Monday, October 23, 2006 4:43 PM > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > > > Cc: Nieminen Klaus; speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Brian, > > > > > > You don't want to talk about federation, yet that is just an > > > expression for a type of peering. So, you want to do > > Speermint, you > > > just don't want to do peering??? > > > > > > You want to skip dealing with domains, which is the host > > part of a SIP > > > URI and remain focused on routing based on TNs. So, I > > presume we just > > > use tel:URIs? > > > > > > Today, DNS is how you end up with an IP address which is > > routing data > > > that allows you to put a data packet into the network. > > But, you don't > > > want any of that to be "public", but rather shared among a > > closed group. > > > > > > Sounds like you already have the ideal solution. It's > > called the PSTN. > > > You seem to be arguing against doing anything new. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Monday, October 23, 2006 4:10 PM > > > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar > > > > Lendl'; 'Richard Shockey' > > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > We need to distinguish between peering for voluntary > > exchange of > > > > > traffic (not currently regulated at least in the US) and > > > > Peering as a > > > > > replacement for legally required interconnection in the > > > > current PSTN. > > > > > For the former carriers (and anyone else) can and will do what > > > > > they want. The latter is likely to eventually be subject to some > > > > rules. But > > > > > consider also that where interconnection is mandated it > > comes with > > > > > rules and is not open to all parties. > > > > > You want to interconnect with the PSTN in the US you need to be > > > > > certified; otherwise you buy end user services. > > > > In the U.S., and I suspect in other countries, if anyone, > > including > > > > a less regulated (can't really say unregulated) carrier > > were to put > > > > its numbers in a public database, I am quite certain > > there would be > > > > an uproar, and I'm pretty sure the regulator would act. > > That kind > > > > of thing is just too sensitive these days. > > > > > > > > Since there were some objections even to OPT-IN > > scenarios, I think > > > > the whole area is fraught with difficulty. YMMV. > > > > > > > > > > > > > > > > > > BTW If you put all allocated (including unassigned) numbers > > > > in the DNS > > > > > then you provide no more info than can be obtained by > > war dialing > > > > > every legitimate sequence. > > > > And I repeat, I am firmly in the camp that believes security by > > > > obscurity is not real security. However, we deal with > > perceptions > > > > as well as truths and since we're looking for practical > > answers to > > > > real world problems here, I think we need solutions for > > all routing > > > > data not in public databases. > > > > > > > > If the world ran the way I, personally, wanted, we'd peer on the > > > > Internet, and we wouldn't need federations. The reality is quite > > > > different. I'd like to not waste my time in this WG working on > > > > solutions that don't get widespread adoption. > > > > Been there, done that. > > > > > > > > If you assume ANY public routing data, it's my opinion you have a > > > > solution that will not be widely implemented. If you have a > > > > solution that works with all private databases, we have a > > chance. > > > > That means the word "DNS", at least a public DNS, can't appear in > > > > the answer. I don't like that situation. I'd like to eventually > > > > change the perceptions that make that situation arise, but in the > > > > mean time, I'd like to get VoIP to VoIP traffic off the > > PSTN please. > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 14:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQx4-0003RA-7I; Tue, 24 Oct 2006 14:24:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQx2-0003Qs-Tm for speermint@ietf.org; Tue, 24 Oct 2006 14:24:36 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQwu-0006Cs-W2 for speermint@ietf.org; Tue, 24 Oct 2006 14:24:36 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id k9OIOR0B149302 for ; Tue, 24 Oct 2006 18:24:27 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9OIR9KP2896116 for ; Tue, 24 Oct 2006 20:27:09 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9OIORkA014756 for ; Tue, 24 Oct 2006 20:24:27 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9OIOReY014753; Tue, 24 Oct 2006 20:24:27 +0200 In-Reply-To: To: "Jean-Francois Mule" MIME-Version: 1.0 Subject: RE: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Tue, 24 Oct 2006 20:27:06 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 24/10/2006 20:27:08, Serialize complete at 24/10/2006 20:27:08 X-Spam-Score: 0.1 (/) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420844229==" Errors-To: speermint-bounces@ietf.org This is a multipart message in MIME format. --===============0420844229== Content-Type: multipart/alternative; boundary="=_alternative 00652227C2257211_=" This is a multipart message in MIME format. --=_alternative 00652227C2257211_= Content-Type: text/plain; charset="US-ASCII" Jean-Francois,, Sorry for the late answer was busy with another draft for SIMPLE (problem statement) I think that you are right and other then some sessions details as MSRP vs. page-mode, rate of re-subscribes that is expected etc. the requirements for VOIP should enable also presence and IM peering given that there will be enough flexibility to define different parameters for the session. For name resolution I do not see much difference between VOIP systems and presence/IM systems. RFC 3263 and RFC 3861 that you mention in another note will be used. I am seeing the presence and IM operations between domains done on the domain level and not on the client level. Doing this on the client level will require additional mechanisms to make sure that the client was authorized by the domain it claims that is coming from. There may be also a need for protocol translations that are better done in the GW level of the domain of the client and not in the client to the other domain basis. There is an emerging issue that may be quite different for presence and not relevant for VOIP. Assume that we have a domain that subscribes to many users on other domains. In the many users that the domain is subscribing to there are many duplicates and actually the other domain can subscribe to e.g. 2000 users instead of 10000 users. The issue that prevents doing this optimizations is privacy. The domain that receives that subscriptions need to know exactly which user is subscribing. On the other hand being able to do consolidates subscriptions may save a LOT in inter-domain traffic for presence. I assume that after the very heated debate that I am almost sure will happen in SIMPLE we may need a new requirement here on whether consolidates subscriptions are possible and how. --Avshalom "Jean-Francois Mule" 19/10/2006 18:32 To Avshalom Houri/Haifa/IBM@IBMIL cc Subject RE: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt Avshalom, Thank you for writing this draft. In your draft, there are a few examples that just point to different types of session descriptors in the session establishment (page mode, MSRP-based session): in those examples, can you point to specific requirements that would be new or different than for the ones for voip? There are other examples however (like 3.1.) which provide new requirements: users from different domains subscribing to each other's presence info. Could you provide more specific examples of this kind of use cases using common presence/simple/xmpp terminology and well-known URI schemes for presence? The reason I'm asking is that I'm looking at this wanting to capture beyond "VoIP" requirements and it is hard to figure out what you think is missing or should be done to allow inter-domain presence info retrieval (if anything). --- proposal (with poor wording): Based on a well-known URI (for e.g. pres:), it SHOULD be possible to determine whether the domain servicing the URI (VSP/ASP) allows session peering, and if it does, it SHOULD be possible to locate the domain's policy and signaling functions? i.e. Given that I know Bob's presence URI (e.g. pres:bob@example.com?), my client application should be able to query example.com with my own domain's credentials and figure out whether example.com allows me to see/retrieve Bob's presence, and if so, where I need to subscribe to get it? Excuse my lack of knowledge here but: - is there an equivalent of RFC3263 to locate presence servers? - are things like sip identity in play in here: what are the holes? Jean-Francois. ________________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] Sent: Tuesday, October 17, 2006 6:26 AM To: speermint@ietf.org Subject: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt FYI. Title should have been "Presence and IM use cases" --Avshalom Real Time Collaboration Standards ----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 ----- Internet-Drafts@ietf.org 17/10/2006 00:50 Please respond to internet-drafts@ietf.org To i-d-announce@ietf.org cc Subject I-D ACTION:draft-houri-speermint-usecase-presence-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTC Provisioning Requirements Author(s) : A. Houri, et al. Filename : draft-houri-speermint-usecase-presence-00.txt Pages : 12 Date : 2006-10-16 The document describes several use cases for peering between two or more communities that provide real time communications services and presence and IM in particular. The communities create a peering relationship between themselves thus enabling their users to collaborate with users on other communities. The target of the document is to help understanding the requirements for peering between domains with regard to real time services A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-houri-speermint-usecase-presence-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-houri-speermint-usecase-presence-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt_______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=_alternative 00652227C2257211_= Content-Type: text/html; charset="US-ASCII"
Jean-Francois,,

Sorry for the late answer was busy with another draft for SIMPLE (problem statement)

I think that you are right and other then some sessions details as MSRP vs. page-mode, rate
of re-subscribes that is expected etc. the requirements for VOIP should enable also presence
and IM peering given that there will be enough flexibility to define different parameters for the session.

For name resolution I do not see much difference between VOIP systems and presence/IM systems.
RFC 3263 and RFC 3861 that you mention in another note will be used.

I am seeing the presence and IM operations between domains done on the domain level and not on the client level. Doing this on the client level will require additional mechanisms to make sure that the client was authorized by the domain it claims that is coming from. There may be also a need for protocol translations that are better done in the GW level of the domain of the client and not in the client to the other domain basis.

There is an emerging issue that may be quite different for presence and not relevant for VOIP. Assume that we have a domain that subscribes to many users on other domains. In the many users that the domain is subscribing to there are many duplicates and actually the other domain can subscribe to e.g. 2000 users instead of 10000 users. The issue that prevents doing this optimizations is privacy. The domain that receives that subscriptions need to know exactly which user is subscribing. On the other hand being able to do consolidates subscriptions may save a LOT in inter-domain traffic for presence. I assume that after the very heated debate that I am almost sure will happen in SIMPLE we may need a new requirement here on whether consolidates subscriptions are possible and how.

--Avshalom


"Jean-Francois Mule" <jf.mule@cablelabs.com>

19/10/2006 18:32

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
<speermint@ietf.org>
Subject
RE: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt





Avshalom,

  Thank you for writing this draft.

  In your draft, there are a few examples that just point to different types of session descriptors in the session establishment (page mode, MSRP-based session): in those examples, can you point to specific requirements that would be new or different than for the ones for voip?

  There are other examples however (like 3.1.) which provide new requirements: users from different domains subscribing to each other's presence info.
Could you provide more specific examples of this kind of use cases using common presence/simple/xmpp terminology and well-known URI schemes for presence?
The reason I'm asking is that I'm looking at this wanting to capture beyond "VoIP" requirements and it is hard to figure out what you think is missing or should be done to allow inter-domain presence info retrieval (if anything).

--- proposal (with poor wording):
Based on a well-known URI (for e.g. pres:), it SHOULD be possible to determine whether the domain servicing the URI (VSP/ASP) allows session peering, and if it does, it SHOULD be possible to locate the domain's policy and signaling functions?
i.e.
Given that I know Bob's presence URI (e.g. pres:bob@example.com?), my client application should be able to query example.com with my own domain's credentials and figure out whether example.com allows me to see/retrieve Bob's presence, and if so, where I need to subscribe to get it?

Excuse my lack of knowledge here but:
                - is there an equivalent of RFC3263 to locate presence servers?
                - are things like sip identity in play in here: what are the holes?

Jean-Francois.
________________________________________
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Tuesday, October 17, 2006 6:26 AM
To: speermint@ietf.org
Subject: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt


FYI. Title should have been "Presence and IM use cases"

--Avshalom
Real Time Collaboration Standards

----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 -----
Internet-Drafts@ietf.org
17/10/2006 00:50
Please respond to
internet-drafts@ietf.org

To
i-d-announce@ietf.org
cc

Subject
I-D ACTION:draft-houri-speermint-usecase-presence-00.txt







A New Internet-Draft is available from the on-line Internet-Drafts
directories.


                Title                                  : RTC Provisioning Requirements
                Author(s)                 : A. Houri, et al.
                Filename                 : draft-houri-speermint-usecase-presence-00.txt
                Pages                                  : 12
                Date                                  : 2006-10-16
               
  The document describes several use cases for peering between two or
  more communities that provide real time communications services and
  presence and IM in particular.  The communities create a peering
  relationship between themselves thus enabling their users to
  collaborate with users on other communities.  The target of the
  document is to help understanding the requirements for peering
  between domains with regard to real time services


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-houri-speermint-usecase-presence-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                mailserv@ietf.org.
In the body type:
                "FILE /internet-drafts/draft-houri-speermint-usecase-presence-00.txt".
               
NOTE:                 The mail server at ietf.org can return the document in
                MIME-encoded form by using the "mpack" utility.  To use this
                feature, insert the command "ENCODING mime" before the "FILE"
                command.  To decode the response(s), you will need "munpack" or
                a MIME-compliant mail reader.  Different MIME-compliant mail readers
                exhibit different behavior, especially when dealing with
                "multipart" MIME messages (i.e. documents which have been split
                up into multiple messages), so check your local documentation on
                how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
--=_alternative 00652227C2257211_=-- --===============0420844229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0420844229==-- From speermint-bounces@ietf.org Tue Oct 24 14:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRBI-0003or-S1; Tue, 24 Oct 2006 14:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRBH-0003ok-GQ for speermint@ietf.org; Tue, 24 Oct 2006 14:39:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRBD-0000HS-OP for speermint@ietf.org; Tue, 24 Oct 2006 14:39:19 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 24 Oct 2006 11:39:14 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OIdEvA013278; Tue, 24 Oct 2006 11:39:14 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9OIcobf004627; Tue, 24 Oct 2006 11:39:09 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 14:39:09 -0400 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] Basic Peering Requirements Date: Tue, 24 Oct 2006 14:39:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C617@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAo3q+gAADi+VAAAxCrgA== From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 24 Oct 2006 18:39:09.0060 (UTC) FILETIME=[B124AC40:01C6F79B] DKIM-Signature: a=rsa-sha1; q=dns; l=11381; t=1161715154; x=1162579154; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=FRZSdRO3bRe4aph92ws52H+8pCSPvi5K34PbIw9VUNT8bFgT/IMv21NpXFeazkuyX0yO6MVP LtETVKifMseFiqyJnXMddza422XNKExBdyT1mdyfazx6gkEy7U7SKYeR; Authentication-Results: sj-dkim-7.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, October 24, 2006 12:55 PM > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar=20 > Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > I'm sure we can converge. Any public database can be made=20 > private and vice versa, if the parties agree. One of the=20 > things that IS hard to do is to make assumptions that the=20 > origination network can find out things about the termination=20 > network. I think if you insist on that, we would have problems. I understand the complexities and obstacles that some of the current regulations impose that are counter-productive to an effective solution. That doesn't mean I am willing to accept the status quo. Rules change as their makers learn what impacts they have. The information about what numbers are assigned to what provider is public information and trying to obscure that will be easily circumvented. > If you ask information about next hop to entities you have a=20 > relationship with, then it works. You can cascade that out=20 > to the termination network, but you may have some=20 > restrictions on what can be revealed backwards. Unfortunately, this way of thinking runs counter to liberalization and de-regulation. It also gives false hope to those who would seek to restrict access to public number resources versus just being the fastest easiest most efficient VSP to help one connect. =20 > Unless you have some evidence that carriers are a lot more=20 > friendly than they seem to be now, I think the notion of=20 > simple routes is doomed. I know there are carriers who THINK=20 > they will arrange transit to all "interesting" > networks and all "interesting" federations, but I don't see=20 > an environment where that will actually happen any time soon.=20 > I think we will need to have > 3-8 hop routing. I don't see a problem with that. =20 But, I do see a problem with that. The service value is at the edge serving the end users. There is very little value in the middle. I could only agree with you if the incremental billing of adding those additional transit SIP hops is substantially zero. > I don't=20 > even see a real problem with 10-20 as long as the media=20 > doesn't have to go that way. That IS an argument that media=20 > might not want to transit some active element in a > federation. We might want to give some thoughts to how we=20 > can provide > transitive trust to SBCs so that we can cut out the middleman=20 > in the media path. I'm sure each carrier will want an SBC=20 > between it and the rest of the world. Right now, I think=20 > we're headed down restrictions that media can only come from=20 > federation partners. If we stay with that, the MEDIA will go=20 > through all those hops. That would be a mistake I think. I=20 > do understand the QoS issues, but I think we can work them=20 > out for inter federation traffic. >=20 > Brian Agree with the objective, but I think you achieve that by getting The Max Two Transit VSPs to the point where they can connect directly using some optimal IP/MPLS path. Additional SIP/SBC hops at that point justs muddies the picture. Mike >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, October 24, 2006 12:39 PM > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > > Cc: Nieminen Klaus; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > > Brian, > >=20 > > We may not be so far apart as it might appear. I am not adverse to=20 > > options that allow a choice of technology or privacy at=20 > each step, or=20 > > to the possibility that several steps may be combined. But, we do=20 > > need to define those steps and how policy is applied and security=20 > > assured along the way. > >=20 > > We can perhaps be sure that the role of domains and the information=20 > > from knowing a domain can lead to is better understood. > >=20 > > I also do not want to go the BGP-like route. The IP layer=20 > addresses=20 > > that type of routing quite well. > >=20 > > But, I do feel that complex, multi-SIP-hop routes is a sure=20 > sign that=20 > > the process is sub-optimal, both technically and=20 > business-wise. The=20 > > quality assurance measurement aspects probably won't keep up. And=20 > > media path optimization will probably work better with fewer call=20 > > segments involved. We'll see. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, October 24, 2006 7:06 AM > > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar=20 > > > Lendl'; 'Richard Shockey' > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Mike > > > > > > I think federations are a useful exercise for a long=20 > time. I want=20 > > > to do SPEERMINT, with federations, with private data. > > > > > > Although I can deal with TN to domain, and domain to=20 > ingress point,=20 > > > that is not ENUM, and it's not particularly efficient. > > > I'm willing to define it two step, and then allow=20 > optimization if=20 > > > it makes people feel better. > > > > > > I want to focus on routing by TN because the folks who are all=20 > > > worked up about private routing data only use TNs. I'm=20 > not opposed=20 > > > to having federation solutions involving domains, but I'd prefer=20 > > > they were explicitly domains and not URIs. > > > Whatever we base routing on, I really want to work with the basic=20 > > > Internet routing scheme of reachability advertisements. > > > I can, and prefer, to do this in a very simplistic way now. > > > I don't want to deal with BGP like issues for a long time. I do=20 > > > think we have to deal with number porting with several minute=20 > > > updates. I think we have to deal with complex, multihop routes,=20 > > > especially for international routes. I think we have to=20 > deal with=20 > > > federations who compete, and transit providers who compete, and=20 > > > carriers who compete at multiple levels. > > > > > > I want to do something new. I have no interest in=20 > re-inventing the=20 > > > PSTN. I just have to deal with carriers who grew up with=20 > the PSTN=20 > > > and think a certain way. We can move them a great deal, but we=20 > > > can't get them to give up on a few ideas yet, like how public the=20 > > > routing data is. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > Sent: Monday, October 23, 2006 4:43 PM > > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard=20 > > > > Shockey > > > > Cc: Nieminen Klaus; speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > Brian, > > > > > > > > You don't want to talk about federation, yet that is just an=20 > > > > expression for a type of peering. So, you want to do > > > Speermint, you > > > > just don't want to do peering??? > > > > > > > > You want to skip dealing with domains, which is the host > > > part of a SIP > > > > URI and remain focused on routing based on TNs. So, I > > > presume we just > > > > use tel:URIs? > > > > > > > > Today, DNS is how you end up with an IP address which is > > > routing data > > > > that allows you to put a data packet into the network. > > > But, you don't > > > > want any of that to be "public", but rather shared among a > > > closed group. > > > > > > > > Sounds like you already have the ideal solution. It's > > > called the PSTN. > > > > You seem to be arguing against doing anything new. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Monday, October 23, 2006 4:10 PM > > > > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar=20 > > > > > Lendl'; 'Richard Shockey' > > > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > We need to distinguish between peering for voluntary > > > exchange of > > > > > > traffic (not currently regulated at least in the US) and > > > > > Peering as a > > > > > > replacement for legally required interconnection in the > > > > > current PSTN. > > > > > > For the former carriers (and anyone else) can and=20 > will do what=20 > > > > > > they want. The latter is likely to eventually be subject to=20 > > > > > > some > > > > > rules. But > > > > > > consider also that where interconnection is mandated it > > > comes with > > > > > > rules and is not open to all parties. > > > > > > You want to interconnect with the PSTN in the US=20 > you need to=20 > > > > > > be certified; otherwise you buy end user services. > > > > > In the U.S., and I suspect in other countries, if anyone, > > > including > > > > > a less regulated (can't really say unregulated) carrier > > > were to put > > > > > its numbers in a public database, I am quite certain > > > there would be > > > > > an uproar, and I'm pretty sure the regulator would act. > > > That kind > > > > > of thing is just too sensitive these days. > > > > > > > > > > Since there were some objections even to OPT-IN > > > scenarios, I think > > > > > the whole area is fraught with difficulty. YMMV. > > > > > > > > > > > > > > > > > > > > > > BTW If you put all allocated (including unassigned) numbers > > > > > in the DNS > > > > > > then you provide no more info than can be obtained by > > > war dialing > > > > > > every legitimate sequence. > > > > > And I repeat, I am firmly in the camp that believes=20 > security by=20 > > > > > obscurity is not real security. However, we deal with > > > perceptions > > > > > as well as truths and since we're looking for practical > > > answers to > > > > > real world problems here, I think we need solutions for > > > all routing > > > > > data not in public databases. > > > > > > > > > > If the world ran the way I, personally, wanted, we'd=20 > peer on the=20 > > > > > Internet, and we wouldn't need federations. The reality is=20 > > > > > quite different. I'd like to not waste my time in this WG=20 > > > > > working on solutions that don't get widespread adoption. > > > > > Been there, done that. > > > > > > > > > > If you assume ANY public routing data, it's my=20 > opinion you have=20 > > > > > a solution that will not be widely implemented. If=20 > you have a=20 > > > > > solution that works with all private databases, we have a > > > chance. > > > > > That means the word "DNS", at least a public DNS,=20 > can't appear=20 > > > > > in the answer. I don't like that situation. I'd like to=20 > > > > > eventually change the perceptions that make that situation=20 > > > > > arise, but in the mean time, I'd like to get VoIP to VoIP=20 > > > > > traffic off the > > > PSTN please. > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 14:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRRc-0003Fc-Hj; Tue, 24 Oct 2006 14:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRRa-0003Bh-U3 for speermint@ietf.org; Tue, 24 Oct 2006 14:56:10 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRRa-000353-8w for speermint@ietf.org; Tue, 24 Oct 2006 14:56:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GcRRD-0001p2-NT; Tue, 24 Oct 2006 13:55:48 -0500 From: "Brian Rosen" To: "'Michael Hammer \(mhammer\)'" , "'Pfautz, Penn L, GBLAM'" , "'Otmar Lendl'" , "'Richard Shockey'" Subject: RE: [Speermint] Basic Peering Requirements Date: Tue, 24 Oct 2006 14:55:51 -0400 Message-ID: <0c8401c6f79e$08697420$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAo3q+gAADi+VAAAxCrgAABE+mQ In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C617@xmb-rtp-20b.amer.cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: 'Nieminen Klaus' , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org You seem to have fallen into the trap of believing that you can right a regulatory wrong by defining standards that only permit "right" behavior. That never works. You can try to change behavior by education, but not by standardization. All the attempts to do that fail, and usually make poorer results; the folks left on their high horses are all alone, the rest of the world is somewhere else, perhaps not as righteous, but functioning. Penn and company think they can fix the issues. I have my doubts, and until they succeed, I think we should concentrate our efforts in working with today's reality and not tomorrow's hope. With respect to route simplicity, again I think you are in the wishing and hoping crowd rather than the ugly reality crowd. Here among the uglies, we don't assume miracles like all federations agreeing to admit any transit carrier who comes a'callin, or transit carriers that step up to 100% interconnect right off the bat, or other fanciful dreams. In this case, there isn't regulatory or customary practice problem, there are just immensely complex, and expensive buildout requirements and commercial rivalries that get in the way of nice simple solutions. In any event, a solution that had a hard limit is definitely not possible; you HAVE to assume that some routes will be long. If the usual case was 3 hops, we might engineer systems that were optimal there, and made other situations less optimal. Right now, I don't even see the common international case being that easy, although the domestic calls might often be 1-2 federations and 0-1 transit carriers. Brian > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, October 24, 2006 2:39 PM > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > Cc: Nieminen Klaus; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, October 24, 2006 12:55 PM > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar > > Lendl'; 'Richard Shockey' > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > > > > I'm sure we can converge. Any public database can be made > > private and vice versa, if the parties agree. One of the > > things that IS hard to do is to make assumptions that the > > origination network can find out things about the termination > > network. I think if you insist on that, we would have problems. > > I understand the complexities and obstacles that some of the current > regulations impose that are counter-productive to an effective solution. > That doesn't mean I am willing to accept the status quo. Rules change > as their makers learn what impacts they have. > > The information about what numbers are assigned to what provider is > public information and trying to obscure that will be easily > circumvented. > > > If you ask information about next hop to entities you have a > > relationship with, then it works. You can cascade that out > > to the termination network, but you may have some > > restrictions on what can be revealed backwards. > > Unfortunately, this way of thinking runs counter to liberalization and > de-regulation. It also gives false hope to those who would seek to > restrict access to public number resources versus just being the fastest > easiest most efficient VSP to help one connect. > > > > Unless you have some evidence that carriers are a lot more > > friendly than they seem to be now, I think the notion of > > simple routes is doomed. I know there are carriers who THINK > > they will arrange transit to all "interesting" > > networks and all "interesting" federations, but I don't see > > an environment where that will actually happen any time soon. > > I think we will need to have > > 3-8 hop routing. I don't see a problem with that. > > But, I do see a problem with that. The service value is at the edge > serving the end users. There is very little value in the middle. I > could only agree with you if the incremental billing of adding those > additional transit SIP hops is substantially zero. > > > I don't > > even see a real problem with 10-20 as long as the media > > doesn't have to go that way. That IS an argument that media > > might not want to transit some active element in a > > federation. We might want to give some thoughts to how we > > can provide > > transitive trust to SBCs so that we can cut out the middleman > > in the media path. I'm sure each carrier will want an SBC > > between it and the rest of the world. Right now, I think > > we're headed down restrictions that media can only come from > > federation partners. If we stay with that, the MEDIA will go > > through all those hops. That would be a mistake I think. I > > do understand the QoS issues, but I think we can work them > > out for inter federation traffic. > > > > Brian > > Agree with the objective, but I think you achieve that by getting The > Max Two Transit VSPs to the point where they can connect directly using > some optimal IP/MPLS path. Additional SIP/SBC hops at that point justs > muddies the picture. > > Mike > > > > > > -----Original Message----- > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > Sent: Tuesday, October 24, 2006 12:39 PM > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > > > Cc: Nieminen Klaus; speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > Brian, > > > > > > We may not be so far apart as it might appear. I am not adverse to > > > options that allow a choice of technology or privacy at > > each step, or > > > to the possibility that several steps may be combined. But, we do > > > need to define those steps and how policy is applied and security > > > assured along the way. > > > > > > We can perhaps be sure that the role of domains and the information > > > from knowing a domain can lead to is better understood. > > > > > > I also do not want to go the BGP-like route. The IP layer > > addresses > > > that type of routing quite well. > > > > > > But, I do feel that complex, multi-SIP-hop routes is a sure > > sign that > > > the process is sub-optimal, both technically and > > business-wise. The > > > quality assurance measurement aspects probably won't keep up. And > > > media path optimization will probably work better with fewer call > > > segments involved. We'll see. > > > > > > Mike > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, October 24, 2006 7:06 AM > > > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar > > > > Lendl'; 'Richard Shockey' > > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > Mike > > > > > > > > I think federations are a useful exercise for a long > > time. I want > > > > to do SPEERMINT, with federations, with private data. > > > > > > > > Although I can deal with TN to domain, and domain to > > ingress point, > > > > that is not ENUM, and it's not particularly efficient. > > > > I'm willing to define it two step, and then allow > > optimization if > > > > it makes people feel better. > > > > > > > > I want to focus on routing by TN because the folks who are all > > > > worked up about private routing data only use TNs. I'm > > not opposed > > > > to having federation solutions involving domains, but I'd prefer > > > > they were explicitly domains and not URIs. > > > > Whatever we base routing on, I really want to work with the basic > > > > Internet routing scheme of reachability advertisements. > > > > I can, and prefer, to do this in a very simplistic way now. > > > > I don't want to deal with BGP like issues for a long time. I do > > > > think we have to deal with number porting with several minute > > > > updates. I think we have to deal with complex, multihop routes, > > > > especially for international routes. I think we have to > > deal with > > > > federations who compete, and transit providers who compete, and > > > > carriers who compete at multiple levels. > > > > > > > > I want to do something new. I have no interest in > > re-inventing the > > > > PSTN. I just have to deal with carriers who grew up with > > the PSTN > > > > and think a certain way. We can move them a great deal, but we > > > > can't get them to give up on a few ideas yet, like how public the > > > > routing data is. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > Sent: Monday, October 23, 2006 4:43 PM > > > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard > > > > > Shockey > > > > > Cc: Nieminen Klaus; speermint@ietf.org > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > Brian, > > > > > > > > > > You don't want to talk about federation, yet that is just an > > > > > expression for a type of peering. So, you want to do > > > > Speermint, you > > > > > just don't want to do peering??? > > > > > > > > > > You want to skip dealing with domains, which is the host > > > > part of a SIP > > > > > URI and remain focused on routing based on TNs. So, I > > > > presume we just > > > > > use tel:URIs? > > > > > > > > > > Today, DNS is how you end up with an IP address which is > > > > routing data > > > > > that allows you to put a data packet into the network. > > > > But, you don't > > > > > want any of that to be "public", but rather shared among a > > > > closed group. > > > > > > > > > > Sounds like you already have the ideal solution. It's > > > > called the PSTN. > > > > > You seem to be arguing against doing anything new. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Monday, October 23, 2006 4:10 PM > > > > > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer); 'Otmar > > > > > > Lendl'; 'Richard Shockey' > > > > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > We need to distinguish between peering for voluntary > > > > exchange of > > > > > > > traffic (not currently regulated at least in the US) and > > > > > > Peering as a > > > > > > > replacement for legally required interconnection in the > > > > > > current PSTN. > > > > > > > For the former carriers (and anyone else) can and > > will do what > > > > > > > they want. The latter is likely to eventually be subject to > > > > > > > some > > > > > > rules. But > > > > > > > consider also that where interconnection is mandated it > > > > comes with > > > > > > > rules and is not open to all parties. > > > > > > > You want to interconnect with the PSTN in the US > > you need to > > > > > > > be certified; otherwise you buy end user services. > > > > > > In the U.S., and I suspect in other countries, if anyone, > > > > including > > > > > > a less regulated (can't really say unregulated) carrier > > > > were to put > > > > > > its numbers in a public database, I am quite certain > > > > there would be > > > > > > an uproar, and I'm pretty sure the regulator would act. > > > > That kind > > > > > > of thing is just too sensitive these days. > > > > > > > > > > > > Since there were some objections even to OPT-IN > > > > scenarios, I think > > > > > > the whole area is fraught with difficulty. YMMV. > > > > > > > > > > > > > > > > > > > > > > > > > > BTW If you put all allocated (including unassigned) numbers > > > > > > in the DNS > > > > > > > then you provide no more info than can be obtained by > > > > war dialing > > > > > > > every legitimate sequence. > > > > > > And I repeat, I am firmly in the camp that believes > > security by > > > > > > obscurity is not real security. However, we deal with > > > > perceptions > > > > > > as well as truths and since we're looking for practical > > > > answers to > > > > > > real world problems here, I think we need solutions for > > > > all routing > > > > > > data not in public databases. > > > > > > > > > > > > If the world ran the way I, personally, wanted, we'd > > peer on the > > > > > > Internet, and we wouldn't need federations. The reality is > > > > > > quite different. I'd like to not waste my time in this WG > > > > > > working on solutions that don't get widespread adoption. > > > > > > Been there, done that. > > > > > > > > > > > > If you assume ANY public routing data, it's my > > opinion you have > > > > > > a solution that will not be widely implemented. If > > you have a > > > > > > solution that works with all private databases, we have a > > > > chance. > > > > > > That means the word "DNS", at least a public DNS, > > can't appear > > > > > > in the answer. I don't like that situation. I'd like to > > > > > > eventually change the perceptions that make that situation > > > > > > arise, but in the mean time, I'd like to get VoIP to VoIP > > > > > > traffic off the > > > > PSTN please. > > > > > > > > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 15:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRlw-0001QD-IH; Tue, 24 Oct 2006 15:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRlv-0001Q4-9h for speermint@ietf.org; Tue, 24 Oct 2006 15:17:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRlt-0006QC-KL for speermint@ietf.org; Tue, 24 Oct 2006 15:17:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2006 15:17:09 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OJH93A023716; Tue, 24 Oct 2006 15:17:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9OJH9YJ017417; Tue, 24 Oct 2006 15:17:09 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 15:17:09 -0400 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] Basic Peering Requirements Date: Tue, 24 Oct 2006 15:17:05 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C655@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAo3q+gAADi+VAAAxCrgAABE+mQAACfw4A= From: "Michael Hammer \(mhammer\)" To: "Brian Rosen" , "Pfautz, Penn L, GBLAM" , "Otmar Lendl" , "Richard Shockey" X-OriginalArrivalTime: 24 Oct 2006 19:17:09.0072 (UTC) FILETIME=[0022E500:01C6F7A1] DKIM-Signature: a=rsa-sha1; q=dns; l=15924; t=1161717429; x=1162581429; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Brian=20Rosen=22=20, =0A=20=20=20=20=20=20=20=20=22 Pfautz, =20Penn=20L, =20GBLAM=22=20, =0A=20=20=20=20=20=20=20 =20=22Otmar=20Lendl=22=20, =20=22Richard=20Shockey=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=X1mFXOIl/ySalPcp/LFnvq6ntPQwvjkGh6oVpNJgqdunbpUkyqaHaB4ChqhfDdO+iPPUjYeT Wm7xXQeliynZ+RFUZ0HQLbP0eMmQfhfXN4WpKWDySzeSNQHErZ+IDc7D; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: Nieminen Klaus , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Brian, Standards are a part of education when they show how it could be done for those that have doubts about its technical feasibility. You also seem to miss the key point that terminating VSPs can choose to publicly advertize their reachability, if they so choose, just as I hand out my phone number on a business card. But, the ugliest fact of all is that voice revenues are falling, and any dilution of those revenues across extraneous carriers will bring ruin on all of them. So, it is in their best interests to devise the most efficient mechanism possible. If making a phone call were as simple as clicking on a Web site, do you think all those arbitrarily complex ways you hold dear will last long? Take heed, "google you" may some day mean a click to dial SIP session rather than just a web search. Mike =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Tuesday, October 24, 2006 2:56 PM > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar=20 > Lendl'; 'Richard Shockey' > Cc: 'Nieminen Klaus'; speermint@ietf.org > Subject: RE: [Speermint] Basic Peering Requirements >=20 > You seem to have fallen into the trap of believing that you=20 > can right a regulatory wrong by defining standards that only=20 > permit "right" behavior. >=20 > That never works. >=20 > You can try to change behavior by education, but not by=20 > standardization. > All the attempts to do that fail, and usually make poorer=20 > results; the folks left on their high horses are all alone,=20 > the rest of the world is somewhere else, perhaps not as=20 > righteous, but functioning. >=20 > Penn and company think they can fix the issues. I have my=20 > doubts, and until they succeed, I think we should concentrate=20 > our efforts in working with today's reality and not tomorrow's hope. >=20 > With respect to route simplicity, again I think you are in=20 > the wishing and hoping crowd rather than the ugly reality=20 > crowd. Here among the uglies, we don't assume miracles like=20 > all federations agreeing to admit any transit carrier who=20 > comes a'callin, or transit carriers that step up to 100%=20 > interconnect right off the bat, or other fanciful dreams. In=20 > this case, there isn't regulatory or customary practice=20 > problem, there are just immensely complex, and expensive=20 > buildout requirements and commercial rivalries that get in=20 > the way of nice simple solutions. >=20 > In any event, a solution that had a hard limit is definitely=20 > not possible; you HAVE to assume that some routes will be=20 > long. If the usual case was 3 hops, we might engineer=20 > systems that were optimal there, and made other situations=20 > less optimal. Right now, I don't even see the common=20 > international case being that easy, although the domestic=20 > calls might often be 1-2 federations and 0-1 transit carriers. >=20 > Brian >=20 >=20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, October 24, 2006 2:39 PM > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard Shockey > > Cc: Nieminen Klaus; speermint@ietf.org > > Subject: RE: [Speermint] Basic Peering Requirements > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, October 24, 2006 12:55 PM > > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar=20 > > > Lendl'; 'Richard Shockey' > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > I'm sure we can converge. Any public database can be=20 > made private=20 > > > and vice versa, if the parties agree. One of the things that IS=20 > > > hard to do is to make assumptions that the origination=20 > network can=20 > > > find out things about the termination network. I think if you=20 > > > insist on that, we would have problems. > >=20 > > I understand the complexities and obstacles that some of=20 > the current=20 > > regulations impose that are counter-productive to an=20 > effective solution. > > That doesn't mean I am willing to accept the status quo. =20 > Rules change=20 > > as their makers learn what impacts they have. > >=20 > > The information about what numbers are assigned to what provider is=20 > > public information and trying to obscure that will be easily=20 > > circumvented. > >=20 > > > If you ask information about next hop to entities you have a=20 > > > relationship with, then it works. You can cascade that=20 > out to the=20 > > > termination network, but you may have some restrictions=20 > on what can=20 > > > be revealed backwards. > >=20 > > Unfortunately, this way of thinking runs counter to=20 > liberalization and=20 > > de-regulation. It also gives false hope to those who would seek to=20 > > restrict access to public number resources versus just being the=20 > > fastest easiest most efficient VSP to help one connect. > >=20 > >=20 > > > Unless you have some evidence that carriers are a lot=20 > more friendly=20 > > > than they seem to be now, I think the notion of simple routes is=20 > > > doomed. I know there are carriers who THINK they will arrange=20 > > > transit to all "interesting" > > > networks and all "interesting" federations, but I don't see an=20 > > > environment where that will actually happen any time soon. > > > I think we will need to have > > > 3-8 hop routing. I don't see a problem with that. > >=20 > > But, I do see a problem with that. The service value is at=20 > the edge=20 > > serving the end users. There is very little value in the=20 > middle. I=20 > > could only agree with you if the incremental billing of=20 > adding those=20 > > additional transit SIP hops is substantially zero. > >=20 > > > I don't > > > even see a real problem with 10-20 as long as the media=20 > doesn't have=20 > > > to go that way. That IS an argument that media might not want to=20 > > > transit some active element in a > > > federation. We might want to give some thoughts to how we > > > can provide > > > transitive trust to SBCs so that we can cut out the=20 > middleman in the=20 > > > media path. I'm sure each carrier will want an SBC=20 > between it and=20 > > > the rest of the world. Right now, I think we're headed down=20 > > > restrictions that media can only come from federation=20 > partners. If=20 > > > we stay with that, the MEDIA will go through all those=20 > hops. That=20 > > > would be a mistake I think. I do understand the QoS=20 > issues, but I=20 > > > think we can work them out for inter federation traffic. > > > > > > Brian > >=20 > > Agree with the objective, but I think you achieve that by=20 > getting The=20 > > Max Two Transit VSPs to the point where they can connect directly=20 > > using some optimal IP/MPLS path. Additional SIP/SBC hops at that=20 > > point justs muddies the picture. > >=20 > > Mike > >=20 > > > > > > > -----Original Message----- > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > Sent: Tuesday, October 24, 2006 12:39 PM > > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar Lendl; Richard=20 > > > > Shockey > > > > Cc: Nieminen Klaus; speermint@ietf.org > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > Brian, > > > > > > > > We may not be so far apart as it might appear. I am=20 > not adverse=20 > > > > to options that allow a choice of technology or privacy at > > > each step, or > > > > to the possibility that several steps may be combined. =20 > But, we do=20 > > > > need to define those steps and how policy is applied=20 > and security=20 > > > > assured along the way. > > > > > > > > We can perhaps be sure that the role of domains and the=20 > > > > information from knowing a domain can lead to is better=20 > understood. > > > > > > > > I also do not want to go the BGP-like route. The IP layer > > > addresses > > > > that type of routing quite well. > > > > > > > > But, I do feel that complex, multi-SIP-hop routes is a sure > > > sign that > > > > the process is sub-optimal, both technically and > > > business-wise. The > > > > quality assurance measurement aspects probably won't=20 > keep up. And=20 > > > > media path optimization will probably work better with=20 > fewer call=20 > > > > segments involved. We'll see. > > > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Tuesday, October 24, 2006 7:06 AM > > > > > To: Michael Hammer (mhammer); 'Pfautz, Penn L, GBLAM'; 'Otmar=20 > > > > > Lendl'; 'Richard Shockey' > > > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > Mike > > > > > > > > > > I think federations are a useful exercise for a long > > > time. I want > > > > > to do SPEERMINT, with federations, with private data. > > > > > > > > > > Although I can deal with TN to domain, and domain to > > > ingress point, > > > > > that is not ENUM, and it's not particularly efficient. > > > > > I'm willing to define it two step, and then allow > > > optimization if > > > > > it makes people feel better. > > > > > > > > > > I want to focus on routing by TN because the folks=20 > who are all=20 > > > > > worked up about private routing data only use TNs. I'm > > > not opposed > > > > > to having federation solutions involving domains, but=20 > I'd prefer=20 > > > > > they were explicitly domains and not URIs. > > > > > Whatever we base routing on, I really want to work with the=20 > > > > > basic Internet routing scheme of reachability advertisements. > > > > > I can, and prefer, to do this in a very simplistic way now. > > > > > I don't want to deal with BGP like issues for a long=20 > time. I do=20 > > > > > think we have to deal with number porting with several minute=20 > > > > > updates. I think we have to deal with complex,=20 > multihop routes,=20 > > > > > especially for international routes. I think we have to > > > deal with > > > > > federations who compete, and transit providers who=20 > compete, and=20 > > > > > carriers who compete at multiple levels. > > > > > > > > > > I want to do something new. I have no interest in > > > re-inventing the > > > > > PSTN. I just have to deal with carriers who grew up with > > > the PSTN > > > > > and think a certain way. We can move them a great=20 > deal, but we=20 > > > > > can't get them to give up on a few ideas yet, like how public=20 > > > > > the routing data is. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > > > > > Sent: Monday, October 23, 2006 4:43 PM > > > > > > To: Brian Rosen; Pfautz, Penn L, GBLAM; Otmar=20 > Lendl; Richard=20 > > > > > > Shockey > > > > > > Cc: Nieminen Klaus; speermint@ietf.org > > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > > Brian, > > > > > > > > > > > > You don't want to talk about federation, yet that=20 > is just an=20 > > > > > > expression for a type of peering. So, you want to do > > > > > Speermint, you > > > > > > just don't want to do peering??? > > > > > > > > > > > > You want to skip dealing with domains, which is the host > > > > > part of a SIP > > > > > > URI and remain focused on routing based on TNs. So, I > > > > > presume we just > > > > > > use tel:URIs? > > > > > > > > > > > > Today, DNS is how you end up with an IP address which is > > > > > routing data > > > > > > that allows you to put a data packet into the network. > > > > > But, you don't > > > > > > want any of that to be "public", but rather shared among a > > > > > closed group. > > > > > > > > > > > > Sounds like you already have the ideal solution. It's > > > > > called the PSTN. > > > > > > You seem to be arguing against doing anything new. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Monday, October 23, 2006 4:10 PM > > > > > > > To: 'Pfautz, Penn L, GBLAM'; Michael Hammer (mhammer);=20 > > > > > > > 'Otmar Lendl'; 'Richard Shockey' > > > > > > > Cc: 'Nieminen Klaus'; speermint@ietf.org > > > > > > > Subject: RE: [Speermint] Basic Peering Requirements > > > > > > > > > > > > > > > We need to distinguish between peering for voluntary > > > > > exchange of > > > > > > > > traffic (not currently regulated at least in the US) and > > > > > > > Peering as a > > > > > > > > replacement for legally required interconnection in the > > > > > > > current PSTN. > > > > > > > > For the former carriers (and anyone else) can and > > > will do what > > > > > > > > they want. The latter is likely to eventually=20 > be subject=20 > > > > > > > > to some > > > > > > > rules. But > > > > > > > > consider also that where interconnection is mandated it > > > > > comes with > > > > > > > > rules and is not open to all parties. > > > > > > > > You want to interconnect with the PSTN in the US > > > you need to > > > > > > > > be certified; otherwise you buy end user services. > > > > > > > In the U.S., and I suspect in other countries, if anyone, > > > > > including > > > > > > > a less regulated (can't really say unregulated) carrier > > > > > were to put > > > > > > > its numbers in a public database, I am quite certain > > > > > there would be > > > > > > > an uproar, and I'm pretty sure the regulator would act. > > > > > That kind > > > > > > > of thing is just too sensitive these days. > > > > > > > > > > > > > > Since there were some objections even to OPT-IN > > > > > scenarios, I think > > > > > > > the whole area is fraught with difficulty. YMMV. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > BTW If you put all allocated (including unassigned)=20 > > > > > > > > numbers > > > > > > > in the DNS > > > > > > > > then you provide no more info than can be obtained by > > > > > war dialing > > > > > > > > every legitimate sequence. > > > > > > > And I repeat, I am firmly in the camp that believes > > > security by > > > > > > > obscurity is not real security. However, we deal with > > > > > perceptions > > > > > > > as well as truths and since we're looking for practical > > > > > answers to > > > > > > > real world problems here, I think we need solutions for > > > > > all routing > > > > > > > data not in public databases. > > > > > > > > > > > > > > If the world ran the way I, personally, wanted, we'd > > > peer on the > > > > > > > Internet, and we wouldn't need federations. The=20 > reality is=20 > > > > > > > quite different. I'd like to not waste my time=20 > in this WG=20 > > > > > > > working on solutions that don't get widespread adoption. > > > > > > > Been there, done that. > > > > > > > > > > > > > > If you assume ANY public routing data, it's my > > > opinion you have > > > > > > > a solution that will not be widely implemented. If > > > you have a > > > > > > > solution that works with all private databases, we have a > > > > > chance. > > > > > > > That means the word "DNS", at least a public DNS, > > > can't appear > > > > > > > in the answer. I don't like that situation. I'd like to=20 > > > > > > > eventually change the perceptions that make that=20 > situation=20 > > > > > > > arise, but in the mean time, I'd like to get VoIP to VoIP=20 > > > > > > > traffic off the > > > > > PSTN please. > > > > > > > > > > > > > > > >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 24 17:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUEr-0001xN-47; Tue, 24 Oct 2006 17:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUEp-0001xD-Ts for speermint@ietf.org; Tue, 24 Oct 2006 17:55:11 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUEi-00071W-63 for speermint@ietf.org; Tue, 24 Oct 2006 17:55:11 -0400 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 Date: Tue, 24 Oct 2006 17:54:49 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602364E43@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recent List Traffic Thread-Index: Acb3twcQ5azfk74bSS6+t2JMkvkORg== From: "Livingood, Jason" To: X-OriginalArrivalTime: 24 Oct 2006 21:54:50.0569 (UTC) FILETIME=[07A0C390:01C6F7B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Speermint] Recent List Traffic X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Wow - Catching up on list traffic from a few days on the road and I think I have 100+ messages in the queue. Maybe we should create a speermint-philosophy list? ;-) In all seriousness, we've got San Diego in a few weeks. Let's try to stay focused on our near-term deliverables. Thanks Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 25 03:50:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdWe-00053W-4c; Wed, 25 Oct 2006 03:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcdWd-00053R-2S for speermint@ietf.org; Wed, 25 Oct 2006 03:50:11 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcdWa-0000nJ-C0 for speermint@ietf.org; Wed, 25 Oct 2006 03:50:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Speermint] Use Case draft Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Oct 2006 09:49:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C520A@oefeg-s04.oefeg.loc> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C580@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use Case draft thread-index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfwAAd3ZEAAANKpwAADop0wAB8999A= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "David Schwartz" , "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I had understood this the same way. That the direct or indirect > referred to the SIP INVITE, not the ENUM lookups. This is what I also wanted to say. We should keep the separation in scope of ENUM and SPEERMINT up, even if real implementations may mix up this issue. BTW, excellent draft, David and Eli Richard > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, October 24, 2006 6:54 PM > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use Case draft >=20 > David, >=20 > I had understood this the same way. That the direct or indirect > referred to the SIP INVITE, not the ENUM lookups. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > Sent: Tuesday, October 24, 2006 11:37 AM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: RE: [Speermint] Use Case draft > > > > Hi Adam. > > > > Inline. > > > > > David - excellent draft and thank you for compiling! One > > thing that I > > > noticed and thought a bit odd was your definition of "Bi-Lateral or > > > direct peering". You state - "For the purposes of this > > document, VSPs > > > upload their numbers to an externally reachable location service > > denoted > > > as D-PSP." - To me, this is not direct because the location > > function > > > that you define is done outside of the > > > originating-domain/terminating-domain relationship. > > > > DS: The point I am trying to make here is as follows. When 2 > > VSPs want to share their user information with each other they can: > > > > 1. Do the equivalent of a zone transfer of all their > > users to each other so that a local copy of this information > > is available to the O-VSP. > > 2. Have the O-VSP send an INVITE to the T-VSPs registrar > > and have T-VSP either proxy the INVITE or send a 3XX back > > 3. Same as 2 only use ENUM to query a private tree > > operated at T-VSP > > 4. Store this information in a mutually accessible location > > 4a. Possibly push/pull this information to a local > > copy at both O-VSP and T-VSP > > > > Options 1 will almost never happen. Why? Because in reality > > new users are constantly being added/removed not to mention > > porting in/out of numbers and since each VSP has many > > bilateral relationships each possibly of a different nature, > > this model will not scale as well as other options. > > > > Options 2/3 will also probably not happen since again there > > are multiple relationships and O-VSP will have to send many > > INVITES to different VSPs to get an answer. Forking in this > > case is a kludge and doesn't really help. > > > > Option 4 (and 4a) is the only reasonable approach. This is > > the reason for the worldwide push for either ENUM or > > Infrastructure ENUM. To try to get all the location > > information into 1 place. Remember. The signaling and media > > are still traveling between VSPs and hence I still consider > > this Direct. Would you agree that public ENUM in this case > > fits the direct model? I think so. So just replace the public > > ENUM with a private ENUM that does nothing more than hold the > > data for all interested parties and you have the same thing. > > > > > Per the speermint terminology draft: > > > "Direct peering describes those cases in which two service > > providers > > > interconnect without using an intervening layer 5 network." > > > > DS: I interpret this as intervening in terms of signaling or > > media NOT number lookup. Am I wrong? > > > > > -AU > > > > Thanks for your comments Adam. > > > > D. > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > _______________________________________________ > 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 From speermint-bounces@ietf.org Wed Oct 25 10:38:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcjsf-0001kW-7f; Wed, 25 Oct 2006 10:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcjsd-0001e9-KQ for speermint@ietf.org; Wed, 25 Oct 2006 10:37:19 -0400 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcjsZ-0005u0-2M for speermint@ietf.org; Wed, 25 Oct 2006 10:37:19 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 7C30B1A381; Wed, 25 Oct 2006 16:37:13 +0200 (CEST) Date: Wed, 25 Oct 2006 16:37:13 +0200 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20061025143713.GP15701@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Speermint] Regarding the term "federation" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The term federation in the context of Speermint appeared (AFAIK) first in draft-lendl-sip-peering-policy-00.txt, then the definition got moved to draft-ietf-speermint-reqs-and-terminology-01.txt, then draft-ietf-speermint-terminology-06 plus draft-lendl-speermint-federations-03. >From the current terminology draft: A federation is a group of VSPs which agree to receive calls from each other via SIP, and who agree on a set of administrative rules for such calls (settlement, abuse-handling, ...) and the specific rules for the technical details of the interconnection. My basic premise for this definition was the idea that federations should play the same role in SIP routing as subnets play in L3 routing: If the higher level routing algorithm notices that his host and the destination share a common subnet, then use his interface into that subnet to directly route to the destination. That routing step only works if all members of a federation can talk to each other. Some other drafts have picked up the "federation" terminology. I'm not sure they agree on the definition, though. Thus this mail. To recap what I think a "federation" should be: * Full mesh between members. No "we both members of $WHATEVER, but we don't peer with each other there". Corrolary: there is no need for the federation to maintain detailed information on what routing information should be disclosed to which member. * A federation is a mathematical set of VSPs. There can, but need not be some organization (with associated services) behind a federation. >From what I read between the lines of other drafts, a federation there needs to be operated by someone who provides various business and technical services, including a DB which stores who has agreed to peer with whom. Now, I'm not saying that this is a bad idea. In fact, for some scenarios this is the likely outcome. I'm just worried about keeping the terminology consistent. What about calling such managed federations "peering fabrics"? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 25 11:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckLv-0007AT-S8; Wed, 25 Oct 2006 11:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckLt-0007AL-Ba for speermint@ietf.org; Wed, 25 Oct 2006 11:07:33 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GckLn-0004gn-Qy for speermint@ietf.org; Wed, 25 Oct 2006 11:07:33 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Wed, 25 Oct 2006 08:07:01 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9PF6vIY024359; Wed, 25 Oct 2006 08:07:03 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9PF5fPb025273; Wed, 25 Oct 2006 08:06:17 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 08:06:10 -0700 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] Basic Peering Requirements Date: Wed, 25 Oct 2006 08:06:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141251@namail5.corp.adobe.com> In-Reply-To: <055D8EBC-A448-4E7A-8320-D264FD4CFDDF@rfc1035.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb24yj5Cbq0LTTtT3GmCcs4YCsehABXY3qg From: "Henry Sinnreich" To: "Jim Reid" , "Reinaldo Penno" X-OriginalArrivalTime: 25 Oct 2006 15:06:10.0172 (UTC) FILETIME=[1ABEDBC0:01C6F847] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Nieminen Klaus , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jim Reid wrote: > Telcos tend to consider this kind of thing to be sensitive data. This is correct and there is more to it. Scenario: Telco1 prepares a holiday promotion with free calls on Mother's Day (or for frequent flyers) but will not let its competitors know this ahead of time. The sudden free calls may need to be routed differently and also settled differently. Such a web of critical business arrangements between networks will IMHO make peering just as difficult as implementing interdomain QoS, which has not happened for similar reasons: _Competing networks don't share critical policies_. The need to interdomain QoS was mitigated by the advent of broadband. Best effort prevails. The need for peering will be mitigated by the advent of free VoIP, IM and video. VoIP prevails as an application with no other usage charge besides the cost of broadband. Thanks, Henry -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Monday, October 23, 2006 3:38 PM To: Reinaldo Penno Cc: Otmar Lendl; Nieminen Klaus; speermint@ietf.org Subject: Re: [Speermint] Basic Peering Requirements On Oct 23, 2006, at 21:10, Reinaldo Penno wrote: > I must be missing something here. True. :-) > Telephone numbers are already public in the US (they have to be). =20 > To be de-listed you have to pay extra but law enforcement in the US =20 > are still notified of such unlisted phones. I can get a paper =20 > telephone directory and lookup any telephone number. I can go to =20 > Verizon's or ATT's (in the US) home page and perform a reverse =20 > lookup and find the telephone number associated with a name (and =20 > vice-versa). Although phone numbers are sort of public, other things related to =20 telephony service are not. [Or at least not easily determined by the =20 general public.] These include stuff like which company provides =20 service for a given number, which number(s) in a company's =20 "allocation block" have been ported or are not in use, where the =20 telco's interconnect points are, what type of hardware they use, etc, =20 etc. With SIP peering, the analogues of these things could become =20 visible to everyone: eg the name and addresses of the company's SIP =20 servers that act as their internet/PSTN gateways. Telcos tend to =20 consider this kind of thing to be sensitive data. _______________________________________________ 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 From speermint-bounces@ietf.org Wed Oct 25 11:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckPv-0002oM-Pg; Wed, 25 Oct 2006 11:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckPu-0002oH-Vk for speermint@ietf.org; Wed, 25 Oct 2006 11:11:42 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckPq-0005gc-J0 for speermint@ietf.org; Wed, 25 Oct 2006 11:11:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GckPj-0002F5-Mg; Wed, 25 Oct 2006 10:11:31 -0500 From: "Brian Rosen" To: "'Otmar Lendl'" , Subject: RE: [Speermint] Regarding the term "federation" Date: Wed, 25 Oct 2006 11:11:33 -0400 Message-ID: <0ee901c6f847$dd6ea420$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb4QzrS4yJiabt9SSKSf8Ce1cb0HgAAiR8A In-Reply-To: <20061025143713.GP15701@nic.at> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org By our definition, a federation has rules. The rules state when two members can exchange traffic. While I do think the most common rule is everyone can talk to everyone else, I don't think we can or should have a blanket prohibition on one peer refusing traffic from another peer within the rules. Consider, for example, non payment of compensation, if there is any, or receipt of what the termination network considered SPIT. Federations have rules, so there has to be SOMETHING that defines the rules. In that sense, there is some kind of organization, but it might be pretty weak. I do think it is currently the case that federations run databases. I don't think there is a flat requirement that they do, but most of the practical solutions I see involve them. It's possible to build databases that are distributed enough that each peer can keep his part of it by himself. Sometimes such databases have a common portion (root) that SOMEONE runs, but again, that could be pretty simple. So, I'm not afraid of having federations running databases. I guess I think we probably ought to separate the functional parts, allowing someone to run the federation, and someone else to run the database. If we, for example, agreed that a common registry made sense, but a single federation did not, then we would separate at least one database from actual federation ownership. Brian > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Wednesday, October 25, 2006 10:37 AM > To: speermint@ietf.org > Subject: [Speermint] Regarding the term "federation" > > > The term federation in the context of Speermint appeared (AFAIK) > first in draft-lendl-sip-peering-policy-00.txt, then the definition > got moved to draft-ietf-speermint-reqs-and-terminology-01.txt, > then draft-ietf-speermint-terminology-06 plus draft-lendl-speermint- > federations-03. > > >From the current terminology draft: > > A federation is a group of VSPs which agree to receive calls from > each other via SIP, and who agree on a set of administrative rules > for such calls (settlement, abuse-handling, ...) and the specific > rules for the technical details of the interconnection. > > My basic premise for this definition was the idea that federations > should play the same role in SIP routing as subnets play in L3 routing: > If the higher level routing algorithm notices that his host and > the destination share a common subnet, then use his interface into > that subnet to directly route to the destination. > > That routing step only works if all members of a federation can talk > to each other. > > Some other drafts have picked up the "federation" terminology. > I'm not sure they agree on the definition, though. Thus this mail. > > To recap what I think a "federation" should be: > > * Full mesh between members. > > No "we both members of $WHATEVER, but we don't peer with each other > there". > > Corrolary: there is no need for the federation to maintain detailed > information on what routing information should be disclosed to which > member. > > * A federation is a mathematical set of VSPs. There can, but need not > be some organization (with associated services) behind a federation. > > >From what I read between the lines of other drafts, a federation there > needs to be operated by someone who provides various business and > technical > services, including a DB which stores who has agreed to peer with whom. > > Now, I'm not saying that this is a bad idea. In fact, for some scenarios > this is the likely outcome. > > I'm just worried about keeping the terminology consistent. > > What about calling such managed federations "peering fabrics"? > > /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 From speermint-bounces@ietf.org Wed Oct 25 13:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcmzE-0004uj-JE; Wed, 25 Oct 2006 13:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcmz4-0004ns-45 for speermint@ietf.org; Wed, 25 Oct 2006 13:56:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcmmr-0001Q9-6U for speermint@ietf.org; Wed, 25 Oct 2006 13:43:35 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2006 13:43:33 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PHhWMp007888; Wed, 25 Oct 2006 13:43:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9PHhVDa006270; Wed, 25 Oct 2006 13:43:32 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 13:43:27 -0400 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] Regarding the term "federation" Date: Wed, 25 Oct 2006 13:43:23 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C9AD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Regarding the term "federation" Thread-Index: Acb4Q0wDVjhKLh2vSnCuYVlLdn3XVAAGS9fA From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , X-OriginalArrivalTime: 25 Oct 2006 17:43:27.0788 (UTC) FILETIME=[1400C6C0:01C6F85D] DKIM-Signature: a=rsa-sha1; q=dns; l=3038; t=1161798212; x=1162662212; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Regarding=20the=20term=20=22federation=22 |To:=22Otmar=20Lendl=22=20,=20; X=v=3Dcisco.com=3B=20h=3DnnCzyVZVU5/+hV2q7mBChtkoOTk=3D; b=FPaUh2EFXcILeGlMC/LFctaMt04pTdUNNfMtUHsplFUs1rzV1aLCw62EedRqXq5qXmRpT/pc byiSq8MtkdTHDBJ15NCt3l/v92p9aFsyIPNsB5oe4jtGIdZey7gjQi20; Authentication-Results: rtp-dkim-2.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, I don't know that the distinction is sufficiently different to need another term. This would seem to be arguing about whether some peers are more or less equal than others. I would prefer not to get too far into the business aspects of this. Just leave room for multiple models to operate. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Wednesday, October 25, 2006 10:37 AM > To: speermint@ietf.org > Subject: [Speermint] Regarding the term "federation" >=20 >=20 > The term federation in the context of Speermint appeared=20 > (AFAIK) first in draft-lendl-sip-peering-policy-00.txt, then=20 > the definition got moved to=20 > draft-ietf-speermint-reqs-and-terminology-01.txt, > then draft-ietf-speermint-terminology-06 plus=20 > draft-lendl-speermint-federations-03. >=20 > >From the current terminology draft: >=20 > A federation is a group of VSPs which agree to receive calls from > each other via SIP, and who agree on a set of administrative rules > for such calls (settlement, abuse-handling, ...) and the specific > rules for the technical details of the interconnection. >=20 > My basic premise for this definition was the idea that=20 > federations should play the same role in SIP routing as=20 > subnets play in L3 routing: > If the higher level routing algorithm notices that his host=20 > and the destination share a common subnet, then use his=20 > interface into that subnet to directly route to the destination. >=20 > That routing step only works if all members of a federation=20 > can talk to each other. >=20 > Some other drafts have picked up the "federation" terminology.=20 > I'm not sure they agree on the definition, though. Thus this mail. >=20 > To recap what I think a "federation" should be: >=20 > * Full mesh between members. >=20 > No "we both members of $WHATEVER, but we don't peer with=20 > each other there". >=20 > Corrolary: there is no need for the federation to maintain detailed > information on what routing information should be disclosed to which > member. >=20 > * A federation is a mathematical set of VSPs. There can, but need not > be some organization (with associated services) behind a federation. >=20 > >From what I read between the lines of other drafts, a=20 > federation there > needs to be operated by someone who provides various business=20 > and technical services, including a DB which stores who has=20 > agreed to peer with whom. >=20 > Now, I'm not saying that this is a bad idea. In fact, for=20 > some scenarios this is the likely outcome.=20 >=20 > I'm just worried about keeping the terminology consistent.=20 >=20 > What about calling such managed federations "peering fabrics"? >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 25 14:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcnIS-00019I-39; Wed, 25 Oct 2006 14:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcnIQ-00012H-0B for speermint@ietf.org; Wed, 25 Oct 2006 14:16:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcnIO-00074x-KT for speermint@ietf.org; Wed, 25 Oct 2006 14:16:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Oct 2006 11:16:08 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PIG8tB030043; Wed, 25 Oct 2006 14:16:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9PIG6YP024574; Wed, 25 Oct 2006 14:16:07 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 14:16:05 -0400 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] Basic Peering Requirements Date: Wed, 25 Oct 2006 14:16:00 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30218C9DD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb24yj5Cbq0LTTtT3GmCcs4YCsehABXY3qgAAduAZA= From: "Michael Hammer \(mhammer\)" To: "Henry Sinnreich" , "Jim Reid" , "Reinaldo Penno" X-OriginalArrivalTime: 25 Oct 2006 18:16:05.0615 (UTC) FILETIME=[A2F577F0:01C6F861] DKIM-Signature: a=rsa-sha1; q=dns; l=4394; t=1161800168; x=1162664168; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:RE=3A=20[Speermint]=20Basic=20Peering=20Requirements |To:=22Henry=20Sinnreich=22=20, =20=22Jim=20Reid=22=20, =0A=20=20=20=20=20=20=20=20=22Reinaldo=20Penno=22=20; X=v=3Dcisco.com=3B=20h=3DZpQZhukDJgF9rIBN+ao93OopwkE=3D; b=fZYNDVBTYjgCh2+OxfzkNnruMQGNjAk7vo6PZ0iRx3ve5TH4D5lY1/eNizEaTE6pfKjt0J6N i99CWj07s6c8Z3m4r7dGHyz90FJsUK+mujAtdwMFYcv3CB07JqwcL+S7; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Nieminen Klaus , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Henry, How would the route differ, and are you suggesting that your competitors will settle differently if you surprise them with more traffic? Also, didn't grok the "mitigate the need for peering". I assume you still need to handoff traffic to other VSPs, or are you just referring to pure P2P and no VSPs? The sensitivity revolves around security and identity in that they don't want to give out information to just anybody. For a monthy fee and access to a participants data, the role of the middlemen in many cases is to sell the addressing information collected from the group back to those very same members in small chunks. They may also compensate for the inability of the VSPs to agree on standard means of interconnection, as well as referee settlements. But, it makes you wonder, if standard interconnection arrangements were agreed on, and the security mechanisms were in place, could a limited amount of public bootstrapping information enable more fluid direct peering? I think there are word games played with regard to the labels "public" or "private". The data is not kept within the carrier, it is shared to others, you just need be authenticated and to pay for it. Mike > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Wednesday, October 25, 2006 11:06 AM > To: Jim Reid; Reinaldo Penno > Cc: Nieminen Klaus; speermint@ietf.org; Otmar Lendl > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Jim Reid wrote: >=20 > > Telcos tend to consider this kind of thing to be sensitive data. >=20 > This is correct and there is more to it. >=20 > Scenario: Telco1 prepares a holiday promotion with free calls=20 > on Mother's Day (or for frequent flyers) but will not let its=20 > competitors know this ahead of time. >=20 > The sudden free calls may need to be routed differently and=20 > also settled differently. >=20 > Such a web of critical business arrangements between networks=20 > will IMHO make peering just as difficult as implementing=20 > interdomain QoS, which has not happened for similar reasons:=20 > _Competing networks don't share critical policies_. >=20 > The need to interdomain QoS was mitigated by the advent of broadband. > Best effort prevails. >=20 > The need for peering will be mitigated by the advent of free=20 > VoIP, IM and video. VoIP prevails as an application with no=20 > other usage charge besides the cost of broadband. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Monday, October 23, 2006 3:38 PM > To: Reinaldo Penno > Cc: Otmar Lendl; Nieminen Klaus; speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On Oct 23, 2006, at 21:10, Reinaldo Penno wrote: >=20 > > I must be missing something here. >=20 > True. :-) >=20 > > Telephone numbers are already public in the US (they have to be). =20 > > To be de-listed you have to pay extra but law enforcement in the US=20 > > are still notified of such unlisted phones. I can get a paper=20 > > telephone directory and lookup any telephone number. I can go to=20 > > Verizon's or ATT's (in the US) home page and perform a=20 > reverse lookup=20 > > and find the telephone number associated with a name (and=20 > vice-versa). >=20 > Although phone numbers are sort of public, other things=20 > related to telephony service are not. [Or at least not easily=20 > determined by the general public.] These include stuff like=20 > which company provides service for a given number, which=20 > number(s) in a company's "allocation block" have been ported=20 > or are not in use, where the telco's interconnect points are,=20 > what type of hardware they use, etc, etc. With SIP peering,=20 > the analogues of these things could become visible to=20 > everyone: eg the name and addresses of the company's SIP=20 > servers that act as their internet/PSTN gateways. Telcos tend=20 > to consider this kind of thing to be sensitive data. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 25 15:55:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcopt-0002FV-JE; Wed, 25 Oct 2006 15:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcolK-0003qW-ML; Wed, 25 Oct 2006 15:50:06 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcolJ-0007q4-3U; Wed, 25 Oct 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1349326E48; Wed, 25 Oct 2006 19:50:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolI-0004tR-Rm; Wed, 25 Oct 2006 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Oct 2006 15:50:04 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-requirements-01.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Requirements for SIP-based VoIP Interconnection Author(s) : J. Mule Filename : draft-ietf-speermint-requirements-01.txt Pages : 22 Date : 2006-10-25 This document describes high-level guidelines and general requirements for Session PEERing for Multimedia INTerconnect. It also defines a minimum set of requirements applicable to session peering for Voice over IP interconnects. It is intended to become best current practices based on the use cases discussed in the speermint working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25142824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25142824.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Wed Oct 25 18:18:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcr4T-0004G0-3F; Wed, 25 Oct 2006 18:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcr4S-0004Fj-Ao for speermint@ietf.org; Wed, 25 Oct 2006 18:18:00 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcr4L-0001iV-9D for speermint@ietf.org; Wed, 25 Oct 2006 18:18:00 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9PMHqWL008248 for ; Wed, 25 Oct 2006 16:17:52 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Speermint] Changes in draft-ietf-speermint-requirements-01.txt Date: Wed, 25 Oct 2006 16:17:51 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Changes in draft-ietf-speermint-requirements-01.txt Thread-Index: Acb0zGDQS+ukDJGlTHOETWq2UyMNxgB0oZggAAEWkhA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I've submitted an update to the requirement I-D based on the wg input and feedback. It is now available at: http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-01 .txt The main changes in draft 01 are: - clarifed the intent and scope of the ID in the introduction by capturing the main discussion points from the IETF 66 and interim meetings on what this ID should be about, what it should not cover, what the target of the requirements should be, the "must implement" vs. "must use" debate; - aligned the terminology with draft-speermint-terminology (CRD-> CAD, SBE, ...) and with Hannes' proposal to re-use ASP/VSP for non voice service providers based on the ecrit requirement work; - done various editorial work on requirements per Hannes' comments (e.g., separated the actual requirements from motivations/justifications); - added the requirement on the variability of CAD per mailing list thread based on Daryl, Otmar, Penn and other inputs - added what I think is our current (rough, incomplete and unsatisfying) definition of session peering policy; - integrated ideas & inputs from Tom Creighton, Daryl Malas, Otmar Lendl and others on the parameters that could be included in a policy description: I put this in a new informative annex for now as I am not sure how much of these are seeds for requirement that we would want to keep long term in the document to drive protocol solutions; - updated codec requirements to reflect wg consensus (I think); - integrated the input we got from various participants at the interim on the fact that some VSPs rely on network-layer and lower layer security mechanisms for VoIP exchanges; added pointers to rtpsec bof for media related security requirements and new IDs on media security requirements; - replaced the basic TLS requirement with more detailed ones per the wg recommendations at the interim; some initial text was sent to the list for comments and is inspired from Rohan's direct peering draft and Vijay's draft on sip certs (see email sent last week, this needs work for sure). Comments welcome. Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Oct 25 19:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcrn0-0000Oh-4u; Wed, 25 Oct 2006 19:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcrmy-0000Nq-LV for speermint@ietf.org; Wed, 25 Oct 2006 19:04:00 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcrmx-0008F6-1U for speermint@ietf.org; Wed, 25 Oct 2006 19:04:00 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 9E3173A7D; Wed, 25 Oct 2006 19:03:58 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 19:03:58 -0400 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] Use Case draft Date: Wed, 25 Oct 2006 19:03:57 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C580@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use Case draft Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfwAAd3ZEAAANKpwAADop0wAD8naeA= From: "Uzelac, Adam" To: "Michael Hammer (mhammer)" , "David Schwartz" , X-OriginalArrivalTime: 25 Oct 2006 23:03:58.0281 (UTC) FILETIME=[DA452390:01C6F889] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I am with you guys on this one I believe. Just so I understand....So if it's an ENUM look-up for a trusted 3rd party to satisfy a location request, but the SIP Invite/Media are direct between VSP-o and VSP-t, then it's direct. BUT if, for some reason or another (I am not advocating, just asking the question) it's a SIP INV/3XX exchange to the trusted 3rd party to satisfy a location request, it's indirect? -AU -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, October 24, 2006 12:54 PM To: David Schwartz; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Use Case draft David, I had understood this the same way. That the direct or indirect referred to the SIP INVITE, not the ENUM lookups. Mike =20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > Sent: Tuesday, October 24, 2006 11:37 AM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use Case draft >=20 > Hi Adam. >=20 > Inline. >=20 > > David - excellent draft and thank you for compiling! One > thing that I > > noticed and thought a bit odd was your definition of "Bi-Lateral or=20 > > direct peering". You state - "For the purposes of this > document, VSPs > > upload their numbers to an externally reachable location service > denoted > > as D-PSP." - To me, this is not direct because the location > function > > that you define is done outside of the=20 > > originating-domain/terminating-domain relationship. >=20 > DS: The point I am trying to make here is as follows. When 2 VSPs want > to share their user information with each other they can: >=20 > 1. Do the equivalent of a zone transfer of all their users to each > other so that a local copy of this information is available to the=20 > O-VSP. > 2. Have the O-VSP send an INVITE to the T-VSPs registrar and have=20 > T-VSP either proxy the INVITE or send a 3XX back > 3. Same as 2 only use ENUM to query a private tree operated at=20 > T-VSP > 4. Store this information in a mutually accessible location > 4a. Possibly push/pull this information to a local copy at=20 > both O-VSP and T-VSP >=20 > Options 1 will almost never happen. Why? Because in reality new users=20 > are constantly being added/removed not to mention porting in/out of=20 > numbers and since each VSP has many bilateral relationships each=20 > possibly of a different nature, this model will not scale as well as=20 > other options. >=20 > Options 2/3 will also probably not happen since again there are=20 > multiple relationships and O-VSP will have to send many INVITES to=20 > different VSPs to get an answer. Forking in this case is a kludge and=20 > doesn't really help. >=20 > Option 4 (and 4a) is the only reasonable approach. This is the reason=20 > for the worldwide push for either ENUM or Infrastructure ENUM. To try=20 > to get all the location information into 1 place. Remember. The=20 > signaling and media are still traveling between VSPs and hence I still > consider this Direct. Would you agree that public ENUM in this case=20 > fits the direct model? I think so. So just replace the public ENUM=20 > with a private ENUM that does nothing more than hold the data for all=20 > interested parties and you have the same thing. >=20 > > Per the speermint terminology draft: > > "Direct peering describes those cases in which two service > providers > > interconnect without using an intervening layer 5 network." >=20 > DS: I interpret this as intervening in terms of signaling or media NOT > number lookup. Am I wrong? >=20 > > -AU >=20 > Thanks for your comments Adam. >=20 > D. >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 26 05:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1HS-0001f8-Do; Thu, 26 Oct 2006 05:12:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1HP-0001ST-VQ for speermint@ietf.org; Thu, 26 Oct 2006 05:12:03 -0400 Received: from bzq-25-94-44.cust.bezeqint.net ([212.25.94.44] helo=isr-jlm-mail.Kayote.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1HO-0002gX-GX for speermint@ietf.org; Thu, 26 Oct 2006 05:12:03 -0400 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] Use Case draft Date: Thu, 26 Oct 2006 11:11:50 +0200 Message-ID: <1DDB0D3CC4E7F14FAE946361C0A606550168C27D@isr-jlm-mail.Kayote.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Use Case draft Thread-Index: Acb2uZgDLFRnQ8POTCSxrgFN+5rr+gAASgyQAAQcHyAAAesWUAACictwAAFVSbAAAJUH4AAeFMfwAAd3ZEAAANKpwAADop0wAD8naeAAFT3Y4A== From: "David Schwartz" To: "Uzelac, Adam" , "Michael Hammer \(mhammer\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org That's an interesting question. I view the location process itself as not interfering with the direct/indirect status regardless of the underlying protocol used for the query. Based on this even if you use 3XX to external location but do not signal that entity in terms of actual call routing it should still be direct. I think it's a lot cleaner. D. -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Thursday, October 26, 2006 1:04 AM To: Michael Hammer (mhammer); David Schwartz; speermint@ietf.org Subject: RE: [Speermint] Use Case draft I am with you guys on this one I believe. Just so I understand....So if it's an ENUM look-up for a trusted 3rd party to satisfy a location request, but the SIP Invite/Media are direct between VSP-o and VSP-t, then it's direct. BUT if, for some reason or another (I am not advocating, just asking the question) it's a SIP INV/3XX exchange to the trusted 3rd party to satisfy a location request, it's indirect? -AU -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Tuesday, October 24, 2006 12:54 PM To: David Schwartz; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Use Case draft David, I had understood this the same way. That the direct or indirect referred to the SIP INVITE, not the ENUM lookups. Mike =20 > -----Original Message----- > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > Sent: Tuesday, October 24, 2006 11:37 AM > To: Uzelac, Adam; speermint@ietf.org > Subject: RE: [Speermint] Use Case draft >=20 > Hi Adam. >=20 > Inline. >=20 > > David - excellent draft and thank you for compiling! One > thing that I > > noticed and thought a bit odd was your definition of "Bi-Lateral or=20 > > direct peering". You state - "For the purposes of this > document, VSPs > > upload their numbers to an externally reachable location service > denoted > > as D-PSP." - To me, this is not direct because the location > function > > that you define is done outside of the=20 > > originating-domain/terminating-domain relationship. >=20 > DS: The point I am trying to make here is as follows. When 2 VSPs want > to share their user information with each other they can: >=20 > 1. Do the equivalent of a zone transfer of all their users to each > other so that a local copy of this information is available to the=20 > O-VSP. > 2. Have the O-VSP send an INVITE to the T-VSPs registrar and have=20 > T-VSP either proxy the INVITE or send a 3XX back > 3. Same as 2 only use ENUM to query a private tree operated at=20 > T-VSP > 4. Store this information in a mutually accessible location > 4a. Possibly push/pull this information to a local copy at=20 > both O-VSP and T-VSP >=20 > Options 1 will almost never happen. Why? Because in reality new users=20 > are constantly being added/removed not to mention porting in/out of=20 > numbers and since each VSP has many bilateral relationships each=20 > possibly of a different nature, this model will not scale as well as=20 > other options. >=20 > Options 2/3 will also probably not happen since again there are=20 > multiple relationships and O-VSP will have to send many INVITES to=20 > different VSPs to get an answer. Forking in this case is a kludge and=20 > doesn't really help. >=20 > Option 4 (and 4a) is the only reasonable approach. This is the reason=20 > for the worldwide push for either ENUM or Infrastructure ENUM. To try=20 > to get all the location information into 1 place. Remember. The=20 > signaling and media are still traveling between VSPs and hence I still > consider this Direct. Would you agree that public ENUM in this case=20 > fits the direct model? I think so. So just replace the public ENUM=20 > with a private ENUM that does nothing more than hold the data for all=20 > interested parties and you have the same thing. >=20 > > Per the speermint terminology draft: > > "Direct peering describes those cases in which two service > providers > > interconnect without using an intervening layer 5 network." >=20 > DS: I interpret this as intervening in terms of signaling or media NOT > number lookup. Am I wrong? >=20 > > -AU >=20 > Thanks for your comments Adam. >=20 > D. >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 26 10:43:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6RF-0001Xf-7t; Thu, 26 Oct 2006 10:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6RE-0001XY-PE for speermint@ietf.org; Thu, 26 Oct 2006 10:42:32 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6R6-0006bN-HN for speermint@ietf.org; Thu, 26 Oct 2006 10:42:32 -0400 Received: from ([10.20.62.12]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.25874169; Thu, 26 Oct 2006 10:42:07 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCRLY02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 10:40:42 -0400 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] I-D ACTION:draft-ietf-speermint-srv-naptr-use-00.txt Date: Thu, 26 Oct 2006 10:40:41 -0400 Message-ID: <45AEC6EF95942140888406588E1A660236524C@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-00.txt Thread-Index: AcbxaI5Ma/HRhzNTTXOXTC3SqWR25wHo8Qhw From: "Livingood, Jason" To: "Otmar Lendl" , X-OriginalArrivalTime: 26 Oct 2006 14:40:42.0053 (UTC) FILETIME=[B6542750:01C6F90C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > I may be missing something, but is there anything in this=20 > draft which isn't just a summary of RFCs 3263 and 2782? >=20 > The abstract says: >=20 > The objective of this document is to specify the Best Current=20 > Practice (BCP) adopted by a Voice Over IP (VoIP) service=20 > provider in=20 > order to locate another VoIP service provider to peer with in the=20 > context of Session PEERing for Multimedia INTerconnect. =20 >=20 > Given the discussions on-list and at the meetings: This does=20 > not describe what the current practice is. It just describes=20 > the theory in the current RFCs. The current practice is=20 > either manually nailed down peerings or a fabric which=20 > resolves numbers to ingress points. If you have specific feedback on what you think is the current practice, please send it to the document authors. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 26 11:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6zz-0004KQ-Qv; Thu, 26 Oct 2006 11:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6zy-0004I8-Au for speermint@ietf.org; Thu, 26 Oct 2006 11:18:26 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6xP-00057b-KS for speermint@ietf.org; Thu, 26 Oct 2006 11:15:53 -0400 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.25876506; Thu, 26 Oct 2006 11:15:20 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 11:15:20 -0400 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] Basic Peering Requirements Date: Thu, 26 Oct 2006 11:15:19 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602365272@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2rEovRqAQQJQ3SeeZRfywEBwkUACY7Qgw From: "Livingood, Jason" To: "Klaus Darilion" , "Nieminen Klaus" X-OriginalArrivalTime: 26 Oct 2006 15:15:20.0605 (UTC) FILETIME=[8D3E04D0:01C6F911] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > regarding public routing info: > There are several arguments why carriers will never put there=20 > TNs in public ENUM trees, e.g.: > - "Carriers are afraid that others can query how many=20 > numbers(customers) they have." Most carriers are traded on public stock exchanges where regulatory rules dictate the disclosure of subscriber counts. I am not sure this is a big deal in reality. > - "Carriers are afraid that other carriers can find out the=20 > current carrier-of-record of an enterprise and to poach this customer" Probably a valid fear on some level. But you could just as easily figure out who hosted an enterprises' website or email domain and try to poach that service. If someone wants to find this information out, they can. I'd suggest, therefore, that this fear, if it exists pervasively inside of enterprise service providers, is irrational (like many fears perhaps).=20 > IMO this arguments are not valid, because this information=20 > can be retrieved easily also in the current TDM world - at=20 > least in Austria. And in other places as well, especially those with number portability. =20 > maybe others can tell us why carriers never will put there=20 > numbers into public infrastructure ENUM? I think perhaps there are two concerns I have heard (not that I agree with them) - 1 - Security through obscurity of the interconnection points on public and private IP networks. But these gateways must be secure no matter whether the address is published in a public database or not - someone will find it and probe it eventually and it must be secured with this assumption in mind. 2 - Security of the TNs / user portion of the SIP URIs. In email, many SPs try to hide the list of users (perhaps similar to list of TNs) to prevent spam. So perhaps they want to extend that and hide the user portion of the URI, which is the TN, to prevent SPIT. The only problem is that you need such a TN in order to discover the SIP URI and discover the domain portion - so this position kind of falls apart... Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 26 11:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd70o-00052F-E7; Thu, 26 Oct 2006 11:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd70n-00051h-Jg for speermint@ietf.org; Thu, 26 Oct 2006 11:19:17 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd70k-0006YW-Ay for speermint@ietf.org; Thu, 26 Oct 2006 11:19:17 -0400 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] Basic Peering Requirements Date: Thu, 26 Oct 2006 11:18:57 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602365277@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb2s2l2LIn9eFdVT3aiLYMdZue0iACXlkRQ From: "Livingood, Jason" To: "Otmar Lendl" , "Brian Rosen" X-OriginalArrivalTime: 26 Oct 2006 15:18:58.0588 (UTC) FILETIME=[0F2B95C0:01C6F912] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Stastny Richard , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > > This is the problem we have with you guys. Somehow you think that=20 > > it's acceptable for there to be some private data and some public=20 > > data. I don't think it works that way. The organizations=20 > who won't=20 > > peer on the Internet want ALL of their data private, not=20 > just some of it. >=20 > Oh yes, they're not used to that from their PSTN business. On=20 > the other hand, they don't seem to have a problem regarding=20 > such information at the IP layer. E.g. from the RIPE db: Yes, an interesting paradox, isn't it? I think this stems from the fact that inside of service providers you in fact have two different cultures. One is the PSTN one and the other is the IP group. They both approach this question in their areas in basically opposite ways. We get the fun task of bringing them together I think! ;-) Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Oct 26 11:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7Kr-0003tW-Os; Thu, 26 Oct 2006 11:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7Kq-0003rs-8o for speermint@ietf.org; Thu, 26 Oct 2006 11:40:00 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd7Kl-000319-QU for speermint@ietf.org; Thu, 26 Oct 2006 11:40:00 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id k9QFddtE018140; Thu, 26 Oct 2006 08:39:39 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id k9QFddjJ018139; Thu, 26 Oct 2006 08:39:39 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 26 Oct 2006 08:39:39 -0700 From: David Meyer To: "Livingood, Jason" Subject: Re: [Speermint] Basic Peering Requirements Message-ID: <20061026153939.GA18074@1-4-5.net> References: <45AEC6EF95942140888406588E1A6602365277@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 In-Reply-To: <45AEC6EF95942140888406588E1A6602365277@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0860824427==" Errors-To: speermint-bounces@ietf.org --===============0860824427== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 26, 2006 at 11:18:57AM -0400, Livingood, Jason wrote: > > > This is the problem we have with you guys. Somehow you think that=20 > > > it's acceptable for there to be some private data and some public=20 > > > data. I don't think it works that way. The organizations=20 > > who won't=20 > > > peer on the Internet want ALL of their data private, not=20 > > just some of it. > >=20 > > Oh yes, they're not used to that from their PSTN business. On=20 > > the other hand, they don't seem to have a problem regarding=20 > > such information at the IP layer. E.g. from the RIPE db: >=20 > Yes, an interesting paradox, isn't it? I think this stems from the fact > that inside of service providers you in fact have two different > cultures. One is the PSTN one and the other is the IP group. They both > approach this question in their areas in basically opposite ways. We > get the fun task of bringing them together I think! ;-) Well, its not exactly true. People have big problems using the IRRs for generating policy (notwithstanding folks like NTT/Verio, who do). Most frequently people put up their own IRR (e.g., MCI) because not only are the public IRRs populated with junk (for many reasons, including that data gets stale, malicious use, etc), and its not verifiable in any strong sense... --dmm --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFQNa7ORgD1qCZ2KcRAtTiAJ4k9P5ZLjxfcKBe6ofpsixiKK/6CACdGZHk u50bIkitCVUbRMpOOko5xGE= =nknf -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- --===============0860824427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0860824427==-- From speermint-bounces@ietf.org Thu Oct 26 18:24:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDaS-0001gD-G1; Thu, 26 Oct 2006 18:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDaO-0001bz-5w for speermint@ietf.org; Thu, 26 Oct 2006 18:20:28 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdDXo-0001cZ-8q for speermint@ietf.org; Thu, 26 Oct 2006 18:17:50 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 26 Oct 2006 15:17:35 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9QMEvvV001532; Thu, 26 Oct 2006 15:15:00 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k9QMHAeC003314; Thu, 26 Oct 2006 15:17:16 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 15:17:10 -0700 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] Basic Peering Requirements Date: Thu, 26 Oct 2006 15:17:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141264@namail5.corp.adobe.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E30218C9DD@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Basic Peering Requirements Thread-Index: Acb24yj5Cbq0LTTtT3GmCcs4YCsehABXY3qgAAduAZAAOowDgA== From: "Henry Sinnreich" To: "Michael Hammer \(mhammer\)" , "Jim Reid" , "Reinaldo Penno" X-OriginalArrivalTime: 26 Oct 2006 22:17:10.0602 (UTC) FILETIME=[7B2D12A0:01C6F94C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Nieminen Klaus , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Mike, Thanks for the good questions. I believe most of the answers are in the new I-D < draft-ietf-speermint-requirements-01.txt>. > For a monthy fee and access to a participants data, the role of the=20 > middlemen in many cases is to sell the addressing information collected=20 > from the group back to those very same members in small chunks. I agree, this makes sense for direct enterprise interconnect without going through a carrier. Actually there are some companies doing it. =20 > They may also compensate for the inability of the VSPs to agree on=20 > standard means of interconnection, as well as referee settlements. This is 100% accurate IMHO. Henry -----Original Message----- From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 Sent: Wednesday, October 25, 2006 1:16 PM To: Henry Sinnreich; Jim Reid; Reinaldo Penno Cc: Nieminen Klaus; speermint@ietf.org; Otmar Lendl Subject: RE: [Speermint] Basic Peering Requirements Henry, How would the route differ, and are you suggesting that your competitors will settle differently if you surprise them with more traffic? Also, didn't grok the "mitigate the need for peering". I assume you still need to handoff traffic to other VSPs, or are you just referring to pure P2P and no VSPs? The sensitivity revolves around security and identity in that they don't want to give out information to just anybody. For a monthy fee and access to a participants data, the role of the middlemen in many cases is to sell the addressing information collected from the group back to those very same members in small chunks. They may also compensate for the inability of the VSPs to agree on standard means of interconnection, as well as referee settlements. But, it makes you wonder, if standard interconnection arrangements were agreed on, and the security mechanisms were in place, could a limited amount of public bootstrapping information enable more fluid direct peering? I think there are word games played with regard to the labels "public" or "private". The data is not kept within the carrier, it is shared to others, you just need be authenticated and to pay for it. Mike > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Wednesday, October 25, 2006 11:06 AM > To: Jim Reid; Reinaldo Penno > Cc: Nieminen Klaus; speermint@ietf.org; Otmar Lendl > Subject: RE: [Speermint] Basic Peering Requirements >=20 > Jim Reid wrote: >=20 > > Telcos tend to consider this kind of thing to be sensitive data. >=20 > This is correct and there is more to it. >=20 > Scenario: Telco1 prepares a holiday promotion with free calls=20 > on Mother's Day (or for frequent flyers) but will not let its=20 > competitors know this ahead of time. >=20 > The sudden free calls may need to be routed differently and=20 > also settled differently. >=20 > Such a web of critical business arrangements between networks=20 > will IMHO make peering just as difficult as implementing=20 > interdomain QoS, which has not happened for similar reasons:=20 > _Competing networks don't share critical policies_. >=20 > The need to interdomain QoS was mitigated by the advent of broadband. > Best effort prevails. >=20 > The need for peering will be mitigated by the advent of free=20 > VoIP, IM and video. VoIP prevails as an application with no=20 > other usage charge besides the cost of broadband. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Monday, October 23, 2006 3:38 PM > To: Reinaldo Penno > Cc: Otmar Lendl; Nieminen Klaus; speermint@ietf.org > Subject: Re: [Speermint] Basic Peering Requirements >=20 > On Oct 23, 2006, at 21:10, Reinaldo Penno wrote: >=20 > > I must be missing something here. >=20 > True. :-) >=20 > > Telephone numbers are already public in the US (they have to be). =20 > > To be de-listed you have to pay extra but law enforcement in the US=20 > > are still notified of such unlisted phones. I can get a paper=20 > > telephone directory and lookup any telephone number. I can go to=20 > > Verizon's or ATT's (in the US) home page and perform a=20 > reverse lookup=20 > > and find the telephone number associated with a name (and=20 > vice-versa). >=20 > Although phone numbers are sort of public, other things=20 > related to telephony service are not. [Or at least not easily=20 > determined by the general public.] These include stuff like=20 > which company provides service for a given number, which=20 > number(s) in a company's "allocation block" have been ported=20 > or are not in use, where the telco's interconnect points are,=20 > what type of hardware they use, etc, etc. With SIP peering,=20 > the analogues of these things could become visible to=20 > everyone: eg the name and addresses of the company's SIP=20 > servers that act as their internet/PSTN gateways. Telcos tend=20 > to consider this kind of thing to be sensitive data. >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 27 04:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdNPE-0007Oe-TZ; Fri, 27 Oct 2006 04:49:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdNPD-0007NF-2P; Fri, 27 Oct 2006 04:49:35 -0400 Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdNPB-00045u-EH; Fri, 27 Oct 2006 04:49:35 -0400 Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3]) (AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 27 Oct 2006 10:49:25 +0200 id 0007C0C1.4541C815.00004C09 Message-ID: <4541C78C.7060102@enum.at> Date: Fri, 27 Oct 2006 10:47:08 +0200 From: Alexander Mayrhofer Organization: enum.at GmbH User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'enum@ietf.org'" , speermint Content-Type: multipart/mixed; boundary="------------090300090303010705030003" X-Spam-Score: 0.2 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Subject: [Speermint] [Fwd: Update to Internet-Draft and RFC Boilerplate] X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --------------090300090303010705030003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit administrivia: there is a new boilerplate to be used for Internet Drafts. Draft authors might want to check their versions of xml2rfc and idnits. Alex --------------090300090303010705030003 Content-Type: message/rfc822; name="Update to Internet-Draft and RFC Boilerplate" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Update to Internet-Draft and RFC Boilerplate" Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [::ffff:156.154.16.145]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by pahula with esmtp; Fri, 27 Oct 2006 03:27:02 +0200 id 0007C393.45416067.00001331 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdGOd-0002A4-Ez; Thu, 26 Oct 2006 21:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdGOc-00029y-KL for ietf-announce@ietf.org; Thu, 26 Oct 2006 21:20:30 -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 1GdGOc-0002Ag-I1 for ietf-announce@ietf.org; Thu, 26 Oct 2006 21:20:30 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdGOc-0000MD-7H for ietf-announce@ietf.org; Thu, 26 Oct 2006 21:20:30 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id E68FF175E1 for ; Fri, 27 Oct 2006 01:19:59 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GdGO7-0007vB-Go for ietf-announce@ietf.org; Thu, 26 Oct 2006 21:19:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit To: IETF Announcement list Cc: From: IETF Chair Message-Id: Date: Thu, 26 Oct 2006 21:19:59 -0400 X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: Update to Internet-Draft and RFC Boilerplate X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on pahula X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, UPPERCASE_25_50 autolearn=no version=3.0.3 A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team -------- Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that is to be maintained by the IANA, the following abbreviated notice shall be included: OLD "Copyright (C) The Internet Society . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." NEW "Copyright (C) The IETF Trust . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --------------090300090303010705030003 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --------------090300090303010705030003-- From speermint-bounces@ietf.org Fri Oct 27 12:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdULn-00054P-Gb; Fri, 27 Oct 2006 12:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH9-0008W9-AD for speermint@ietf.org; Fri, 27 Oct 2006 12:09:43 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdU9k-00039g-FR for speermint@ietf.org; Fri, 27 Oct 2006 12:02:08 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9RG23Ah008959; Fri, 27 Oct 2006 10:02:03 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] TLS related requirements for speermint ID Date: Fri, 27 Oct 2006 10:02:02 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] TLS related requirements for speermint ID Thread-Index: AcbyAldCYxDkox8FRLipDq2U4cJoIQBj8J5wAABZqQAAAnidsAGPxmSQ From: "Jean-Francois Mule" To: "Reinaldo Penno" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi, Reinaldo wrote: > For TLS specifically, isn't it better just to say peers should follow > RFC4346 (or 2246) it they want implement TLS? Is there a need to say > that peers need to agree on a port?! This is a built-in requirement > for > DNS/ENUM, SIP, and any layer 4 protocol out there. Do not take it the > wrong way but it seems stating the obvious. >=20 > As for the more security related things, TLS already have built-in > capabilities for cipher negotiation and mutual-challenge. If something > fails they will get an error saying "negoiation failed", "cipher suite > invalid", or something like it. Specifying the minimum set of cipher > suites is a slippery slope (remember the minimum codec thread...). >=20 > It _seems_ to me we are compensating the general lack of TLS > understanding by trying to summarize the most basic TLS requirements. > IMHO we should only mention those things that somebody after reading > the > RFCs and/or going through a basic server-server configuration process > cannot figure out. >=20 > A "list of trusted root CAs" is something less obvious and specific to > peering. I'm sure there are others. Suggestions welcome. On your point about not listing the obvious things, I would tend to disagree. The intent was to get into a little bit more details and starting with the obvious does help get quick agreement to focus on the harder things. First, we all tend to take some shortcuts when implementing things (side note, check this: http://www.ietf.org/internet-drafts/draft-ietf-tls-interoperability-00.t xt ). Second, having a list of parameters that should be statically or dynamically negotiated (and hence dynamically configurable on sip routing server engines on a per route basis) could help many folks.=20 As an enterprise sysadmin trying to configure TLS parameters for an outbound SIP proxy aimed at terminating sip sessions to 2 different peers, the first things you ask yourself are those basic questions for each peer. And the answers are "it depends to the host you want to connect to". Jean-Francois. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Oct 27 13:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdV3q-0005MQ-5W; Fri, 27 Oct 2006 13:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdV3p-0005Lp-1Z for speermint@ietf.org; Fri, 27 Oct 2006 13:00:01 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdV3k-0005A5-DG for speermint@ietf.org; Fri, 27 Oct 2006 13:00:01 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k9RGwvcx008590; Fri, 27 Oct 2006 16:58:58 GMT Subject: RE: [Speermint] Use Case draft From: Daryl Malas To: "Michael Hammer (mhammer)" In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3021F1E32@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3021F1E32@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain Date: Fri, 27 Oct 2006 11:01:45 -0600 Message-Id: <1161968505.16895.168.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: speermint@ietf.org, "Uzelac, Adam" , David Schwartz X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In my mind, I agree with David. I separate the LF look up from direct/indirect status. The LF lookup can comprise of ENUM or 3XX. Even though SIP is used for the 3XX, this is still the "LF" phase. In order for an indirect peering method to take place, the subsequent INVITE after the 3XX is actually sent to a SF of a 3rd party provider to be proxied to the (indirect) peer. --Daryl On Thu, 2006-10-26 at 15:17 -0400, Michael Hammer (mhammer) wrote: > In the example Adam gives, the SIP method is just another mechanism to > query and get the real address to which a *new* INVITE is sent directly. > In other words the subsequent INVITE is a new dialog and the route set > does not include the previously queried one. > > So, I would see that as direct. > > Mike > > > > -----Original Message----- > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > Sent: Thursday, October 26, 2006 5:12 AM > > To: Uzelac, Adam; Michael Hammer (mhammer); speermint@ietf.org > > Subject: RE: [Speermint] Use Case draft > > > > That's an interesting question. > > > > I view the location process itself as not interfering with > > the direct/indirect status regardless of the underlying > > protocol used for the query. Based on this even if you use > > 3XX to external location but do not signal that entity in > > terms of actual call routing it should still be direct. > > > > I think it's a lot cleaner. > > > > D. > > > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Thursday, October 26, 2006 1:04 AM > > To: Michael Hammer (mhammer); David Schwartz; speermint@ietf.org > > Subject: RE: [Speermint] Use Case draft > > > > I am with you guys on this one I believe. Just so I > > understand....So if it's an ENUM look-up for a trusted 3rd > > party to satisfy a location request, but the SIP Invite/Media > > are direct between VSP-o and VSP-t, then it's direct. BUT > > if, for some reason or another (I am not advocating, just > > asking the question) it's a SIP INV/3XX exchange to the > > trusted 3rd party to satisfy a location request, it's indirect? > > > > -AU > > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Tuesday, October 24, 2006 12:54 PM > > To: David Schwartz; Uzelac, Adam; speermint@ietf.org > > Subject: RE: [Speermint] Use Case draft > > > > David, > > > > I had understood this the same way. That the direct or > > indirect referred to the SIP INVITE, not the ENUM lookups. > > > > Mike > > > > > > > -----Original Message----- > > > From: David Schwartz [mailto:David.Schwartz@Kayote.com] > > > Sent: Tuesday, October 24, 2006 11:37 AM > > > To: Uzelac, Adam; speermint@ietf.org > > > Subject: RE: [Speermint] Use Case draft > > > > > > Hi Adam. > > > > > > Inline. > > > > > > > David - excellent draft and thank you for compiling! One > > > thing that I > > > > noticed and thought a bit odd was your definition of > > "Bi-Lateral or > > > > direct peering". You state - "For the purposes of this > > > document, VSPs > > > > upload their numbers to an externally reachable location service > > > denoted > > > > as D-PSP." - To me, this is not direct because the location > > > function > > > > that you define is done outside of the > > > > originating-domain/terminating-domain relationship. > > > > > > DS: The point I am trying to make here is as follows. When > > 2 VSPs want > > > > > to share their user information with each other they can: > > > > > > 1. Do the equivalent of a zone transfer of all their > > users to each > > > > > other so that a local copy of this information is available to the > > > O-VSP. > > > 2. Have the O-VSP send an INVITE to the T-VSPs > > registrar and have > > > T-VSP either proxy the INVITE or send a 3XX back > > > 3. Same as 2 only use ENUM to query a private tree operated at > > > T-VSP > > > 4. Store this information in a mutually accessible location > > > 4a. Possibly push/pull this information to a local copy at > > > both O-VSP and T-VSP > > > > > > Options 1 will almost never happen. Why? Because in reality > > new users > > > are constantly being added/removed not to mention porting in/out of > > > numbers and since each VSP has many bilateral relationships each > > > possibly of a different nature, this model will not scale > > as well as > > > other options. > > > > > > Options 2/3 will also probably not happen since again there are > > > multiple relationships and O-VSP will have to send many INVITES to > > > different VSPs to get an answer. Forking in this case is a > > kludge and > > > doesn't really help. > > > > > > Option 4 (and 4a) is the only reasonable approach. This is > > the reason > > > for the worldwide push for either ENUM or Infrastructure > > ENUM. To try > > > to get all the location information into 1 place. Remember. The > > > signaling and media are still traveling between VSPs and > > hence I still > > > > > consider this Direct. Would you agree that public ENUM in this case > > > fits the direct model? I think so. So just replace the public ENUM > > > with a private ENUM that does nothing more than hold the > > data for all > > > interested parties and you have the same thing. > > > > > > > Per the speermint terminology draft: > > > > "Direct peering describes those cases in which two service > > > providers > > > > interconnect without using an intervening layer 5 network." > > > > > > DS: I interpret this as intervening in terms of signaling > > or media NOT > > > > > number lookup. Am I wrong? > > > > > > > -AU > > > > > > Thanks for your comments Adam. > > > > > > D. > > > > > > _______________________________________________ > > > 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 From speermint-bounces@ietf.org Mon Oct 30 11:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZwE-0006zz-Sm; Mon, 30 Oct 2006 11:24:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZwD-0006zJ-Vl for speermint@ietf.org; Mon, 30 Oct 2006 11:24:38 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZw0-0002Lv-9R for speermint@ietf.org; Mon, 30 Oct 2006 11:24:37 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 654471A36C; Mon, 30 Oct 2006 17:24:12 +0100 (CET) Date: Mon, 30 Oct 2006 17:24:12 +0100 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20061030162412.GY19113@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Speermint] Agenda for San Diego? X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Our slot seems to be wednesday, 0900-1130. Do we have an agenda yet? Based on the recent discussion on the list I propose we spend some time on the basics of what speermint is supposed to achive: The setting, the requirements and what kind of problem we want to solve (and what not). /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Oct 30 13:26:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebpo-00044S-Rn; Mon, 30 Oct 2006 13:26:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebpn-00043B-7h for speermint@ietf.org; Mon, 30 Oct 2006 13:26:07 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gebpd-0006XW-BY for speermint@ietf.org; Mon, 30 Oct 2006 13:26:07 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id k9UIPqZ0027796; Mon, 30 Oct 2006 10:25:52 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id k9UIPqB5027795; Mon, 30 Oct 2006 10:25:52 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 30 Oct 2006 10:25:52 -0800 From: David Meyer To: Otmar Lendl , speermint@ietf.org Subject: Re: [Speermint] Agenda for San Diego? Message-ID: <20061030182552.GA27755@1-4-5.net> References: <20061030162412.GY19113@nic.at> Mime-Version: 1.0 In-Reply-To: <20061030162412.GY19113@nic.at> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1914979013==" Errors-To: speermint-bounces@ietf.org --===============1914979013== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 30, 2006 at 05:24:12PM +0100, Otmar Lendl wrote: >=20 > Our slot seems to be wednesday, 0900-1130. >=20 > Do we have an agenda yet? We're working on it. There's a lot of material to cover, and we're trying to optimize for the time we have. Please bear with us a few more hours. > Based on the recent discussion on the list I propose we > spend some time on the basics of what speermint is supposed > to achive: The setting, the requirements and what kind > of problem we want to solve (and what not). Thanks for the suggestion. I'll talk it over with Jason. --dmm --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFRkOwORgD1qCZ2KcRAqhYAJsFSnBfy5axOrGMwRa58PWEq3Gz/wCePeDz WlFtEzqgx/TiY8amfl6FWJU= =sP+x -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- --===============1914979013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1914979013==-- From speermint-bounces@ietf.org Tue Oct 31 08:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetYJ-00006r-C2; Tue, 31 Oct 2006 08:21:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetYF-00006a-VQ for speermint@ietf.org; Tue, 31 Oct 2006 08:21:14 -0500 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GetY7-0003mN-K2 for speermint@ietf.org; Tue, 31 Oct 2006 08:21:11 -0500 Received: from ([10.20.9.172]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH3.26022186; Tue, 31 Oct 2006 08:20:48 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 08:20:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6FCEF.60F81CDF" Date: Tue, 31 Oct 2006 08:20:47 -0500 Message-ID: <45AEC6EF95942140888406588E1A660245313F@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [wg-business] Draft Agenda - IETF 67 - San Diego Thread-Index: Acb872CF5pZSifCbRfCsNVDdINDQgg== From: "Livingood, Jason" To: X-OriginalArrivalTime: 31 Oct 2006 13:20:48.0040 (UTC) FILETIME=[60F09280:01C6FCEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Speermint] [wg-business] Draft Agenda - IETF 67 - San Diego X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FCEF.60F81CDF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Pls advise if you have any feedback. As per discussion at the interim, we're focusing a lot of time and energy in use case reviews. =20 Thanks Jason & Dave Session PEERing for Multimedia INTerconnect (speermint) Wednesday, November 8, 2006, 0900 - 1130 (Morning Session I)=20 Room Name: Grande A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer o Welcome & Introduction to speermint / Administrivia 5 minutes Dave Meyer - Mailing list: speermint-request@ietf.org subscribe - Scribe (jabber) =20 - Blue Sheets - Review of Milestones - Note Changes to I-D Boilerplate, Effective December 2006 o Agenda Bashing 5 minutes Jason Livingood USE CASE DRAFT REVIEWS (1hr 15mins) 1 - An ITSP Problem Statement Regarding SIP Peering 15 minutes draft-newton-speermint-itsp-problem-statement-00=20 Andy Newton=09 2 - Best Current Practices for Session Peering on the Internet 15 minutes by Carriers through Federations draft-rosen-speermint-peeringbcp-v1-00 Brian Rosen 3 - SIP Peering Use Case for VSPs 15 minutes draft-uzelac-speermint-use-cases-00 Adam Uzelac=20 4 - Session Peering Use Cases for Federations 15 minutes draft-schwartz-speermint-use-cases-federations-00 David Schwartz 5 - IM Use Cases 15 minutes draft-houri-speermint-usecase-presence-00 Avshalom Houri OTHER DRAFT REVIEWS (25mins) 6 - SPEERMINT Requirements for SIP-based VoIP Interconnection 10 minutes draft-ietf-speermint-requirements-01 Jean-Francois Mule 7 - SPEERMINT Peering Architecture 10 minutes SPEERMINT Routing Architecture Message Flows=20 draft-ietf-speermint-architecture-02 draft-ietf-speermint-flows-01 Reinadlo Penno 8 - VoIP Security Threats 5 minutes draft-niccolini-speermint-voipthreats-00.txt Saverio Niccolini o Open Discussion 10 minutes =20 ------_=_NextPart_001_01C6FCEF.60F81CDF Content-Type: text/plain; name="speermint_agenda_ietf67.txt" Content-Transfer-Encoding: base64 Content-Description: speermint_agenda_ietf67.txt Content-Disposition: attachment; filename="speermint_agenda_ietf67.txt" U2Vzc2lvbiBQRUVSaW5nIGZvciBNdWx0aW1lZGlhIElOVGVyY29ubmVjdCAoc3BlZXJtaW50KQ0K DQpXZWRuZXNkYXksIE5vdmVtYmVyIDgsIDIwMDYsIDA5MDAgLSAxMTMwIChNb3JuaW5nIFNlc3Np b24gSSkgDQpSb29tIE5hbWU6IEdyYW5kZSBBDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpDSEFJUlM6CSAgICBE YXZpZCBNZXllciAgICAgIAk8ZG1tQDEtNC01Lm5ldD4NCgkgICAgSmFzb24gTGl2aW5nb29kICAJ PGphc29uX2xpdmluZ29vZEBjYWJsZS5jb21jYXN0LmNvbT4NCg0KU0VDUkVUQVJZOiAgQWxleGFu ZGVyIE1heXJob2ZlciA8YWxleGFuZGVyLm1heXJob2ZlckBuaWMuYXQ+DQoNCiBvIFdlbGNvbWUg JiBJbnRyb2R1Y3Rpb24gdG8gc3BlZXJtaW50IC8gQWRtaW5pc3RyaXZpYQkgIAkJNSBtaW51dGVz DQogICAgIERhdmUgTWV5ZXINCg0KICAgLSBNYWlsaW5nIGxpc3Q6IHNwZWVybWludC1yZXF1ZXN0 QGlldGYub3JnDQogICAgIHN1YnNjcmliZQ0KDQogICAtIFNjcmliZSAoamFiYmVyKQ0KICAgDQog ICAtIEJsdWUgU2hlZXRzDQoNCiAgIC0gUmV2aWV3IG9mIE1pbGVzdG9uZXMNCg0KICAgLSBOb3Rl IENoYW5nZXMgdG8gSS1EIEJvaWxlcnBsYXRlLCBFZmZlY3RpdmUgRGVjZW1iZXIgMjAwNg0KDQog byBBZ2VuZGEgQmFzaGluZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CQk1IG1pbnV0ZXMNCiAgICAgSmFzb24gTGl2aW5nb29kDQoNClVTRSBDQVNFIERSQUZUIFJFVklF V1MgKDFociAxNW1pbnMpDQoNCjEgLSBBbiBJVFNQIFByb2JsZW0gU3RhdGVtZW50IFJlZ2FyZGlu ZyBTSVAgUGVlcmluZwkJCTE1IG1pbnV0ZXMNCglkcmFmdC1uZXd0b24tc3BlZXJtaW50LWl0c3At cHJvYmxlbS1zdGF0ZW1lbnQtMDAgDQoJQW5keSBOZXd0b24JDQoNCjIgLSBCZXN0IEN1cnJlbnQg UHJhY3RpY2VzIGZvciBTZXNzaW9uIFBlZXJpbmcgb24gdGhlIEludGVybmV0IAkJMTUgbWludXRl cw0KCWJ5IENhcnJpZXJzIHRocm91Z2ggRmVkZXJhdGlvbnMNCglkcmFmdC1yb3Nlbi1zcGVlcm1p bnQtcGVlcmluZ2JjcC12MS0wMA0KCUJyaWFuIFJvc2VuDQoNCjMgLSBTSVAgUGVlcmluZyBVc2Ug Q2FzZSBmb3IgVlNQcyAJCQkJCTE1IG1pbnV0ZXMNCglkcmFmdC11emVsYWMtc3BlZXJtaW50LXVz ZS1jYXNlcy0wMA0KCUFkYW0gVXplbGFjIA0KDQo0IC0gU2Vzc2lvbiBQZWVyaW5nIFVzZSBDYXNl cyBmb3IgRmVkZXJhdGlvbnMJCQkJMTUgbWludXRlcw0KCWRyYWZ0LXNjaHdhcnR6LXNwZWVybWlu dC11c2UtY2FzZXMtZmVkZXJhdGlvbnMtMDANCglEYXZpZCBTY2h3YXJ0eg0KDQo1IC0gSU0gVXNl IENhc2VzCQkJCQkJCTE1IG1pbnV0ZXMNCglkcmFmdC1ob3VyaS1zcGVlcm1pbnQtdXNlY2FzZS1w cmVzZW5jZS0wMA0KCUF2c2hhbG9tIEhvdXJpDQoNCk9USEVSIERSQUZUIFJFVklFV1MgKDI1bWlu cykNCg0KNiAtIFNQRUVSTUlOVCBSZXF1aXJlbWVudHMgZm9yIFNJUC1iYXNlZCBWb0lQIEludGVy Y29ubmVjdGlvbgkJMTAgbWludXRlcw0KCWRyYWZ0LWlldGYtc3BlZXJtaW50LXJlcXVpcmVtZW50 cy0wMQ0KCUplYW4tRnJhbmNvaXMgTXVsZQ0KDQo3IC0gU1BFRVJNSU5UIFBlZXJpbmcgQXJjaGl0 ZWN0dXJlCQkJCQkxMCBtaW51dGVzDQogICAgU1BFRVJNSU5UIFJvdXRpbmcgQXJjaGl0ZWN0dXJl IE1lc3NhZ2UgRmxvd3MgDQoJZHJhZnQtaWV0Zi1zcGVlcm1pbnQtYXJjaGl0ZWN0dXJlLTAyDQoJ ZHJhZnQtaWV0Zi1zcGVlcm1pbnQtZmxvd3MtMDENCglSZWluYWRsbyBQZW5ubw0KDQo4IC0gVm9J UCBTZWN1cml0eSBUaHJlYXRzCQkJCQkJNSBtaW51dGVzDQoJZHJhZnQtbmljY29saW5pLXNwZWVy bWludC12b2lwdGhyZWF0cy0wMC50eHQNCglTYXZlcmlvIE5pY2NvbGluaQ0KDQoNCiBvIE9wZW4g RGlzY3Vzc2lvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAkJMTAgbWlu dXRlcw0KICAgDQoNCg== ------_=_NextPart_001_01C6FCEF.60F81CDF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ------_=_NextPart_001_01C6FCEF.60F81CDF-- From speermint-bounces@ietf.org Tue Oct 31 10:26:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevVb-0001aQ-PI; Tue, 31 Oct 2006 10:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevVZ-0001aI-Mb for speermint@ietf.org; Tue, 31 Oct 2006 10:26:34 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GevVV-0007Sg-8p for speermint@ietf.org; Tue, 31 Oct 2006 10:26:33 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 31 Oct 2006 07:26:27 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9VFQhIY009610; Tue, 31 Oct 2006 07:26:44 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k9VFPNeK027266; Tue, 31 Oct 2006 07:26:24 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 07:26:15 -0800 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] [wg-business] Draft Agenda - IETF 67 - San Diego Date: Tue, 31 Oct 2006 07:25:53 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141296@namail5.corp.adobe.com> In-Reply-To: <45AEC6EF95942140888406588E1A660245313F@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] [wg-business] Draft Agenda - IETF 67 - San Diego Thread-Index: Acb872CF5pZSifCbRfCsNVDdINDQggAD1XjA From: "Henry Sinnreich" To: "Livingood, Jason" , X-OriginalArrivalTime: 31 Oct 2006 15:26:15.0761 (UTC) FILETIME=[E7CFA410:01C6FD00] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I would suggest to start with #1 presence and IM peering, since this topic has been neglected so far and may change most documents published so far since they are voice centric, or even worse, PSTN-emulation-centric. #1. IM Use Cases 15 minutes draft-houri-speermint-usecase-presence-00 Avshalom Houri Most "IM services" also provide voice now and arguably may carry even the majority of VoIP traffic. When trying to use some IM gateway, server or UA based, one is hit by the fact that though there are protocol mappings (SIMPLE-XMPP for example), the different policies and features make interchanging presence and IM a non-trivial exercise. It appears that peering for presence and IM is far more complex than peering for voice only (where folks have fallen into the trap of emulating PSTN interconnect). In the light of the above, I dare to suggest the agenda item #2:=20 Is it time to re-charter the WG so as to include presence and IM? Please keep this for the Agenda Bashing, not for bashing yours humble :-) Thanks, Henry -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Tuesday, October 31, 2006 7:21 AM To: speermint@ietf.org Subject: [Speermint] [wg-business] Draft Agenda - IETF 67 - San Diego Pls advise if you have any feedback. As per discussion at the interim, we're focusing a lot of time and energy in use case reviews. =20 Thanks Jason & Dave Session PEERing for Multimedia INTerconnect (speermint) Wednesday, November 8, 2006, 0900 - 1130 (Morning Session I)=20 Room Name: Grande A =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: David Meyer Jason Livingood SECRETARY: Alexander Mayrhofer o Welcome & Introduction to speermint / Administrivia 5 minutes Dave Meyer - Mailing list: speermint-request@ietf.org subscribe - Scribe (jabber) =20 - Blue Sheets - Review of Milestones - Note Changes to I-D Boilerplate, Effective December 2006 o Agenda Bashing 5 minutes Jason Livingood USE CASE DRAFT REVIEWS (1hr 15mins) 1 - An ITSP Problem Statement Regarding SIP Peering 15 minutes draft-newton-speermint-itsp-problem-statement-00=20 Andy Newton=09 2 - Best Current Practices for Session Peering on the Internet 15 minutes by Carriers through Federations draft-rosen-speermint-peeringbcp-v1-00 Brian Rosen 3 - SIP Peering Use Case for VSPs 15 minutes draft-uzelac-speermint-use-cases-00 Adam Uzelac=20 4 - Session Peering Use Cases for Federations 15 minutes draft-schwartz-speermint-use-cases-federations-00 David Schwartz 5 - IM Use Cases 15 minutes draft-houri-speermint-usecase-presence-00 Avshalom Houri OTHER DRAFT REVIEWS (25mins) 6 - SPEERMINT Requirements for SIP-based VoIP Interconnection 10 minutes draft-ietf-speermint-requirements-01 Jean-Francois Mule 7 - SPEERMINT Peering Architecture 10 minutes SPEERMINT Routing Architecture Message Flows=20 draft-ietf-speermint-architecture-02 draft-ietf-speermint-flows-01 Reinadlo Penno 8 - VoIP Security Threats 5 minutes draft-niccolini-speermint-voipthreats-00.txt Saverio Niccolini o Open Discussion 10 minutes =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 31 16:52:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1Oq-0002Ku-9Z; Tue, 31 Oct 2006 16:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1Ok-000276-KJ for speermint@ietf.org; Tue, 31 Oct 2006 16:43:54 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1F7-0002m8-FF for speermint@ietf.org; Tue, 31 Oct 2006 16:33:58 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 13:33:57 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VLXutK006769; Tue, 31 Oct 2006 13:33:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VLXuAo007213; Tue, 31 Oct 2006 13:33:56 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 13:33:56 -0800 Received: from [192.168.1.3] ([10.21.98.97]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 13:33:55 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28BCB438-ADB0-4026-8516-1B6D30ED375E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 31 Oct 2006 13:33:59 -0800 To: David Meyer , Jason Livingood , David Schwartz X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Oct 2006 21:33:55.0920 (UTC) FILETIME=[44B0C500:01C6FD34] DKIM-Signature: a=rsa-sha1; q=dns; l=81; t=1162330436; x=1163194436; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Question=20on=20draft-schwartz-speermint-use-cases-federati; X=v=3Dcisco.com=3B=20h=3DKGhS8lwAjU0g3CUAoOZA2I7wae4=3D; b=c7pJ+hP+eB2z5KNcPXhVxBx4ZWG/prkoGNC+q7CpUiUmdmiOMmRt6vb1heofYv14tsF4VpDj gWfxYrjP9hM50ctDBTwBy0vHWHO+2oSar9OtVGYU3db/32IDsTkFDu51; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: speermint@ietf.org Subject: [Speermint] Question on draft-schwartz-speermint-use-cases-federati X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I can't seem to find this draft. If there a copy somewhere? Thanks, Cullen _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Oct 31 16:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1aT-0000ow-Qk; Tue, 31 Oct 2006 16:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1aS-0000og-A0 for speermint@ietf.org; Tue, 31 Oct 2006 16:56:00 -0500 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1aQ-0005Yl-1v for speermint@ietf.org; Tue, 31 Oct 2006 16:56:00 -0500 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id D3FA44E03; Tue, 31 Oct 2006 16:55:27 -0500 (EST) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 16:55:27 -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] Question on draft-schwartz-speermint-use-cases-federati Date: Tue, 31 Oct 2006 16:55:14 -0500 Message-ID: In-Reply-To: <28BCB438-ADB0-4026-8516-1B6D30ED375E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Question on draft-schwartz-speermint-use-cases-federati Thread-Index: Acb9Ns5MDaQikGyZRXuy7fTWyLnVFgAAGXRg From: "Uzelac, Adam" To: "Cullen Jennings" , "David Meyer" , "Jason Livingood" , "David Schwartz" X-OriginalArrivalTime: 31 Oct 2006 21:55:27.0886 (UTC) FILETIME=[46C322E0:01C6FD37] X-Spam-Score: 1.2 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org http://www.kayote.com/web/docs/Drafts/draft-schwartz-speermint-use-cases -federations-00.txt =20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Tuesday, October 31, 2006 4:34 PM To: David Meyer; Jason Livingood; David Schwartz Cc: speermint@ietf.org Subject: [Speermint] Question on draft-schwartz-speermint-use-cases-federati I can't seem to find this draft. If there a copy somewhere? Thanks, Cullen _______________________________________________ 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